Notifications
Clear all
Topic starter
06/09/2026 9:33 am
TL;DR: Continuous offensive security testing, or COST, fails when teams confuse cadence with coverage, findings with proof, and AI-driven planning with safe execution, according to FireCompass. The real shift is toward validated exploit chains, controlled autonomy, and governance that keeps offensive testing usable in production.
NHIMG editorial — based on content published by FireCompass: COST vs CTEM: What Continuous Offensive Security Testing Requires
By the numbers:
- DAST scanners routinely run 40-70% false positive rates, which pushes teams back into triage instead of remediation.
Questions worth separating out
Q: What breaks when offensive security is limited to annual testing cycles?
A: The evidence window is too short and too stale.
Q: Why do proof-of-exploit requirements matter in offensive testing?
A: Proof-of-exploit matters because findings without reproducible evidence create noise, not risk reduction.
Q: How do security teams know if autonomous testing is working?
A: Look for fewer disputed findings, faster triage, and a higher percentage of issues that map to real attack paths.
Practitioner guidance
- Define continuous as change-driven coverage Tie offensive testing to release events, new CVEs, exposed assets, and identity changes so the programme tests what actually moved.
- Require reproducible proof for every finding Reject any output that does not include a working request, response evidence, and step-by-step reproduction against the live target.
- Separate AI planning from execution runtime Place scope checks, rate limits, kill switches, and audit logging between the model and any live target so autonomy remains constrained.
What's in the full article
FireCompass's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the COST execution model, including how validation runs move from planning to safe live testing.
- Detailed discussion of governance controls such as scope enforcement, kill switches, and credential scoping for autonomous testing.
- Performance evidence from a large enterprise deployment, including coverage expansion, false positive reduction, and cost comparisons.
- Examples of how the platform chains findings into attack paths across applications, services, and network boundaries.
👉 Read FireCompass's analysis of continuous offensive security testing and governance →
Continuous offensive security testing: where the governance gap shows up?
Explore further
06/09/2026 9:34 am
Cadence is not continuity: The market still overuses the word continuous to describe faster versions of periodic testing. That is a governance error, not just a terminology issue, because the real requirement is coverage that tracks change across assets, access paths, and exposure windows. In NIST-CSF terms, the control question is whether the organisation can identify and protect what changed before the next exploit window opens. Practitioners should treat cadence as a delivery detail, not the definition of the category.
A question worth separating out:
Q: How should teams evaluate continuous offensive security testing against scanners?
A: Teams should evaluate whether the tool models attack chains, not just isolated vulnerabilities. A scanner can enumerate issues, but COST should show how a disclosure becomes credential access, how access becomes lateral movement, and where the chain can be halted. That is the operational difference that matters.
👉 Read our full editorial: Continuous offensive security testing needs proof, not just cadence
