Security Acts: The Magazine for IT Security

The publisher of Testing Experience launched Security Acts, subtitled the magazine for IT security, in late 2009. It appears in this domain's link record in two ways. First, as anchor text on links to the Testing Experience homepage: 'Security Acts', 'SecurityActs', 'Security Acts - The Magazine for IT Security', 'Security Acts - Media', 'Security Acts website' and the sister domain's URL, together about twenty referring domains and more than 1,700 links, most of them a sitewide banner on a single large site. Second, as two PDF files hosted on this domain, securityacts03.pdf and securityacts04.pdf, issues 3 and 4 of the sister title, which were linked with a stray trailing dot from broken markup on the citing page. Both file names, with and without the dot, redirect here.

The 'Security Acts - Media' anchor comes from the programme page of a 2010 international incident-response conference, which listed the magazine as a media partner. That places Security Acts in the same media-partner role at security events that Testing Experience held at testing events, and it confirms the publisher's strategy: one editorial operation, two audiences, cross-promoted from each magazine's site.

How many issues Security Acts ran to, and when it stopped, is not recoverable from this domain's link data; only issues 3 and 4 are named. The sister domain is not part of this site and no claim is made about its current status. What the record does establish is the editorial bridge the publisher was building between software testing and security testing, which began with the OSSTMM article in issue 6 and continued in the separate title.

That bridge is worth keeping. Security testing is still the area where most test teams have the least confidence and the most exposure, and the methodology-first approach the OSSTMM article introduced to testers in 2009 remains the right one. The security testing guide on this site covers the five main types of security testing, the OSSTMM and the OWASP Top Ten as vocabularies, where each activity sits in a delivery pipeline, and what a tester without a security background can start doing this quarter.

Reading the Security Acts anchors. The twenty domains and 1,700 links divide very unevenly. One large site carried a sitewide banner with a Security Acts anchor for years, and a banner counts once per page, which is where most of the 1,700 links come from; set it aside and about nineteen domains remain with a handful of links each, the ordinary profile of a magazine being mentioned. Five anchor spellings survive ('Security Acts', 'SecurityActs', the subtitle form, the media-partner form and 'Security Acts website') plus the sister domain's URL used as anchor. All of them point at the Testing Experience homepage rather than at any Security Acts file, which means the publisher promoted the sister title from the Testing Experience site and other sites copied that link. The two PDF names, securityacts03.pdf and securityacts04.pdf, are the only direct file evidence, and their trailing-dot shapes come from a citing page whose markup ran the file name into the following sentence.

How security testing practice changed, 2009 to 2026. When issue 6 and then Security Acts appeared, OSSTMM 2.x was the current methodology; OSSTMM 3 arrived in 2010 with the rav as a reproducible attack-surface measure. The OWASP Testing Guide was at version 3, from 2008; version 4 followed in 2014 and the Web Security Testing Guide 4.2 in 2020, with numbered test cases that a pipeline can reference. NIST SP 800-115, published in September 2008, is still the assessment guide that regulated buyers in the United States cite. The practical change is cadence: a 2009 security test was an engagement booked once a year, and the magazine's role was to explain it to testers who would never run one. In 2026 the cheap activities (threat modelling at design, static analysis and dependency scanning on every commit, dynamic scanning in staging) run continuously, and the penetration test is the last check rather than the only one.

Where an IT security reader should go now. Start with Table 1 of the security testing guide, which compares the five types of security testing by lifecycle stage, what each finds and misses and who runs it, then the section 'OSSTMM in plain terms' for the channels, the visible-accessible-trusted distinction and the rav. The section on where security testing sits in a delivery pipeline, with its pipeline budget callout, is the one to hand to a delivery lead. A reader from the testing side should read the closing five-point list, which begins with adding abuse cases to every story. For the risk vocabulary the OWASP Top Ten section covers, pair it with the risk-based testing guide's scoring matrix so that security risks are scored on the same 5 by 5 scale as everything else. For mobile applications the mobile app testing guide's permissions section and the OWASP MASVS it cites are the starting points. The issue 6 record preserves the one article title the archive establishes.