Identify who can change each part of the release

Maintainers, registries, builders, signing systems, artifact stores and deployment identities hold different kinds of authority. Record the authorization and evidence at each transition. A signature connects an artifact to a key, but its meaning depends on who can use that key and what the verifier actually checks.

SSDF provides lifecycle practices, and current ATT&CK material can help examine threats to development and build systems. Apply that guidance to the actual pipeline. A hosted builder does not automatically make a customer’s workflow definitions or credentials trustworthy.

A workflow file can bypass application review

Suppose a fictional repository requires approval for application changes but permits an unreviewed workflow file to publish a release using release credentials. The application review has not covered the mechanism that builds and distributes the application.

Review who can change workflow paths, restrict the release context and check that the expected builder produced the artifact. Test unauthorized publication in an isolated repository and staging registry with disposable credentials. That keeps the test from distributing an unintended release or exercising production authority.

Retain the links between source and deployment

You should be able to start with a deployed artifact and trace it back, or start with the reviewed source and follow it forward. The following record keeps those connections available.

TransitionEvidence to retain
Source to buildReviewed revision, workflow definition and initiating identity.
Build to artifactArtifact digest, builder and dependencies.
Artifact to signatureSigning identity and signing policy.
Artifact to deploymentDeployed digest, environment and approver.
Dependency to responseAffected component, reachability and responsible owner.

Test rejection and rollback as well as the normal release

Confirm that the approved release succeeds and that an unexpected source, identity or digest is rejected. Then test rollback to an approved earlier artifact. Keep the deployment decision and policy in the record so the result explains what was allowed and why.

A software bill of materials lists components. It does not establish whether a vulnerable path is reachable, whether the defect is exploitable or whether a component is absent from the running system. Connect the inventory to actual deployments before deciding whether a finding applies.

Prepare for a dependency or credential that can no longer be trusted

Decide who can pause publication, revoke a credential, identify affected artifacts and rebuild from a trusted state. Exercise those decisions without distributing malware or disrupting downstream users. Keep external dependencies that could not be verified and the remaining trust assumptions visible in the result.

Sources and reference editions

  1. NIST Secure Software Development Framework1.1, SP 800-218
  2. MITRE ATT&CK August 2026 release19.2, 2026-08-06