BAS, CTEM and CART: where offensive security categories diverge

At a glance

What this is: This is a category-by-category analysis of offensive security testing methods, showing where VA, DAST, pen testing, BAS, CART, ASM, AEV and COST do and do not fit.

Why it matters: It matters because IAM, NHI and broader security teams need to know which control validates exposure, which one tests exploitability, and where continuous offensive testing changes the governance model.

By the numbers:

• The average enterprise now manages 25x to 50x more non-human identities than human identities.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 91.6% of secrets remain valid five days after the targeted organisation is notified.

👉 Read FireCompass's breakdown of BAS, CTEM, CART, VA and AEV

Context

Offensive security categories are often sold as substitutes when they are really different layers of assurance. Vulnerability assessment, DAST, BAS, CART, ASM, AEV and pen testing each answer a different governance question, and confusing them leaves teams with visibility but no proof of exploitability. In environments with heavy NHI usage, that distinction matters because exposed secrets, service accounts and APIs create attack paths that scanners alone rarely validate.

For security programmes, the practical issue is not taxonomy for its own sake. It is deciding which tool validates controls, which one validates exposure, and which one proves an attacker can actually chain a path to impact. That decision affects how IAM, PAM and broader security teams prioritise remediation, especially where credentials, access paths and application flaws intersect.

Key questions

Q: How should security teams choose between VA, BAS, CART and pen testing?

A: Choose by the question you need answered. VA tells you what known weaknesses exist, BAS checks whether controls stop known techniques, pen testing proves whether an attacker can compromise a defined target, and CART tests whether an adversary can reach an objective continuously. If the programme cannot say which question each tool answers, it is probably buying overlap rather than coverage.

Q: Why do exposure scans often fail to reduce real risk?

A: Exposure scans often fail because they stop at discovery. They can show that an asset exists or that a CVE is present, but they do not prove exploitability, chaining or business impact. Without validation, teams end up fixing what is visible rather than what is reachable and material. That is why validation is the step that turns exposure into risk prioritisation.

Q: What breaks when attack surface management cannot validate critical risk?

A: When ASM cannot validate critical risk, teams over-trust raw findings and under-invest in the exposures that matter most. That creates blind spots, weak prioritisation, and remediation backlogs that do not meaningfully reduce attack paths. The result is a reporting exercise instead of a control function, with security teams left unable to prove risk reduction.

Q: How do continuous offensive testing programs support zero trust and NHI governance?

A: They test whether assumptions about access, exposure and privilege still hold under realistic attack conditions. For NHI governance, that means checking whether exposed secrets, service accounts or tokens can actually be abused to reach data or control planes. For zero trust, it means proving that exposure does not automatically become trusted access just because it is authenticated.

Technical breakdown

Vulnerability assessment versus exploit validation

Vulnerability assessment identifies known weaknesses by matching versions, signatures and configuration patterns to a CVE catalogue. It is useful for hygiene, but it does not prove that a flaw is reachable, exploitable or chained into a real attack path. Exploit validation adds that missing test by attempting to reproduce attacker behaviour against the exposed condition. In practice, the gap between the two is where false positives, patch noise and misprioritisation accumulate.

Practical implication: Treat VA as an inventory of candidates, then validate the small subset that could actually lead to compromise.

BAS, red teaming and CART are not the same control

BAS runs known attack techniques to see whether controls detect or block them. Red teaming is objective-driven and tries to achieve a realistic outcome, while CART extends that idea into continuous, adaptive attack path execution. The important distinction is between technique testing, objective testing and continuous adversarial testing. A control may pass BAS and still fail to stop a chained path that reaches privilege escalation or data access.

Practical implication: Use BAS for control assurance, red teaming for adversary realism and CART for ongoing attack-path validation.

ASM, AEV and COST form the exposure-to-validation pipeline

Attack surface management discovers what is exposed, AEV validates which exposures are actually exploitable, and COST frames the whole activity as a continuous operating model rather than a one-off test. This matters because exposure by itself is not risk. Risk appears when discoverable assets, reachable services and proven exploit paths align. For teams running cloud, web and identity-heavy programmes, this creates a more defensible prioritisation model than raw exposure counts.

Practical implication: Link discovery to validation so the programme can distinguish visible assets from materially exploitable ones.

Threat narrative

Attacker objective: The attacker aims to prove that an external exposure can be turned into a real attack path with measurable impact, not just a theoretical finding.

1. Entry begins with externally exposed assets, leaked credentials or internet-reachable services that an attacker can enumerate and probe.
2. Escalation occurs when the attacker moves from simple discovery to validated exploitation, then chains findings into deeper access or privilege gain.
3. Impact follows when the attacker reaches a defined objective such as credential theft, lateral movement, data access or control-plane compromise.

NHI Mgmt Group analysis

Category confusion is now a governance problem, not a naming problem. The article is right that VA, BAS, pen testing, ASM, AEV and CART answer different questions, but many programmes still buy them as if they were interchangeable. That creates budget leakage and a false sense of coverage. For identity-heavy environments, the same issue shows up when teams assume credential discovery, privilege validation and exploitability testing are the same thing. They are not, and governance should separate them clearly.

Exposure validation is the real control gap this category stack exposes. The most useful distinction in the article is between what is visible and what is exploitable. That is directly relevant to NHI security because exposed service accounts, API keys and tokens often exist long before anyone proves they can be chained into an actual compromise. The practical lesson is to treat validation as a control objective, not a reporting exercise.

Continuous offensive testing is becoming the operational baseline. Annual testing cannot keep pace with weekly release cycles, shadow assets and rapidly weaponised exposures. The category shift toward COST reflects a broader market move from periodic assurance to continuous proof. For IAM and PAM teams, this reinforces a Zero Standing Privilege mindset: access and exposure should be short-lived, measurable and validated in motion.

Attack-path thinking is now more valuable than control silos. The article implicitly shows why standalone scanners, isolated red-team exercises and dashboard-only exposure tools all miss the same failure mode. Attackers do not respect product categories, so governance cannot stop there either. Practitioners should organise around paths to impact, then map each control to the stage it can actually interrupt.

For NHI programmes, the hard question is whether secret exposure can be proven exploitable. An exposed token is not just a hygiene issue if it can be chained into API abuse, privilege escalation or lateral movement. That makes NHI governance inseparable from offensive validation, because the enterprise only learns the true blast radius when exposure is tested against realistic attacker behaviour.

What this signals

Continuous offensive testing is increasingly the only way to determine whether exposed identities, secrets and services are actually exploitable. For identity-heavy programmes, the shift is away from counting exposures and toward proving whether those exposures can be used to move, escalate or persist.

Exposure-to-exploitation gap: this is the control gap that many programmes still miss. A discovery tool can tell you what exists, but only validation shows whether an attacker can turn that existence into impact. That distinction will matter more as cloud, application and NHI estates keep expanding.

Security leaders should expect pressure to collapse fragmented offensive testing categories into a continuous operating model. The practical challenge is not tool variety but workflow design, ownership and measurable handoff from discovery to remediation.

For practitioners

• Differentiate validation layers in your programme Map VA, DAST, BAS, pen testing, ASM, AEV and CART to distinct control objectives so procurement, operations and reporting do not blur them together.
• Validate exposures before prioritising remediation Use exploit testing or adversarial validation on the subset of assets that appear most reachable, most exposed or most connected to sensitive identities.
• Align offensive testing to attack paths Prioritise attack paths that cross identity, application and infrastructure boundaries, especially where service accounts or API credentials can be abused.
• Treat CTEM as a workflow, not a dashboard Define how discovery findings move into validation, ownership and remediation so exposure data does not stall at the reporting stage.

Key takeaways

• VA, BAS, pen testing, ASM, AEV and CART are different controls, not interchangeable labels.
• The real security question is whether an exposure can be validated as exploitable, not merely discovered.
• For NHI and identity-heavy environments, continuous offensive testing is becoming essential to prove blast radius and prioritise remediation.

Key terms

• Vulnerability Assessment: A structured review of systems to identify weaknesses before they are exploited. It is broader than a scan because it includes judgement about exposure, business context, and which findings matter enough to drive remediation or mitigation.
• Breach and Attack Simulation: Breach and attack simulation is the practice of repeatedly running safe attack-like tests against live environments to see whether controls detect or block them. It measures defensive effectiveness across real paths, not just policy intent, and is most useful when tied to current threats and business-critical assets.
• Automated red-teaming: Automated red-teaming is the use of adversarial test generation to find how an AI model or agent fails under pressure. It goes beyond manual review by systematically probing prompt injection, goal drift, unsafe outputs, and other repeatable behavioural weaknesses before production use.
• Cloud-Native Adversarial Exposure Validation: A method for proving whether a cloud exposure is actually exploitable by running controlled attack simulations against live environments. It goes beyond detection by testing real attack paths, then returns evidence about exploitability, impact, and reach so teams can prioritise remediation based on demonstrated risk rather than assumptions.

What's in the full article

FireCompass's full article covers the operational detail this post intentionally leaves for the source:

• Per-category breakdowns of what each testing type catches and misses in practice.
• Detailed guidance on when to use each category in a real security programme.
• Examples of how continuous offensive testing is positioned alongside CTEM and exposure validation.
• A vendor-specific explanation of how the platform chains findings into attack paths.

👉 FireCompass's full article covers the category-by-category distinctions and program model in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity control design to broader security operations and governance.