What is Continuous Offensive Security Testing (COST)?

What triggers a COST run?

The defining shift is that you stop scheduling tests and start defining events that launch them. A trigger specifies which testing method fires, against what scope, at what depth, and on what timeline. The calendar becomes a fallback rather than the plan.

The practical consequence is that a COST platform has to know what changed, not just that something did. A trigger that fires a full-surface re-scan on every deployment is unusable for a team that deploys twenty times a day. The run has to scope itself to the endpoints, roles and dependencies the change actually touched, and replay previously proven findings as regressions so old ground is not silently abandoned.

• A deployment — Code reaches an environment. The highest-frequency trigger in any team that ships more than monthly, and the one that makes calendar-based testing structurally inadequate.
• A new asset — A subdomain, an API, a bucket, a cluster appears. Attack surface grows without anyone filing a ticket, so discovery has to be a trigger rather than a quarterly exercise.
• A fresh CVE — A new vulnerability lands in a dependency you run. The question is never whether the CVE is real but whether it is reachable and exploitable in your deployment, which requires testing rather than a version comparison.
• Configuration drift — A role gains a permission, a security group opens, a policy is relaxed for a migration and never tightened. Nothing shipped, but the blast radius moved.

How does COST relate to CTEM, AEV and pentesting?

CTEM is the programme, COST is the testing engine inside it, and AEV is the validation discipline they share. They are layers rather than rivals, which is why vendors in all three keep describing similar things.

Continuous Threat Exposure Management (CTEM) is the umbrella operating model: scope, discover, prioritise, validate, mobilise. It tells an organisation how to run exposure management as a programme. COST sits inside the validate stage and answers a narrower question: when and how does offensive testing actually fire.

Adversarial Exposure Validation (AEV) is the discipline of confirming that an exposure is genuinely exploitable rather than theoretically present. It is the standard of evidence COST produces. Traditional penetration testing is not replaced so much as absorbed: it becomes one of the methods a trigger can invoke, alongside red teaming, bug bounty and control validation, rather than the whole programme.

The reason the distinction matters commercially is that a tool can be excellent at AEV, proving exploitability to a very high standard, and still not deliver COST, because it has no trigger model and no pipeline integration. Proof is a capability. COST is an operating model.

How is a COST programme measured?

Not by tests completed. The success metrics are measurable reductions in exposure windows, faster risk validation, and improved response readiness. That single change in scoring is what separates a real COST programme from a scanner on a cron job.

An exposure window is the time between a weakness becoming exploitable in your environment and it being closed and verified closed. It opens when the vulnerable code deploys, not when someone discovers it, and it shuts when a fix is merged and the original attack path no longer works.

Reading it that way clarifies what each capability is actually worth. A faster trigger shortens the gap between deploy and discovery. Proof of exploitability shortens triage, because nobody spends three days deciding whether a finding is real. Neither of them closes the window. The window closes on a merged patch and a passing retest, which means remediation speed is not a nice-to-have bolted onto a COST programme, it is the denominator of the only metric the model is scored on.

This is the most common gap in current COST implementations. Teams buy a trigger-driven platform that proves exploitability beautifully, then discover their exposure windows barely moved, because the queue of confirmed findings still waits on engineering capacity to write every patch by hand.

Calendar-based penetration testing vs COST

The same offensive techniques. A completely different operating model around when they fire and how success is judged.

How to implement a COST programme

Four steps that convert a calendar-based testing programme into a trigger-driven one without losing your compliance evidence along the way.

1. Step 1

   Baseline your exposure window

   Measure the current time from vulnerable deploy to verified closed on a handful of real past findings. It will be uncomfortable, and it is the only number that tells you later whether any of this worked.

2. Step 2

   Define triggers, not a schedule

   Write down which event invokes which method, at what depth, against what scope. Start with deployment and new-asset triggers, which cover most real risk movement, then add CVE and drift.

3. Step 3

   Make runs incremental

   A trigger is only useful if the run it fires is fast enough to keep up. Scope each run to what the change touched and replay past findings as regressions, so per-merge testing is realistic rather than aspirational.

4. Step 4

   Close the loop, or the metric will not move

   Connect validated findings to remediation: a drafted patch, a review, a merge, and a retest of the original attack path. Without this the programme gets faster at discovering exposures it still cannot close.

Frequently asked questions

What does COST stand for in cybersecurity?

COST stands for Continuous Offensive Security Testing. It describes a trigger-driven, intelligence-led model of offensive testing that activates when material risk changes, replacing the calendar-based penetration testing cycle. It unifies pentesting, red teaming, bug bounty and control validation into a single continuously operating capability.

How is COST different from CTEM?

They operate at different levels. CTEM (Continuous Threat Exposure Management) is the overall programme: scope, discover, prioritise, validate, mobilise. COST is the testing engine that sits inside the validate stage, answering when and how offensive testing actually fires. You can run CTEM as a programme and still have calendar-based testing underneath it, which is precisely the gap COST names.

Does COST replace penetration testing?

It absorbs it rather than removing it. Traditional penetration testing becomes one of the methods a trigger can invoke, alongside red teaming, bug bounty and control validation. Human testers remain essential for novel attack ideas, lateral thinking and regulatory sign-off. What changes is that the calendar stops being the thing that decides when testing happens.

What are the triggers in a COST model?

The four common ones are a deployment, a new asset appearing on the attack surface, a fresh CVE landing in a dependency you run, and configuration drift such as a role gaining a permission or a security group opening. Each trigger specifies which testing method it invokes, against what scope, at what depth, and on what timeline.

Why is exposure window the key COST metric?

Because it is the only measure that reflects real risk rather than activity. An exposure window opens when vulnerable code deploys and closes when a fix is merged and verified. Counting tests completed rewards motion; measuring exposure windows rewards outcomes. It also exposes an uncomfortable truth: faster triggers and better proof shorten discovery and triage, but only remediation actually closes the window.

Can a tool do COST without doing remediation?

It can satisfy the trigger half of the model and still fail the metric. A platform that fires on every deployment and proves exploitability to a high standard has solved discovery and triage speed. If the resulting queue of confirmed findings waits on engineering to hand-write every patch, exposure windows stay roughly where they were. This is the most common gap in current COST implementations, and it is why remediation belongs inside the programme rather than downstream of it.