The security tests that quietly stopped.
ISO 27001:2022 A.8.29 (security testing in development and acceptance) is the control behind the question 'did anyone test the security of this change?' It asks for a repeatable way to verify security requirements as systems are built, and for that verification to inform the decision to accept a release: tests that check the security properties your software claims (authorization rules, injection regressions, session and token handling). The clause does not prescribe a tool or a gate; it wants testing that actually happens, not a process that lives on paper. Which is why it usually dies the same way: not with a decision to stop security-testing, but with a small, reasonable edit that makes the tests stop running.
The shapes the same control failure takes.
A.8.29 rarely breaks with a change that says 'we no longer security-test'. It breaks when the tests that carried the coverage quietly stop running. The recurring shapes:
A security suite is skipped to unblock a merge
Tests covering authorization, injection, or session rules are marked skip while they fail, with a note to re-enable later. The suite stops failing the build; the skip stays.
A security test file is deleted in a cleanup
A flaky-test purge or refactor removes a security regression suite entirely, so the coverage it carried disappears instead of failing.
Assertions are loosened until the suite passes
Security tests are weakened (expected errors removed, negative cases deleted) so they stop failing, instead of the code being changed to meet them.
Security tests drop out of the release run
The test command or config that runs before release starts excluding the security suite (an ignore pattern, a tag filter), so the release decision is made without the security pass it used to have.
A vulnerability fix ships without its regression test
The fix goes in, the test that pins it does not, so nothing fails if the same weakness returns, and there is nothing to show that the fix was ever verified.
An authorization suite marked skip to get a merge green.
A role-model refactor changed the shape of permissions, and the authorization suite now fails intermittently. That suite is the one that pins the rules an audit cares about: viewers cannot issue invoices, editors cannot grant themselves admin, elevated access expires on schedule. Rather than fix the tests against the new model, someone marks the suite skip to get the merge green and files a ticket to do it properly. The merge goes green, the ticket goes on the backlog, and if nothing forces the suite back on, it stays skipped release after release.
- describe("authorization rules", () => {+ describe.skip("authorization rules", () => { // flaky since the RBAC refactor (TCK-207), re-enable once fixed it('denies viewers from issuing invoices', async () => { it('denies editors from granting themselves admin', async () => { it('expires elevated access on schedule', async () => {This marks the whole authorization suite skip: the tests that pin the role rules will not execute when this file runs, and the diff shows nothing that replaces the coverage. The comment attributes the skip to flakiness after an RBAC refactor and points at a follow-up ticket; the diff cannot show whether the flakiness is in the application, in the tests, or in their environment, or whether any other security testing now covers these authorization rules. A.8.29 calls for security testing to happen as part of how the software is built and accepted, and skipped test code in the file tree is not evidence that it did. Fix the tests or replace them before this merges, and treat the open ticket as the first question an auditor will ask.
Auditors ask what security testing ran, and where the results are.
In an audit, A.8.29 comes up as three questions: what does your security testing cover, when does it run in development and before acceptance, and show me the results for the last few releases. A suite that is present but skipped produces the most awkward version of this answer: the test names still appear in the repo, but for as long as the skip stands, those tests produce no results, and the note promising to re-enable them points at a ticket. That gap usually starts as a one-line, reasonable edit merged under time pressure, which is why it is worth catching while it is still a diff.
A review, not a test runner.
heygrc flags changes that touch A.8.29 and cites the control so the fix happens in the pull request. It does not run your security tests or judge how deep they go. It catches the moment a change disables security tests, at the diff.