How should organisations use ASPM in CI/CD governance?

Use it to enforce security policy at merge time, not just to report after release. The strongest model is one where risky changes are flagged or blocked automatically, findings are mapped to the owning team, and remediation work flows into ticketing systems with enough context to act quickly.

Why ASPM Belongs at Merge Time, Not Just in Post-Release Reporting

ASPM is most effective in CI/CD governance when it acts as a decision point before code is merged, because that is where policy can still change the outcome. At that stage, teams can stop risky changes, route findings to the right owner, and avoid turning release-time reviews into a backlog of avoidable exceptions.

The practical shift is from passive visibility to enforceable governance. If ASPM only reports after deployment, it becomes a dashboard; if it is wired into merge controls, it becomes part of the change-management system that shapes what is allowed to progress.

That distinction matters most for pipeline controls, because merge-time policy can catch issues while the change is still cheap to fix. The same principle appears in SLSA, which treats build provenance and integrity as something to establish before artifacts are trusted downstream.

How to Structure ASPM Governance Across Owners, Findings, and Exceptions

Effective governance depends on clear ownership, not just detection. Findings need to map to the team that can actually remediate them, with enough context to understand whether the issue is a policy violation, an accepted exception, or a true release blocker.

That usually means pairing ASPM with routing logic that understands application, repository, and service ownership, then sending actionable findings into ticketing or workflow systems rather than leaving them in a security console. The goal is to make remediation part of normal delivery work, not a separate security-only queue.

It also means deciding which issues are non-negotiable at merge time and which can be time-bound exceptions. Without that distinction, teams either bypass the tool or treat every alert as noise. NHIMG’s CI/CD Pipeline Identity Security Guide is useful here because it ties policy enforcement to the identities and trust relationships that make pipeline decisions meaningful.

What Good ASPM Enforcement Looks Like in Practice

Good ASPM governance is measurable. You should be able to show that risky merges are blocked or flagged automatically, that exceptions require explicit approval, and that the same class of finding is handled consistently across repositories and teams.

A mature setup also avoids ambiguous handoffs. Developers should see the issue in the context of the pull request or merge request, security should see the policy decision, and ownership should be explicit enough that remediation work can be tracked without manual triage.

On the operational side, the best programs minimise drift between what ASPM reports and what delivery teams can act on. If a finding has no owner, no severity context, or no link to the failing control, it will usually be ignored. NHIMG’s Guide to the Secret Sprawl Challenge is relevant because the same workflow problem often shows up when secrets exposure is discovered but not routed into fast remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	CI/CD governance here hinges on pre-trust build integrity and provenance.
Recommendation — Establish trusted build provenance before artifacts are allowed downstream.
CIS Controls v8	CIS-14 — Security Monitoring and Defense	ASPM in pipelines needs continuous detection and governance over risky changes.
Recommendation — Centralize findings and alerts so risky changes are detected and acted on quickly.
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	Merge-time enforcement is change control for software delivery pipelines.
	AU-2 — Event Logging	ASPM governance depends on auditable records of findings, decisions, and exceptions.
Recommendation — Require approval and policy checks before changes are merged or released. Log policy decisions, overrides, and remediation outcomes for reviewability.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Pipeline governance needs controlled configuration of gates, rules, and exceptions.
Recommendation — Manage CI/CD security gates as controlled configuration with review and approval.

Practitioner Guidance

What to prioritise: Put merge-time enforcement ahead of report-only dashboards. If the policy cannot influence the merge decision, it is governance theatre rather than control.

What to verify: Check that each blocking rule has a named owner, a documented exception path, and a ticket or workflow destination that preserves the finding context. If a developer has to re-investigate the issue from scratch, the governance model is too weak.

What good looks like: Security findings are classified once, routed automatically, and either remediated or explicitly waived with expiry. Teams should be able to explain why a merge was blocked and what evidence would clear it.

Practitioner takeaway: ASPM works best in CI/CD governance when it reduces discretion at the point of change, while increasing clarity about ownership and remediation after the policy decision is made.