CompOps shifts continuous compliance from audit drag to pipeline control

At a glance

What this is: Anchore argues that AI agents and modern release pipelines are outpacing manual compliance, making continuous evidence and policy-as-code central to software supply chain governance.

Why it matters: This matters because identity and governance teams now have to track who or what changed code, dependencies, and policy across CI/CD, not just review a quarterly evidence pack.

By the numbers:

• The EU Cyber Resilience Act requires an SBOM for every release, kept on file for 10 years.
• Compliance runway for new market entry can be cut from 12 months to 3.
• CompOps can scale compliance coverage 300% without adding headcount.

Context

Software supply chain governance breaks down when release velocity exceeds the pace of manual review, evidence collection, and control validation. In practice, that means compliance teams are asked to prove what shipped after the fact, while engineering teams are already moving on to the next build.

The identity angle is real here because AI agents, service accounts, build systems, and deployment automation are now acting inside the delivery chain. Once those non-human actors can read data, call APIs, pull dependencies, and write code, governance has to shift from periodic review to continuous control over machine actions.

The article is most relevant to organisations with fast-moving DevOps, regulated software delivery, or emerging AI-assisted engineering. Its starting position is increasingly typical, not exceptional, because release pipelines now change faster than many compliance operating models can evidence.

Key questions

Q: How should teams govern AI agents that can install dependencies?

A: Treat dependency installation as a privileged action that requires scoped authority, logging, and explicit approval for new packages. The agent should not inherit broad secrets or unrestricted registry access just because it can generate code. If the workflow must install, do it in a constrained environment with secret minimisation and dependency review before merge.

Q: Why does continuous compliance matter more than annual audit evidence?

A: Because modern release pipelines change faster than quarterly review cycles can reconstruct. Continuous compliance reduces the gap between what was deployed and what can be proven, which matters when regulators, customers, or security teams ask for evidence after the fact.

Q: What breaks when software compliance is still managed with spreadsheets and screenshots?

A: Teams lose control over provenance, timing, and reproducibility. Spreadsheets cannot reliably track transitive dependencies, screenshots do not prove runtime state, and manual evidence creates delays that let risky releases slip through before anyone can challenge them.

Q: Should organisations prioritize policy-as-code or SBOM automation first?

A: Policy-as-code should come first when the main problem is inconsistent enforcement, while SBOM automation should come first when the main problem is poor software inventory. Most mature programmes need both, but the sequence should reflect the biggest current governance gap.

Technical breakdown

Why manual compliance breaks in modern CI/CD

Manual compliance assumes a stable change window, a human reviewer, and an evidence trail assembled after release. Modern pipelines invalidate all three assumptions. AI agents and automation can create, modify, and ship code, dependencies, and configuration inside the same workflow step, which means the compliance question moves from 'what happened later?' to 'what was allowed to happen at commit, build, and deploy time?'. When evidence is generated after the fact, it is easy to miss the precise control state that existed when the artifact was promoted.

Practical implication: move governance checks into the pipeline stages where code, artefacts, and policy intersect.

How policy-as-code turns regulations into deterministic controls

Policy-as-code converts regulatory requirements into version-controlled rules that software can evaluate consistently. That matters because frameworks like the EU CRA, FedRAMP 20x, and security build standards increasingly require machine-readable, repeatable evidence rather than ad hoc screenshots. The useful mechanism is not just automation, but determinism: the same input should always produce the same PASS, FAIL, or WARN decision. This reduces interpretation drift between engineers, security, and audit teams, and it creates a traceable change history for control logic itself.

Practical implication: express release and evidence requirements as code so every build is assessed against the same rule set.

Why SBOMs and dependency scanning are now governance controls

An SBOM is more than an inventory list when software is assembled from third-party and transitive dependencies at scale. Paired with software composition analysis and vulnerability scanning, it becomes a governance layer that shows what entered the release, what risks were inherited, and what evidence an auditor can trust. This is especially important when AI-assisted development can introduce libraries or packages faster than a human can spot them. In that environment, dependency visibility is not a documentation exercise, it is a control boundary.

Practical implication: treat dependency visibility and SBOM generation as release gates, not post-release paperwork.

Threat narrative

Attacker objective: The attacker objective is to get malicious or risky software into production while the organisation lacks timely, provable evidence to stop it or prove compliance.

1. Entry occurs when an AI agent or developer workflow introduces a vulnerable dependency, misconfigured policy, or unreviewed code into the release stream.
2. Credential or trust abuse follows when automation and third-party tooling are allowed to pull packages, call APIs, and advance artefacts without sufficiently strong governance checks.
3. Impact appears when the organisation cannot reconstruct what shipped, what policy was violated, or whether a deployed component met regulatory and security requirements.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CompOps is a governance pattern for machine-speed delivery, not a reporting tweak. The article makes clear that the real failure is not a missing spreadsheet column but a compliance model that assumes humans will always be in the loop. Once AI agents and automation can influence code, dependencies, and deployment timing, governance has to be enforced where those actions occur. The practitioner conclusion is straightforward: evidence collection must become continuous, deterministic, and embedded in delivery.

Software supply chain evidence is becoming an identity problem as much as a control problem. When non-human actors can write code, pull dependencies, and trigger releases, the question is not just what shipped but who or what was authorised to ship it. That makes build systems, service accounts, and agent workflows part of the identity perimeter. The practitioner conclusion is to govern machine actions with the same lifecycle discipline applied to privileged human access.

Continuous compliance is now a release constraint, not an audit afterthought. The article's regulatory examples show that standards are converging on machine-readable, provable evidence instead of retrospective narratives. That direction rewards organisations that can answer control questions inside the workflow and penalises teams that still rely on quarterly evidence scrambles. The practitioner conclusion is to treat compliance latency as a delivery risk.

Spaghetti wiring is the right name for fragmented compliance architecture. The article describes a growing tangle of scripts, spreadsheets, and point GRC tools that each solve one framework but fail at cross-framework consistency. That creates governance drift, duplicated work, and a weak audit trail when multiple standards overlap. The practitioner conclusion is to rationalise evidence collection into one control plane rather than multiplying ad hoc integrations.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Continuous compliance is now a machine-identity governance problem. Once AI agents and build automation can introduce code or dependencies, the control question becomes who or what was authorised to move software forward. Security teams should expect release governance to merge with machine identity lifecycle management, especially where service accounts and agent workflows can alter production state.

The strongest programmes will treat evidence collection as a control plane rather than an audit byproduct. That shift aligns release operations, policy logic, and runtime monitoring around the same source of truth, which is the only sustainable way to manage fast-moving software supply chains.

For practitioners

• Embed policy checks at release gates Place deterministic controls at commit, build, artifact registry, admission, and runtime stages so violations are blocked where they occur, not after deployment.
• Generate SBOMs automatically for every build Produce machine-readable SBOMs for each release and retain them with the build artefact so auditors can trace exactly what shipped.
• Track non-human actors in the delivery chain Inventory AI agents, build service accounts, CI runners, and deployment credentials so you know which machine identities can change production state.
• Translate regulatory obligations into code Convert framework requirements into version-controlled rules that return PASS, FAIL, or WARN outputs developers can act on in their workflow.
• Replace quarterly evidence scrambles with continuous collection Capture compliance telemetry as part of normal delivery so evidence is always current when audit, procurement, or market-entry questions arrive.

Key takeaways

• AI-assisted delivery changes compliance from a retrospective audit exercise into a live control problem inside the pipeline.
• The article ties that shift to continuous evidence, policy-as-code, and machine-readable artefacts such as SBOMs.
• For practitioners, the practical move is to govern non-human actors and release gates with the same discipline used for privileged access.

Key terms

• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Continuous Compliance: Continuous compliance is the practice of keeping controls and evidence current as the environment changes, rather than proving compliance after a review cycle. For identity and NHI programmes, it means access, logging, and revocation must operate together in real time.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners translate non-human access risk into operational governance that stands up in regulated delivery environments.