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.
| Transition | Evidence to retain |
|---|---|
| Source to build | Reviewed revision, workflow definition and initiating identity. |
| Build to artifact | Artifact digest, builder and dependencies. |
| Artifact to signature | Signing identity and signing policy. |
| Artifact to deployment | Deployed digest, environment and approver. |
| Dependency to response | Affected 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
- NIST Secure Software Development Framework1.1, SP 800-218
- MITRE ATT&CK August 2026 release19.2, 2026-08-06