Compliance as code in AppSec: where ASPM still falls short

At a glance

What this is: This is an analysis of how Application Security Posture Management is being used to automate compliance, monitoring, and vulnerability management across cloud-native software delivery.

Why it matters: It matters because IAM, NHI, and broader security teams increasingly need evidence that development pipelines, service identities, and release processes are controlled continuously, not only at audit time.

👉 Read OXSecurity's analysis of compliance as code and ASPM in cloud-native development

Context

Application Security Posture Management is becoming a governance layer for teams trying to connect secure development, continuous monitoring, and compliance evidence across the software lifecycle. In practice, the gap is not simply tool coverage, but whether security controls can keep pace with cloud-native delivery without adding manual friction that developers work around. For identity and access programmes, that matters because application pipelines often depend on service identities, secrets, and privileged automation that must be governed consistently.

The article also points to a familiar control problem in modern DevSecOps: organisations can document policies faster than they can prove enforcement. That creates a compliance as code challenge, where auditability, vulnerability management, and incident readiness all depend on trusted telemetry from build through release. Where applications call external services or use machine identities, ASPM only helps if identity, secret, and access controls are visible inside that same governance model.

Key questions

Q: Where does compliance as code fail in application security programmes?

A: It fails when teams confuse evidence generation with control enforcement. If a pipeline can produce reports but not prove that security checks blocked risky releases, compliance becomes documentation rather than governance. The gap usually appears where release speed, exception handling, and ownership are fragmented across DevOps and security teams.

Q: Why do software bill of materials controls not fully solve application risk?

A: Because an SBOM tells you what components were shipped, not how the application was built, approved, or released. That matters when process failures, unreviewed dependencies, or automation credentials create risk that component inventory alone cannot expose. A useful programme pairs SBOM data with release provenance and control evidence.

Q: How should security teams integrate identity controls into DevOps pipelines?

A: Start by moving identity checks to the earliest practical stage in delivery, such as pre-merge, build, or pre-deploy gates. Focus on the controls that most often create operational risk, including service account permissions, secret exposure, and deployment credentials. The goal is to make secure identity behaviour the default path for release, not a separate review step.

Q: What should organisations do when ASPM findings are not being remediated?

A: They should assign a single accountable owner, define remediation SLAs, and link each finding to release gating or exception approval. Without that, dashboards accumulate risk rather than reducing it. The objective is to make unresolved findings visible in operational workflows, not only in audit reports.

Technical breakdown

How ASPM connects risk assessment to compliance evidence

ASPM platforms try to unify risk identification, policy checking, and reporting into one operational layer. They typically correlate code, dependencies, build outputs, and runtime signals so teams can link a control failure to a compliance obligation. The architectural value is not just speed. It is the ability to show that a control existed, was monitored, and produced evidence at the same point in the delivery pipeline. That matters most where manual testing cannot scale across frequent releases.

Practical implication: map each compliance requirement to a specific pipeline control and verify that the evidence is machine-readable, not spreadsheet-driven.

Why SBOMs help, but do not solve software supply chain governance

A software bill of materials inventories components and versions, which helps teams identify exposure to known vulnerabilities and track remediation. But an SBOM only describes what was shipped, not how the code was built, which processes approved it, or which exceptions were accepted. That is why some ASPM approaches extend into pipeline-level context, attempting to show the path from source to deployment. The key limitation is still governance completeness: component inventory alone cannot explain process risk or control drift.

Practical implication: treat SBOM data as a detection input, then pair it with change control and release governance to close the gap.

What continuous monitoring changes in DevSecOps accountability

Continuous monitoring turns compliance from a periodic review into an ongoing control state. In ASPM, that means configurations, findings, and policy exceptions can be tracked as the application changes, rather than waiting for a formal assessment window. This is useful for regulated environments, but only if the monitoring is tied to actionable ownership. Without accountable remediation paths, continuous visibility becomes a dashboard, not a control. Where service accounts or deployment tokens are involved, identity governance must be part of the same operational loop.

Practical implication: assign remediation ownership for every appsec finding, including secrets, tokens, and access paths used by the pipeline.

Threat narrative

Attacker objective: The attacker wants to compromise trusted software pathways so they can reach data, inject malicious behaviour, or inherit enterprise trust from a legitimate build chain.

1. Entry occurs through vulnerable software components, insecure build processes, or exposed pipeline dependencies that enter the development lifecycle.
2. Escalation follows when those weaknesses are not contextualised, allowing attackers to exploit trusted build artefacts, hidden dependencies, or unmanaged release paths.
3. Impact is realised through application compromise, unauthorised data access, or downstream trust erosion across environments that rely on the same software chain.

NHI Mgmt Group analysis

Compliance as code is becoming a control architecture problem, not a reporting problem. ASPM matters because it tries to connect build-time security evidence to regulatory obligations, but the real issue is whether the control model is complete enough to prove enforcement. When applications move quickly, partial evidence and manual attestation fail to keep up. Practitioners should treat compliance evidence as a live control output, not an after-the-fact document.

Software bill of materials data is necessary, but PBOM-style context is the real governance differentiator. A component list tells you what is present, but not how the software was produced or which process failures shaped the release. That is the named concept here: pipeline governance gap. It describes the space where inventory exists without enough process traceability to explain risk. Teams should build release governance around component data plus pipeline provenance, especially where regulated software changes frequently.

Application security and identity governance are converging in the delivery pipeline. Service accounts, API tokens, and automation credentials are part of the software control plane, not a side issue. If ASPM does not surface those identities, compliance remains incomplete because the build path itself can become a privilege path. Practitioners should expect appsec and IAM ownership to overlap more often in cloud-native environments.

Traditional testing alone does not solve policy enforcement at release speed. The article reflects a broader market shift toward always-on control validation because point-in-time checks cannot cover modern delivery cadence. That reinforces the need for policy-as-code, continuous evidence collection, and ownership models that survive team handoffs. The practical conclusion is that release governance must be measurable every time code changes.

What this signals

Pipeline governance gap: enterprises are moving beyond component inventory toward proof of process, because release velocity now outruns manual audit methods. For practitioners, that means control design has to cover provenance, approvals, and exception handling inside the same workflow that ships code. Where identity is involved, CI/CD credentials and service accounts should be governed as first-class production identities, not as implementation details.

ASPM will increasingly be judged by whether it reduces decision latency, not by how many findings it can display. That shifts programme design toward continuous evidence, mapped ownership, and policy enforcement that can survive repeated releases. Teams that still separate appsec telemetry from IAM governance will struggle to explain who authorised what, when, and with which credentials.

For practitioners

• Map compliance controls to pipeline evidence Tie each regulated requirement to a specific control in the build, test, and release flow, then define what evidence proves it operated as intended. Use the same control mapping for audits and for daily exception handling.
• Extend SBOMs with release provenance Do not stop at component inventory. Capture pipeline provenance, approval points, and exception records so you can explain how the software reached production and where trust was introduced.
• Treat service identities as part of AppSec scope Inventory the service accounts, tokens, and deployment credentials used by CI/CD and scanning tools, then require ownership, rotation, and revocation paths for each one.
• Create remediation ownership for every control failure Assign a named owner and service-level expectation to each finding so monitoring produces movement, not just visibility. Include secrets exposure, dependency risk, and policy exceptions in the same workflow.

Key takeaways

• ASPM is moving compliance from periodic review into continuous control evidence across the software delivery lifecycle.
• SBOMs improve component visibility, but they do not by themselves explain release provenance, process risk, or identity exposure.
• Security teams need to govern pipeline identities, remediation ownership, and policy enforcement together if they want compliance as code to work in practice.

Key terms

• 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 Governance Gap: The pipeline governance gap is the space between knowing which components exist and knowing how the software was produced, approved, and released. It appears when teams have inventory data but lack enough process traceability to prove enforcement, ownership, and exception handling across delivery stages.
• 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.

What's in the full article

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• How the platform frames ASPM workflows for compliance mapping, documentation, and monitoring across the SDLC
• What the PBOM approach adds to component visibility when teams need process-level context for release decisions
• How the article positions continuous monitoring for regulatory alignment without relying on manual reporting
• Why the source argues that traditional SBOM-only approaches miss parts of the software delivery risk picture

👉 OXSecurity's full post covers the ASPM workflow, PBOM context, and compliance mapping details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a common framework for governing the credentials and automation that modern pipelines depend on.