Making the Case for Cybersecurity
does. Threat likelihood reflects the capabilities, intentions, and opportunities of attackers, as well as the trust boundaries and operating environment of the system.
Risk measurements also incorporate the presence and quality of mitigations— controls and countermeasures modeled or planned. This supports“ what-if” simulations where different defense strategies are applied to the same attack graph.
This modular architecture reflects zero-trust principles: risk is assessed based on what the system exposes, not what it assumes about its users or environment. Trust can be represented as a recalibrated attack likelihood claim in a given threat environment, not a baked-in assumption.
Figure 3-3: Risk measurement claims.
By clearly separating the attack surface from the threat intelligence and mitigation, the framework supports:
• Continuous re-evaluation as threat intelligence evolves
• Mission-aware prioritization of risks
• Evidence-driven trade-offs between cost, control, and exposure.
4 ATTACK PATH CHARACTERIZATION IN RISK-CENTRIC DEVSECOPS
As an attack path is central to making a risk claim, how can we orchestrate attack path enumeration to justify completeness of risk claims, and do so continuously?
In a risk-centric DevSecOps framework, an attack is not merely a theoretical threat— it is a system-specific scenario in which an adversary exploits architectural or operational conditions to compromise mission-relevant assets. To support automation and continuous reasoning, such attack paths must be formally characterized. This means linking offensive techniques to the specific system facts that make them technically feasible.
46 May 2025