[ST3.5: 2] Begin to build and apply adversarial security tests (abuse cases).
QA begins to incorporate test cases based on abuse cases (see [AM2.1 Build attack patterns and abuse cases tied to potential attackers]) 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 Build and maintain a top N possible attacks list]). This effort turns the corner from testing features to attempting to break the software under test.
[ST3.6: 0] Implement event-driven security testing in automation.
The SSG guides implementation of automation for continuous, event-driven application security testing. Event-driven testing implemented in ALM 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 as software moves through ALM, and helps ensure the right testing is executed for a given set of conditions. This might be instead of or in addition to software arriving at a gate or checkpoint and triggering a point-in-time security test. Success with this approach depends on 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.