[ST3.5: 4] Begin to build and apply adversarial security tests (abuse cases).
QA teams incorporate test cases based on abuse cases (see [AM2.1]) as testers move beyond verifying functionality and take on the attacker’s perspective. One way to do this is to systematically attempt to replicate incidents from the organization’s history. Abuse and misuse cases based on the attacker’s perspective can also be derived from security policies, attack intelligence, standards, and the organization’s top N attacks list (see [AM2.5]). This effort turns the corner in QA from testing features to attempting to break the software under test.
[ST3.6: 3] Implement event-driven security testing in automation.
The SSG guides implementation of automation for continuous, event-driven application security testing. An event here is simply a noteworthy occurrence, such as dropping new code in a repository, a pull request, a build request, a push to deployment, or a Tuesday at noon. Event-driven testing implemented in pipeline automation typically moves the testing closer to the conditions driving the testing requirement (whether shift left toward design or shift right toward operations), repeats the testing as often as the event is triggered, and helps ensure that the right testing is executed for a given set of conditions. Success with this approach depends on the broad use of sensors (e.g., agents, bots) that monitor engineering processes, execute contextual rules, and provide telemetry to automation that initiates the specified testing whenever event conditions are met. More mature configurations proceed to including risk-driven conditions (e.g., size of change, provenance, function, team).