AI-enabled capabilities acquired through software-intensive pathways shift assurance concerns from hardware performance and static software validation to data integrity, model drift, supply chain trust, and the resilience of distributed digital ecosystems.
Navigating the complex terrain of proMoving Cyber Resiliency Require - ments Methodology (CRRM) farther “left” toward earlier stages of pro - gram development can help engineer and embed assurance against loss rather than have assurance added after problems begin to emerge. Because AI systems rely on dy - namic data pipelines, evolving models, and extensive third-party software, conventional assurance methods are insufficient for adaptive, data-driven behavior. AI systems also change after deployment through re - training, updates, and shifting inputs, creating model drift and behavior that may not match validated oper - ating assumptions. Verification and validation methods built for relatively stable systems do not adequately ad - dress these dynamics. I would argue that integrating Model-Based Systems Engineering (MBSE) with the CRRM provides a repeatable way to identify loss sce - narios and strengthen security and resiliency in AI-enabled systems. A notional AI system illustrates how this approach can be applied from architecture development through validation.
The expanding AI ecosystem in - creases exposure to malicious data, compromised software components, adversarial model manipulation, in - sider threats, and attacks on Make it Application Programming Interface (API)- or cloud-based services (Fig - ure 1). As organizations depend more on external data sources, third-party models, and interconnected infra - structure, they inherit risks that are often difficult to validate and monitor in real time. Dynamic, System-Theoretic Risk Management Managing these conditions re - quires moving beyond component- focused compliance checks toward system-level analysis of behavior, control logic, timing, and feedback. For complex software-intensive sys - tems, the CRRM process, including security analysis extension of System- Theoretic Process Analysis (STPA- Sec), adds value by analyzing inter - actions and control behavior rather than only component failure. STPA-Sec for software-intensive systems. As systems become increas - ingly software-defined, risk must be understood in terms of behavior, control logic, timing, and interaction,
with a perspective framework not only at the component level. STPA- Sec applies control-theoretic analy - sis to identify unsafe control actions, weak feedback loops, timing depen - dencies, and data flow issues that can produce hazardous or exploitable outcomes in software-intensive sys - tems. It is therefore useful for identify - ing risks that are often missed by tra - ditional testing or compliance-based methods. Its applicability extends beyond traditional safety-critical domains. For example, Google’s Site Reliability Engineering teams have applied STPA to complex software en - vironments to identify unsafe control actions and causal factors linked to outages and security incidents. Integrating STPA-Sec and MBSE Integrating Cyber Resiliency Re - quirements Methodology into an MBSE framework allows engineers to build control-feedback mod - els that improve traceability be - tween hazards, system functions, and design artifacts across the life cycle. It also makes timing relation - ships, data flows, and feedback in - teractions visible early enough to address risk before deployment. Performed within a digital engi - neering ecosystem, this integration advances the Acquisition Transfor - mation Strategy’s goal of modern - izing systems engineering: The au - thoritative MBSE model becomes a shared, physics- and behavior-in - formed component of the source of truth that links acquisition decisions, resilience requirements, and assur - ance evidence across the life cycle, supporting faster, cheaper, and more reliable delivery of weapon systems. The CRRM process shown in Figure 2 includes five phases: Define System Description, Perform Hazard Analysis, Perform Loss Scenario Assessment, Define Resilience Architecture, and
Figure 1. eSystem Contexts/AI Supply Chain
<system context> AI SUPPLY CHAIN
<external> CLOUD INFRASTRUCTURE
<external> THIRD PARTY VENDORS
<system> SOFTWARE ECOSYSTEM
<external> DATA SOURCE
<external> AI/LM MODELS
<subsystem> OPERATIONAL DATA
<subsystem> LIBRARIES AND APIs
<subsystem> DEPENDENCIES
<subsystem> COMPUTE
<subsystem> STORAGE
<subsystem> TRAINING DATA
Key. AI/LM=Artificial Intelligence/Machine Learning Source. Author
SEPTEMBER –OCTOBER 2026 | DEFENSE ACQUISITION MAGAZINE 37
Made with FlippingBook - Online Brochure Maker