From DevSecOps to Continuous Trust: Active Cyber™ Discusses Unifying Software Assurance, Supply Chain Security, and Accreditation

May 22, 2026

I was talking recently with my son who works in an AI lab designing and building assembly lines for automated AI factories and the discussion reminded me of how I was involved in an effort with NIST 20+ years ago to get some standards support started for the fledgling NIST RMF with the IEEE. At the time, I argued that the RMF was a good start, but it didn’t go far enough – I believed that it needed to push toward a more continuous and dynamic Authority-to-Operate (ATO) approach. I stepped back from my position and accepted that the extant tooling to support such a continuous ATO did not exist at the time. However, today we are starting to see organizations embrace the cATO approach that I envisioned, due largely to the introduction of AI into the software development life cycle. In fact, now the possibilities are even greater with AI fueling a more comprehensive and unified approach across security, validation testing, and compliance. Read the article below to discover more about this unified approach and swing back to give me your comments.

Modern software systems are no longer evaluated only by whether they function correctly. They are judged by whether they can be trusted—trusted to resist compromise, trusted to protect data, trusted to maintain integrity across a complex software supply chain, and trusted to operate safely in environments where cyber risk has become a strategic threat.

For many organizations, however, the mechanisms used to establish that trust remain fragmented. DevSecOps teams automate development pipelines. Supply chain teams manage SBOMs and dependency risk. Validation teams conduct testing. Common Criteria evaluators produce assurance documentation. Certification and accreditation authorities assess operational risk separately. Each discipline operates within its own silo, using different tools, evidence models, and reporting structures.

The result is duplication, delay, and often a false sense of assurance. Security evidence is recreated multiple times. Compliance becomes documentation-heavy. Accreditation occurs long after deployment. And software trust remains difficult to measure in real time.

I am happy to say a different model is emerging, finally.

Rather than treating security, assurance, and accreditation as isolated functions, leading organizations are beginning to chain them together into a single continuous assurance pipeline—one in which DevSecOps, software supply chain security, validation, Common Criteria evaluation, and certification processes become components of a unified trust architecture.

The shift is profound. It transforms assurance from a periodic administrative exercise into a continuously updated operational capability.

The Evolution from Secure Development to Continuous Assurance

Traditional software assurance models were designed for slower development cycles. Security reviews occurred at milestones. Accreditation packages were assembled manually. Certification frequently lagged months behind deployment. By the time systems were formally authorized, the software itself had already changed.

Cloud-native development, CI/CD pipelines, containerization, and AI-assisted coding have fundamentally altered that environment. Software now evolves continuously. Dependencies change daily. Infrastructure is ephemeral. Supply chains are globally distributed. Threat actors increasingly target build systems, open-source libraries, and development pipelines rather than production systems alone.

In this environment, trust cannot be established through static certification alone. It must be continuously generated and continuously verified. This is where the convergence of DevSecOps and assurance engineering becomes strategically important.

DevSecOps as the Foundation of Trust Generation

At its core, DevSecOps provides more than development automation. It provides a mechanism for generating evidence.

Every secure commit, every signed artifact, every test execution, every policy check, and every vulnerability scan becomes a measurable signal about the integrity of the system. Properly architected, the CI/CD pipeline evolves into a continuous evidence-generation engine.

In mature environments, security controls begin before code is even committed. Developers operate within protected repositories using signed commits, branch protections, secrets detection, and dependency validation. Build systems produce reproducible artifacts within isolated environments. Automated pipelines execute static analysis, dynamic testing, fuzzing, container scanning, and infrastructure-as-code validation as part of normal delivery operations.

The significance of this automation is not merely operational efficiency. It is traceability. Every action becomes attributable:

• who introduced the code,
• which dependencies were used,
• which compiler produced the artifact,
• what vulnerabilities were present,
• which controls were validated,
• and whether the resulting software satisfies established trust policies.

In effect, the software begins producing its own audit trail as it evolves.

The Rise of Software Supply Chain Assurance

The emergence of software supply chain attacks has accelerated this transformation. Incidents involving compromised libraries, poisoned updates, malicious packages, and build-system intrusions demonstrated that organizations could no longer trust software simply because it originated from internal development teams.

Modern assurance therefore extends beyond code review into provenance verification.

Software Bills of Materials (SBOMs) now provide visibility into dependency composition. Cryptographic signing frameworks such as Sigstore and Cosign establish artifact integrity. SLSA provenance models define the maturity of build-chain security. Attestation systems create verifiable records proving how software was constructed and validated.

These mechanisms fundamentally alter the nature of accreditation. Instead of relying solely on procedural claims, organizations can increasingly rely on cryptographic evidence. Trust becomes measurable. The software supply chain itself becomes observable. And assurance transitions from narrative documentation to verifiable telemetry.

Validation as a Continuous Activity

Historically, validation occurred near the end of development. Security testing was often isolated from operational deployment, and compliance reviews occurred independently from engineering workflows.

Continuous assurance collapses these boundaries. Validation now occurs simultaneously across multiple dimensions:

• functional correctness,
• security resilience,
• policy compliance,
• runtime integrity,
• and operational behavior.

Static analysis tools identify vulnerabilities before execution. Dynamic testing simulates adversarial behavior. Fuzzing uncovers unexpected edge cases. Runtime monitoring validates system behavior after deployment. Infrastructure validation continuously checks for drift against approved baselines.

Increasingly, AI systems are also entering the validation process itself. Large language models are being used to review code, identify insecure patterns, correlate vulnerabilities, and analyze deviations from security policy. Over time, these systems may evolve into autonomous assurance agents capable of continuously evaluating trust posture across distributed environments.

Validated solution designs are critical for AI technology because they shift AI from experimental, “black-box” prototypes to reliable, production-ready systems. By pre-testing, documenting, and securing AI architectures, validated designs minimize the high risks of failure, bias, and unforeseen costs associated with deploying AI.

1. Validated AI Solution Designs De-risk Deployment and Reduces Failure  

AI systems, particularly LLMs and agentic AI, can be unpredictable, hallucinate, or behave differently in production than in training.

• Controlled Testing: Validated designs allow testing in a controlled, lab-like environment, replicating real-world scenarios before live deployment.
• Predictability: They move companies from hoping an AI works to knowing it works.
• Safety and Compliance: In regulated industries like healthcare or finance, validated designs ensure compliance with legal frameworks (e.g., EU AI Act, NIST) by providing audit trails.

2. Validated AI Solution Designs Accelerate Time-to-Market  

Without validation, AI projects often get stuck in the Proof of Concept (POC) phase due to integration complexity or performance issues.

• Faster Deployment: Validated designs—such as those from Dell, NVIDIA, or Juniper—provide pre-tested, integrated hardware-software stacks.
• Reduced Rework: Because the architecture is pre-proven to work together, companies spend less time debugging infrastructure and more time building applications.

3. Validated AI Solution Designs Ensure Scalable and Performant AI  

AI models often fail to scale, causing high inference costs and increased latency under heavy user loads.

• Optimized Performance: Validated designs are engineered to ensure the network is never a bottleneck in AI model training.
• Optimized Costs: By validating the model and infrastructure together (e.g., GPU usage), organizations can prevent runaway operational expenses (OPEX).

4. Validated AI Solution Designs Improve Trust and Reliability  

Validated models are marked with, for example, a “RedHat AI validated model” badge or NVIDIA-Certified Systems, ensuring that the model has been evaluated for accuracy and safety.

• Countering Bias: They help identify and rectify bias in training data, leading to fair, equitable solutions.
• Handling Drift: Continuous validation, a key part of these designs, helps detect data or concept drift—where model performance degrades over time as new data emerges.

5. Validated AI Solution Designs Optimize Resource Allocation  

Building internal labs to test complex AI models is expensive and time-consuming. Validated designs reduce total cost of ownership (TCO) by providing ready-to-use blueprints. The validated design efforts usually involve external expertise (e.g., Dell AI Factory) to solve complex integration challenges, freeing internal teams to focus on strategic, business-specific applications.

The result is a software ecosystem where validation no longer represents a phase. It becomes a permanent condition.

Common Criteria in the Age of Automation

One of the most important—and most overlooked—developments in this evolution is the modernization of formal assurance frameworks such as Common Criteria. Traditionally, Common Criteria evaluations have been viewed as expensive, document-centric, and disconnected from agile engineering practices. Much of the burden came from manually generating evidence after development had already occurred. Continuous assurance changes that equation.

Modern CI/CD pipelines already generate many of the artifacts required for formal evaluation:

• interface documentation,
• configuration management records,
• test coverage reports,
• vulnerability assessment outputs,
• traceability matrices,
• and supply chain attestations.

When these artifacts are mapped directly to Security Assurance Requirements (SARs) and Security Functional Requirements (SFRs) (see example in table below), the pipeline itself becomes an evidence producer for formal evaluation. Instead of treating Common Criteria as a separate compliance effort, organizations can integrate evaluation requirements directly into development operations. This dramatically reduces friction between engineering and accreditation communities while simultaneously improving evidence quality. Most importantly, it allows assurance to evolve at the same speed as software.

From Static Accreditation to Continuous Authorization

Perhaps the most transformative shift is occurring within certification and accreditation itself. Traditional Authority to Operate (ATO) models were designed around periodic review cycles. Systems were assessed, documented, and approved at discrete intervals. Risk acceptance was effectively frozen in time.

Modern environments no longer permit that assumption.

Cloud infrastructure changes continuously. Containers are redeployed hourly. Dependencies update automatically. Threat intelligence evolves daily. Under these conditions, a static accreditation package rapidly becomes obsolete. Continuous Authorization to Operate (cATO) represents the response to this reality.

Rather than relying on periodic compliance snapshots, cATO models use live operational telemetry to continuously evaluate risk posture. Security controls are monitored in real time. Vulnerabilities are correlated with mission impact. Configuration drift is detected automatically. Runtime behavior is continuously assessed against approved baselines. Risk scoring continuously combines exploitability, exposure, mission impact and supply chain risk. The accreditation boundary becomes dynamic rather than static.

Authorization evolves from a document into a continuously updated trust state.

The Emergence of Assurance-as-Code

The unifying concept behind this transformation is what many organizations are beginning to describe as Assurance-as-Code (AaC) Just as Infrastructure-as-Code (IaC) transformed infrastructure management into programmable automation, Assurance-as-Code transforms trust generation into machine-readable policy enforcement. In this model:

• policies become executable,
• compliance becomes measurable,
• evidence becomes automated,
• and accreditation becomes continuously computed.

An example AaC reference architecture is listed in the following table.

The architecture depends on a unified assurance data model linking requirements, code commits, supply chain attestations, testing evidence, vulnerabilities, operational telemetry, and accreditation status into a single traceable graph. This creates end-to-end traceability, explainable assurance, rapid audits, automated compliance, near-real-time accreditation.

Within such systems, a single software change can automatically:

• trigger security validation,
• regenerate SBOMs,
• update risk scores,
• refresh compliance mappings,
• validate supply chain integrity,
• and alter operational authorization status.

The software effectively maintains a continuously updated digital twin of its own trust posture.

Toward a Continuous Trust Architecture

The broader strategic implication is clear: the industry is moving away from certifying software as a static artifact and toward continuously validating software ecosystems as living systems. In the older model, assurance was retrospective. Organizations attempted to prove after the fact that systems were trustworthy. In the emerging model, trust becomes continuously observable. The critical integration layer is no longer documentation. It is machine-generated evidence, cryptographic provenance, operational telemetry, automated control mapping, and real-time risk analysis. The highest maturity model looks like this:

Organizations capable of integrating these disciplines into a seamless flow will achieve more than compliance efficiency. They will gain the ability to measure, manage, and adapt trust dynamically across increasingly complex digital environments. In a world defined by software-defined infrastructure, AI-generated code, and contested supply chains, that capability may ultimately become one of the defining characteristics of resilient digital systems.

Frontrunners Towards a Unified Software Assurance Architecture

While very few organizations publicly describe a fully unified “secure software assurance pipeline” end-to-end, several companies and government programs have assembled major portions of it in practice. The leaders tend to come from:

• hyperscale cloud providers,
• defense contractors,
• regulated infrastructure vendors,
• and high-assurance software companies.

What exists today is usually a convergence of DevSecOps, supply chain integrity, continuous compliance, formal assurance, and continuous authorization. Here are some of the strongest real-world examples.

1. Google — SLSA + Binary Authorization + Supply Chain Integrity 

Google is probably the clearest public example of a software supply chain assurance architecture operating at planetary scale. Google’s secure internal build systems:

• use hermetic/reproducible builds,
• isolate build environments,
• enforce provenance tracking,
• cryptographically sign artifacts.

Google co-created several tools for supply chain assurance and unified these with their build systems:

• SLSA (Supply-chain Levels for Software Artifacts),
• Sigstore,
• provenance attestation models.

Google uses Binary Authorization for continuous policy enforcement:

• only signed/verified artifacts deploy,
• policy gates enforce trust requirements.

Google has integrated different tools for continuous validation including tools that perform:

• fuzzing,
• static analysis,
• container scanning,
• runtime telemetry.

Google’s BeyondProd architecture ties:

• workload identity,
• software provenance,
• runtime authorization,
• deployment trust

into an operational trust model. Google has effectively transformed: “software build metadata” into “continuous cryptographic assurance evidence.” That build evidence is foundational to unified assurance pipelines.

2. Microsoft — SDL + Azure DevSecOps + Continuous Compliance

Microsoft has evolved from a traditional SDLC model into a highly automated cloud-native assurance ecosystem. It has integrated key elements of the SDL including:

• threat modeling,
• secure coding,
• security testing,
• release gates.

Azure DevSecOps pipelines continuously perform:

• SAST,
• DAST,
• secrets detection,
• dependency scanning,
• IaC validation.

Microsoft heavily invested after the SolarWinds incident into supply chain security to include:

• signed builds,
• provenance validation,
• SBOM generation,
• dependency governance.

For compliance, Azure environments map continuously into:

• FedRAMP,
• DoD IL frameworks,
• ISO 27001,
• SOC 2,
• NIST RMF controls.

Azure Policy and Defender provide continuous control monitoring, drift detection, and automated remediation. Microsoft’s major innovation was operationalizing compliance as continuously measured telemetry.

3. Palantir Technologies — Continuous ATO / Defense DevSecOps

Palantir became influential in defense circles because it helped operationalize Continuous ATO (cATO), automated accreditation, mission-integrated DevSecOps. Their model is based on a Unified Data Fabric where security evidence, operational telemetry, and accreditation data are integrated into one operational platform.

Instead of periodic RMF packages, Palantir’s platform updates compliance evidence continuously, automates RMF control validation, and provides a near-real-time view of risk posture.

Palantir has been adopted for use in many high assurance and time-sensitive environments such as:

• defense,
• intelligence,
• tactical systems,
• disconnected edge environments.

Palantir’s approach is important because it demonstrates how operational telemetry, software assurance, and mission risk can be fused into a single trust architecture that can operate at the edge.

4. Lockheed Martin + Raytheon + Northrop Grumman

These defense primes are increasingly building integrated DevSecOps factories, RMF automation, and supply chain assurance platforms. Examples include:

• Platform One alignment,
• Iron Bank containers,
• hardened software factories,
• automated STIG validation,
• continuous vulnerability management.

Software factories include hardened CI/CD, signed containers, approved dependency chains, and automated testing. Pipeline evidence maps directly into NIST RMF controls, POA&M tracking, and security control inheritance. Continuous monitoring involves integration of several tools such as SIEM and XDR along with Kubernetes telemetry to feed runtime policy enforcement.

Most details of these integrators’ capabilities remain classified or proprietary, but defense modernization programs clearly point toward unified assurance architectures.

5. U.S. Department of War — Platform One / Iron Bank / cATO

This is arguably the most explicit government attempt to operationalize unified software assurance. Platform One provides:

• hardened DevSecOps pipelines,
• accredited CI/CD environments,
• reusable security controls,
• container hardening,
• continuous monitoring.

Iron Bank is a repository of hardened containers, signed images, continuously scanned artifacts.

The DoW’s continuous authorization approach ties pipeline evidence, runtime telemetry, vulnerability management, and operational controls into continuous accreditation workflows. Platform One essentially treats the pipeline itself as part of the accreditation boundary. That is a major conceptual shift for DoW.

6. GitLab — Compliance Pipelines as Product

GitLab provides one of the clearest commercial implementations of integrated DevSecOps, compliance-as-code, evidence collection, supply chain validation. The integrated features include

• pipeline security scanning,
• SBOM generation,
• dependency scanning,
• policy-as-code,
• audit evidence collection,
• compliance dashboards.

GitLab demonstrates how compliance artifacts can become native CI/CD outputs.

7. Red Hat — Trusted Software Supply Chains

Red Hat has focused heavily on Kubernetes-native trust chains, signed containers, provenance, software factory security, especially within OpenShift and regulated infrastructure. Some notable capabilities include:

• signed container ecosystems,
• SBOM management,
• policy enforcement,
• admission control,
• continuous scanning,
• supply chain attestation.

What None of Them Have Fully Solved Yet

Even the most advanced organizations still struggle with:

No company has completely solved fully autonomous continuous assurance. But several are clearly converging toward it. The organizations closest to a true unified assurance pipeline share these pattern traits:

1. Everything Generates Evidence – Every pipeline action creates machine-readable trust metadata.

2. Provenance Is Cryptographically Verifiable – Artifacts are signed and traceable.

3. Security Policies Are Automated – Human approvals become policy gates.

4. Compliance Is Continuous – Controls are measured continuously rather than periodically (i.e., zero trust).

5. Runtime Telemetry Feeds Accreditation – Operational behavior affects trust status dynamically (i.e., zero trust).

6. The Pipeline Becomes Part of the Trusted Computing Base – The CI/CD system itself becomes a security-critical asset.

In general, the most important observation is this: The industry is gradually collapsing the distinction between development, security, compliance, accreditation, and operational trust.

The future architecture is not: “build software, then certify it.”

It is: “continuously compute trust as the software evolves.”

That is the foundational idea behind a unified secure software assurance pipeline.

Where is your organization on the road to a Unified Software Assurance Architecture? Do you find existing SDL governance and trust frameworks up to the challenge of managing and measuring a dynamic risk posture? Give me your views. And thanks to my subscribers and visitors to my site for checking out ActiveCyber.net! Please give us your feedback because we’d love to know some topics you’d like to hear about in the area of active cyber defenses, artificial intelligence, authenticity, quantum cryptography, risk assessment and modeling, autonomous security, digital forensics, securing OT / IIoT and IoT systems, Augmented Reality, or other emerging technology topics. Also, email chrisdaly@activecyber.net if you’re interested in interviewing or advertising with us at Active Cyber™.