Why it has leverage
One decision covers every release path.
It turns source, build, signing, and release controls into an enforced outcome: unverifiable software does not run.
Stop supply
chain attacks.
A short field manual for making software release paths harder to poison—and easier to verify.
Start with one deployment rule. Use six field notes for everyday decisions. Keep the twelve controls as a checklist.
01Source
02Dependencies
03Build
04Release
05Runtime
If you do one thing
ONE CONTROL // MAXIMUM COVERAGE
Highest-leverage single move
Verify provenance at the deployment gate.
Plain English
Only ship code when you can prove where it came from and how it was built.
Production accepts only the exact artifact whose signed evidence proves an approved source and trusted builder produced it.
DEFAULT // REJECTWhat it cannot prove
Provenance is not a safety verdict.
It proves where and how software was built. It does not prove the code has no vulnerabilities or that every approved person and platform is benign.
From recent practice
SMALL DECISIONS // REUSABLE HABITS
Six things that helped in the real world.
These are generalized field notes from recent engineering and infrastructure work. The sources validate each practice; the personal details are intentionally kept private.
01Field note
Read before you run
What happenedBefore running an unfamiliar project, I checked its install scripts, dependency sources, and expected network destinations first.
Make it a habitTreat installation as code execution. Inspect first, use isolation, and allow only the scripts and network access the project needs.
02Field note
Verify the exact thing
What happenedDuring a trusted security tool’s supply-chain incident, I checked the exact version and digest instead of trusting the project name or “latest.”
Make it a habitPin executable inputs to a full commit SHA or digest, then compare that exact identity with the incident report.
03Field note
A tag is not a release
What happenedWhen a tag existed but the release workflow had not completed, I treated the release as missing—not mostly done.
Make it a habitVerify the outcome: artifact digest, completed workflow, signature, and provenance. A label is not evidence.
04Field note
Stop at the vault
What happenedDuring a signing-key rotation, automation paused at the secret boundary until the expected revision, identity, and file permissions were verified.
Make it a habitKeep trust-root changes deliberate. Separate build code from signing authority and prefer short-lived, narrowly scoped credentials.
05Field note
Make the safe path reusable
What happenedI moved repeatable release checks—immutable tags, manifests, signatures, and hashes—into one shared release pattern instead of relying on memory.
Make it a habitCreate one paved release path with secure defaults. If required evidence is missing, the shared path should fail closed.
06Field note
Default to locked
What happenedFor a domain transfer, I unlocked the domain only for the transfer window and confirmed the lock afterward.
Make it a habitApply the same shape to automation: locked or read-only by default, narrow elevation for one task, then verify that access ended.
The twelve controls
SOURCE → RUNTIME → RECOVERY
A checklist, not a maturity model.
Start with control 01. Add the others to make its evidence more trustworthy and recovery faster.
01Enforce
Start here
Gate production on verified provenance
Plain EnglishOnly ship code when you can prove where it came from and how it was built.
Reject an artifact unless its digest, source, build definition, builder identity, and signed provenance match policy.
02Source
Protect the source of truth
Plain EnglishGuard the files and settings that decide what gets built.
Require strong authentication and review for source, workflow, release-policy, branch, and tag changes.
03Inputs
Pin every executable input
Plain EnglishUse the exact tool or dependency version you already checked.
Pin actions, images, installers, and toolchains by full commit or digest—not a floating tag or version range.
04Inputs
Review dependency change
Plain EnglishStop and look before adding new third-party code.
Treat a new package, owner, maintainer, install script, or unusual release as a new trust decision.
05Inventory
Generate a release SBOM
Plain EnglishKeep a parts list for every release.
Create an SPDX or CycloneDX inventory from resolved release inputs and bind it to the artifact digest.
06Build
Isolate every build
Plain EnglishGive every build a clean room.
Use a fresh environment, prevent cross-run influence, and keep signing material away from user-controlled build steps.
07Identity
Shrink workflow authority
Plain EnglishGive automation only the access it needs, only while it needs it.
Default tokens to read-only and use short-lived, job-scoped identity for the smallest necessary permission set.
08Release
Build once; promote by digest
Plain EnglishTest once, then ship those exact same bytes.
Move the same immutable artifact through test, staging, and production. Do not rebuild it per environment.
09Evidence
Carry signed evidence
Plain EnglishKeep the receipts attached to the code.
Attach provenance, SBOM, policy results, and source revision to the exact artifact they describe.
10Assure
Reproduce what matters
Plain EnglishMake sure someone else can rebuild the important stuff.
Independently rebuild critical releases and compare digests to expose undeclared inputs or a compromised builder.
11Operate
Detect trust drift
Plain EnglishKeep checking—trusted things can change.
12Recover
Rehearse a poisoned release
Plain EnglishPractice getting bad code out before it happens for real.
Practice tracing, revoking, rebuilding, rolling back, and notifying before a real compromise forces the sequence.
Start today
Three changes. One release.
Pick one production service and make the full path visible before trying to fix everything at once.
Check the evidence- 01
Look before you run
Before installing a new tool or dependency, check what it will execute and where it will connect.
- 02
Use exact versions
Replace one floating version such as “latest” with the exact commit or image you already checked.
- 03
Test the block
Try shipping code from the wrong place or with changed contents. Your system should stop it.
Source index
PRIMARY GUIDANCE // OPEN STANDARDS
Check the evidence.
Every recommendation above links to its closest source. This smaller index collects the references most useful for understanding and implementation.
Framework
What good looks like
Industry specificationSLSA v1.2 — Guiding principlesMakes the case for trusting fewer platforms and automatically verifying their artifacts.Industry specificationSLSA v1.2 — Verifying artifactsCovers verification of signatures, digests, builder identity, source, and build parameters.Industry specificationSLSA v1.2 — Build TrackDefines provenance, hosted builders, and hardened build environments.Federal frameworkNIST SP 800-218 — SSDF 1.1Lifecycle-wide practices for protecting software, producing secure releases, and responding to problems.Pipeline guidanceNIST SP 800-204DStrategies for integrating software supply-chain assurance into CI/CD pipelines.
Practice
How to apply it
Package manager documentationnpm Docs — ScriptsShows which lifecycle scripts can execute during npm install and npm ci.Platform guidanceGitHub — Secure use referenceRecommends pinning third-party actions to a verified, full-length commit SHA.Identity guidanceGitHub — OpenID ConnectUses short-lived, job-scoped credentials instead of duplicating long-lived cloud secrets.Implementation guideGitHub — Enforce artifact attestationsA concrete example of rejecting deployments without provenance from an approved source.Assessment modelOpenSSF Scorecard — ChecksAutomated checks for dependency pinning, token permissions, reviews, and release hygiene.
Evidence
Inventory, incidents, and recovery
Primary incident reportAqua Security — Trivy supply-chain incidentA concrete example of why exact versions, action SHAs, and container digests matter.Plain-language explainerGitLab — The ultimate guide to SBOMsA readable introduction to software bills of materials and how teams use them.Government guidanceCISA — SBOM Resources LibraryGuidance covering SBOM creation, formats, sharing, and operational use.Verification practiceReproducible BuildsDefines how independent parties can recreate bit-for-bit identical artifacts.Response frameworkNIST SP 800-61 Rev. 3Current recommendations for integrating incident response and recovery into risk management.
Built to be challenged
OPEN DOCTRINE // VERSIONED EVIDENCE
Security guidance should be inspectable and corrected in public.
This is an opening draft. The intended next step is a public repository for issue reports, counterexamples, implementation notes, and versioned releases.
Repository publication // next