Compliance as code in AppSec: where ASPM still falls short

At a glance

What this is: OXSecurity argues that compliance as code in AppSec is becoming necessary as cloud-native delivery expands, but many ASPM approaches still fall short on full lifecycle visibility and prioritisation.

Why it matters: For IAM, NHI, and DevSecOps practitioners, the issue is whether security evidence, vulnerability context, and governance signals remain continuous enough to support reliable control decisions.

Context

Compliance as code is the attempt to make security and regulatory controls part of the delivery process rather than an after-the-fact audit exercise. In application security, that means using automated checks, policy evidence, and vulnerability context to keep pace with cloud-native release cycles without forcing teams back into manual review.

The governance gap is not simply whether teams have tools in place. It is whether those tools create continuous visibility from code to cloud, preserve enough context to prioritise risk, and support evidence collection that stands up to audit without slowing delivery. Where applications touch sensitive data or delegated access paths, that same visibility problem becomes an identity and trust problem too.

Key questions

Q: What breaks when open source licence compliance is not built into the AppSec pipeline?

A: Manual review breaks first because it cannot keep up with continuous delivery, transitive dependencies, or generated code. The practical result is that restrictive licence terms can surface after the software is already near release, forcing rework, legal escalation, or blocked shipment. The control failure is late discovery, not lack of policy language.

Q: Why do SBOMs alone not solve application compliance risk?

A: An SBOM tells you what components are present, but it does not explain how the build was governed, which changes were approved, or whether the pipeline preserved enough context to prioritise the real risk.

Q: How do security teams know whether ASPM is improving control effectiveness?

A: They should look for continuous evidence across the delivery chain, faster risk triage, fewer manual audit reconstructions, and clear linkage between findings, approvals, and remediation outcomes.

Q: Which matters more for DevSecOps governance, SBOM coverage or pipeline traceability?

A: Pipeline traceability matters more when the goal is compliance as code. SBOM coverage is useful, but without provenance and workflow evidence it cannot show how risk moved through the delivery process.

Technical breakdown

Why compliance as code breaks down in AppSec pipelines

Compliance as code works only when policy, telemetry, and evidence move at the same speed as delivery. In practice, application teams often stitch together scanners, ticketing, SBOM data, and audit records across separate systems, which creates blind spots between build, deploy, and runtime. That fragmentation is why many ASPM approaches can find issues but still fail to show whether the organisation has a complete control story across the software lifecycle. The core technical problem is not lack of checks, but lack of continuous control continuity.

Practical implication: treat pipeline fragmentation as a governance defect, not just a tooling issue.

What SBOMs reveal and what they still miss

An SBOM inventories software components and versions, which is useful for exposure mapping and vulnerability correlation. But a component list does not explain how the software was assembled, what policies governed the pipeline, or whether compensating controls were present when the build was promoted. That is why the article’s PBOM idea matters as a governance concept: it extends inventory thinking into process and procedural traceability. For AppSec and compliance teams, the technical challenge is correlating component risk with build context, not just counting dependencies.

Practical implication: use component inventories as one input, not as proof of control effectiveness.

Why continuous monitoring matters more than point-in-time audits

Compliance regimes increasingly expect organisations to demonstrate that controls remain effective over time, not just at a single assessment point. Continuous monitoring closes the gap between a secure build at release time and a drifting runtime reality after deployment. In application security, that means monitoring changes in dependencies, findings, policy exceptions, and remediation status as part of the same evidence chain. Where ASPM is working properly, it should help convert security posture into a live governance signal rather than a static report.

Practical implication: align monitoring outputs to control evidence so audit preparation does not become a separate manual project.

Threat narrative

Attacker objective: The objective is to exploit weak application governance so vulnerable software reaches production and creates both security and compliance exposure.

1. Entry occurs through cloud-native application delivery pipelines where insecure components, weak build controls, or untracked changes introduce application risk before release.
2. Credential or trust abuse is possible when pipeline context, dependency provenance, and runtime evidence are not linked closely enough to show what was approved versus what was deployed.
3. Impact follows when organisations cannot prioritise exposed vulnerabilities quickly enough or cannot prove compliance under regulatory scrutiny, leaving data and governance exposure at the same time.

Breaches seen in the wild

• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

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

Compliance as code is now a control architecture problem, not a documentation problem. The article correctly frames the pressure point as continuous evidence across delivery rather than one-off audit artefacts. For modern AppSec, the decisive question is whether controls can remain machine-readable and traceable from build to runtime without introducing manual bottlenecks. Practitioners should treat compliance evidence as an operational output of the pipeline, not a spreadsheet produced after the fact.

Application governance now depends on traceability across the software supply chain. An SBOM helps identify what went into a build, but it does not by itself prove how risk was introduced, accepted, or contained. That gap is why lifecycle traceability matters more than component enumeration alone, especially where cloud-native releases move quickly. Teams should use the build chain as the unit of governance, not the individual scanner result.

As application security becomes more automated, identity and trust assumptions inside the pipeline become more visible. When tools, services, and workflows exchange authority across code, build, and deployment stages, the governance challenge starts to resemble non-human identity control even if the article does not name it that way. The organisation needs to know which systems are allowed to speak for which build stage, for how long, and under what evidence standard. Practitioners should align pipeline governance with machine identity and access scope thinking.

Pipeline governance debt: the accumulated gap between what compliance claims and what the delivery system can actually evidence. This is the hidden risk in many ASPM deployments. If visibility, provenance, and prioritisation are not unified, the organisation can look compliant in reporting while remaining exposed in execution. Practitioners should define control ownership around that evidence gap before it becomes an audit finding or breach amplifier.

What this signals

Pipeline governance debt: many organisations will discover that the hardest part of compliance as code is not detection but evidence continuity. When build, deployment, and runtime signals live in separate systems, compliance becomes a reconstruction exercise instead of an operating model.

As ASPM matures, practitioners should expect more pressure to connect application security evidence to broader governance controls, including software provenance, change management, and exception handling. The practical test is whether a security team can explain a risky release in minutes, not days, using the data already produced by the pipeline.

For practitioners

• Map compliance controls to delivery stages Assign policy, evidence, and exception ownership to source, build, test, deploy, and runtime stages so audit artefacts are produced continuously rather than assembled later.
• Correlate SBOM data with build provenance Use component inventory together with pipeline context so teams can tell whether a vulnerable dependency was introduced knowingly, inherited, or hidden by process drift.
• Separate detection from prioritisation Require a risk context layer that ranks findings by exploitability, exposure, and business impact instead of treating every finding as equally urgent.
• Keep compliance evidence machine-readable Store control outputs, approvals, and remediation status in forms that can be queried by auditors and security teams without manual reconstruction.
• Test incident response inside the pipeline Validate that build and deployment teams can trace a bad artefact back to its source and freeze promotion before the issue spreads into production.

Key takeaways

• Compliance as code in AppSec only works when control evidence is produced continuously across the delivery lifecycle, not assembled after release.
• SBOMs help inventory software components, but they do not by themselves explain build provenance, approval context, or control effectiveness.
• Practitioners should focus on traceability, evidence continuity, and risk prioritisation so ASPM supports both security operations and audit readiness.

Key terms

• Compliance-as-code: A compliance model that treats policies, reviews, and evidence as versioned operational artefacts rather than static documents. The practical aim is to make governance traceable and repeatable, with the same discipline used for software change management applied to control ownership and audit readiness.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• 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.
• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security practitioners connect identity controls to the broader governance demands that modern delivery pipelines create.