Testing Experience Issue 6, June 2009

Record card

What the links show

Issue 6 was published as testingexperience02_09.pdf (the second file of 2009) and mirrored later as issues/testingexperience06_06_09.pdf. Fifteen referring domains still link it. Three of them are unusual for a testing magazine: an OWASP chapter mailing-list archive, the Bugtraq list archive held at a German university, and a security-list mirror. All three carry a June 2009 posting that pointed at the file, which means the issue was announced to security professionals directly, not just to testers. The anchor 'Security Testing by Methodology: the OSSTMM' (two referring domains) is the article title as it was quoted in that announcement.

The OSSTMM is the Open Source Security Testing Methodology Manual, a methodology for measuring operational security by testing rather than by checklist. An article introducing it to a software-testing audience in 2009 fits the magazine's pattern of bridging communities, and it explains why the publisher launched a sister title for IT security later the same year (see Security Acts). It also explains the separate application-security PDF the site hosted, which now redirects to the security testing guide.

The rest of the issue's link record is ordinary: tester blogs in English and Portuguese, and the Portuguese theme index that lists the magazine's recurring subjects. The Portuguese summary of the sixth edition ('Resumo da 6a edicao') is the one case where a summary post is tied to a specific issue number in the anchors, and it confirms that the security theme was what readers took from it.

For a reader who arrives from a 2009 security-list link, the security testing guide explains the OSSTMM in plain terms alongside the other security testing types and where each sits in a delivery pipeline. It is an independent explanation; it is not the 2009 article and does not reproduce it.

The anchor and link shapes for issue 6 fall into two groups that do not overlap. The security-list group (the OWASP chapter archive, the Bugtraq archive and the list mirror) links the root file testingexperience02_09.pdf with the article title as anchor or the raw URL, from June 2009 postings that were archived once and never edited, so their links are dated precisely. The tester-blog group links the same file or the mirrored issues/testingexperience06_06_09.pdf name from Portuguese and English posts, including the 'Resumo da 6a edicao' summary. Fifteen domains in all. The mailing-list archives are the only links in the whole magazine record that come from security sites rather than testing sites, and they are the reason this issue's theme is stated with more confidence than any other issue's: the article title is quoted verbatim in the anchors.

A reader who followed the June 2009 list posting wanted an introduction to a security testing methodology written for testers rather than for penetration testers. The section 'OSSTMM in plain terms' of the security testing guide is that introduction: it explains the five channels (human, physical, wireless, telecommunications and data networks), the distinction between what is visible, accessible and trusted, and the rav as a result another tester could reproduce. Table 1 in the same guide compares five types of security testing by lifecycle stage, what each finds and misses, and who usually runs it, and the closing five-item list (adding abuse cases to every story is the first item) gives a tester without a security background a place to start this quarter.

The methodology landscape moved after 2009. The article was written against OSSTMM 2.x; OSSTMM 3 was published by ISECOM in 2010 and introduced the rav in the form the guide describes. On the application side the OWASP Testing Guide was at version 3 (2008) when the issue appeared; version 4 followed in 2014 and the renamed Web Security Testing Guide reached version 4.2 in 2020, organised around numbered test identifiers that a pipeline can reference. NIST SP 800-115, the US technical guide to security testing and assessment, dates from September 2008 and is still the document most regulated buyers cite. The larger change is where the testing happens: in 2009 a security test was an annual engagement; in 2026 static analysis and dependency scanning run on every commit, and the penetration test comes last, which is how Figure 1 of the security testing guide orders the activities.