What are the signs that a software release did not come from the approved CI/CD process?

The clearest signs are a release in the registry with no corresponding build log, missing tag or commit linkage, absent provenance metadata, or a publish event that does not match known workflow history. When those signals appear together, the artifact should be treated as suspicious until the team proves it came through the normal release path.

What evidence shows a release bypassed the approved pipeline?

A release that cannot be tied back to the approved CI/CD path usually fails basic traceability checks. The most important question is whether the artifact can be connected to a specific source commit, build job, and publish step without gaps. If that chain is broken, the organisation cannot reliably prove who built it, what inputs were used, or whether the release was altered after validation.

For that reason, release verification is not just a compliance exercise. It is a trust boundary around software supply chain integrity, and it becomes especially important when multiple teams, automated agents, or external registries can publish artefacts into the same environment.

Official control guidance on software provenance and system monitoring is discussed in NIST SP 800-53 Rev 5 Security and Privacy Controls, which is useful when teams need to define what evidence should exist before a release is trusted. In practice, many security teams first discover a bypass only after an unexpected artifact has already reached a registry or production lane.

How release provenance checks work in practice

The strongest indicator is a complete provenance chain. A normal release should have a build record, a source reference, a signed or otherwise verifiable artifact identity, and a publish event that matches the approved workflow history. When any one of those elements is missing, the release is not automatically malicious, but it is no longer self-proving.

Teams usually look for a cluster of mismatches rather than a single symptom. Common examples include a package version appearing in the registry without a corresponding pipeline execution, a release timestamp that does not line up with build activity, or artifact metadata that differs from the expected CI/CD output. A tag may exist, but if it does not point to the same commit used by the build, the release path is incomplete.

A registry entry exists with no matching build log or job ID.
The artifact hash does not match the build output recorded by the pipeline.
Provenance metadata, signing data, or attestation records are absent.
The publish event came from an account, runner, or automation path outside the approved workflow.
Versioning, commit, or tag references do not align with repository history.

These checks are strongest when they are automated and compared against known workflow expectations rather than manual memory. In larger environments, the practical problem is not only spotting a single suspicious release, but proving that every legitimate release leaves the same evidence trail. That is why supply chain integrity controls matter even when the immediate concern looks like ordinary change management. If the workflow does not preserve immutable build evidence, the organisation loses the ability to distinguish an approved release from a parallel publish path.

Where this guidance breaks down is in legacy pipelines or highly customised release tooling that does not preserve consistent build-to-publish records.

When the usual signs are ambiguous

Tighter release controls often increase operational overhead, requiring teams to balance traceability against delivery speed. That tradeoff matters because some releases will look incomplete for benign reasons, such as emergency hotfixes, migration work, or a temporary break in logging between systems.

Not every anomaly means compromise. A registry record with delayed metadata ingestion, a manually triggered release with incomplete annotations, or a rebuild after infrastructure failure can create the same surface symptoms as an unauthorised publish. The difference is whether the team can reconstruct the chain from authoritative records rather than relying on informal explanation.

There is also a genuine consensus gap in the industry around how much provenance evidence is enough for low-risk internal releases. Some teams treat signing and attestations as mandatory, while others accept a narrower evidence set for controlled environments. That variation is why the right standard is usually organisationally defined rather than assumed from the toolchain itself.

What matters most is consistency. If one release path preserves source, build, attestation, and publish data while another does not, the weaker path becomes the place where bypasses hide. That is especially true when release tooling is shared across teams, because a legitimate exception in one product line can become a reusable loophole in another.

Standards & Framework Alignment

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

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	16 — Application Software Security	Release provenance gaps indicate weak software build and publish integrity.
	8 — Audit Log Management	Release trust depends on complete and reliable workflow logging.
Recommendation — Enforce trusted build and release evidence for every software artifact before promotion. Retain immutable pipeline and publish logs to reconstruct every software release.
NIST CSF 2.0	PR.DS — Data Security	Artifact integrity and provenance protect software supply-chain trust.
	DE.CM — Security Continuous Monitoring	Missing logs and mismatched history are detectable monitoring signals.
Recommendation — Validate artifact integrity and provenance before allowing a release into production. Monitor build, sign, and publish telemetry for gaps that indicate release bypass.
MITRE ATT&CK	T1195 — Supply Chain Compromise	Unauthorised or altered releases are a supply-chain compromise pattern.
Recommendation — Map suspicious release patterns to supply-chain compromise and investigate publishing paths.

Practitioner Guidance

What to prioritise: Treat provenance gaps as an evidence problem first, not a label problem. The first task is to prove or disprove the release chain using build records, source linkage, and publish history before anyone debates intent.

What to verify: Confirm that the artifact hash, commit reference, tag, pipeline run, and publishing identity all line up. If any one of those is missing or inconsistent, the release should remain under exception handling until the gap is explained.

Common mistake: Teams often focus on whether the release “looks right” in the registry and overlook whether it can be independently reconstructed from authoritative records. A clean package name does not prove approved origin.

What practitioners underestimate: The hardest cases are not obviously rogue releases, but releases that entered through a valid system with a broken control path, because those are the ones most likely to be trusted too quickly.

Practitioner takeaway: The most reliable test is whether the release can be reconstructed end-to-end from immutable workflow evidence; if it cannot, trust should be withheld until the chain is proven.