How should organisations use ASPM in CI/CD governance?

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.

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.

Related resources from NHI Mgmt Group

• Should organisations use the same governance model for CI/CD identities as for service accounts?
• Should organisations use agentic AI in CI/CD before strengthening governance?
• Should organisations use repository-level or hierarchical secret governance in CI/CD?
• How should security teams use IAST and RASP in NHI governance?