The Enduring Security Framework (ESF) is a public-private group working with NSA and CISA. Its software supply chain series has recommended practices for developers, suppliers and customers. For developers, the guidance aligns with NIST's Secure Software Development Framework: protect the organisation, protect the software, produce well-secured software and respond to vulnerabilities.
Who is the ESF?
The ESF is a cross-sector working group led by US government agencies together with industry partners. It publishes joint guidance on securing critical infrastructure. The software supply chain papers were produced after Executive Order 14028 asked for stronger software supply chain practices.
CISA hosts the suppliers and customers guides on its resources pages. Check the agencies' sites for the current developer edition before you cite a version in a policy, since documents are revised.
How does the guidance map to NIST SSDF?
The SSDF, NIST SP 800-218, groups practices into four sets:
- Prepare the organisation (PO): roles, training, toolchains and security requirements.
- Protect the software (PS): protect code from tampering and archive releases.
- Produce well-secured software (PW): design, review, test and reuse trusted components.
- Respond to vulnerabilities (RV): find, analyse and fix issues, then fix causes.
A developer reading any supply chain guide can use these four groups as a checklist. The ESF series expands on how to carry them out across source control, builds, dependencies and delivery.
What are the practical asks?
Paraphrasing across the guidance and the SSDF, the work falls into five habits.
Protect source and accounts. Require multi-factor authentication, review changes before merge and restrict who can push to release branches.
Harden the build. Build in a controlled, ideally ephemeral environment. Keep secrets out of build logs. Record what went into each build.
Know your components. Keep an inventory of dependencies. An SBOM is a machine-readable version of that list. Prefer maintained components and check their advisories.
Verify before release. Run static analysis, dependency scanning and tests. Sign release artifacts so recipients can check integrity.
Handle vulnerabilities. Have a way to receive reports, a target time to fix and a method to tell customers.
What does this look like in a week of work?
A constructed example. A team ships a command line tool. On Monday they turn on branch protection so releases need one reviewer. On Tuesday they move the release build from a developer laptop to a clean CI runner. Wednesday they generate a dependency inventory and find an unmaintained package. Thursday they replace it and add a scan step that fails on known exploited flaws. Friday they publish a security contact file and a fix policy.
Nothing exotic. Each step maps to an SSDF practice, and each leaves evidence.
Why do developers carry so much of this?
Developers choose dependencies, write build scripts and approve changes, so their daily decisions shape the supply chain more than any policy document. The practical consequence is that guidance only works when it lands inside the tools developers already use: the pull request, the pipeline and the package manager. A rule that lives in a PDF gets forgotten. A rule that blocks a merge with a clear message gets followed. Aim to put each SSDF practice you adopt somewhere automatic, and keep the written policy short enough to read in one sitting.
How to check or apply this
- Read SSDF practices PO, PS, PW and RV and mark each as done, partly done or missing for your team.
- Turn on mandatory review and multi-factor authentication for your source host.
- Move releases to a controlled build environment and keep build records.
- Generate and store an SBOM per release.
- Scan dependencies and code on every change, and decide which findings block a merge.
- Sign artifacts and publish a vulnerability reporting route.
Safeguard covers several of these steps with dependency and SBOM scanning, reachability analysis, pipeline gates and compliance automation that collects evidence for SSDF-style requirements. It supports your process. It does not certify you against anything.
Quick check
Is the ESF guidance mandatory?
No. It is recommended practice. Contract or regulatory requirements may reference related standards, so check what applies to you.
Do I need an SBOM to follow it?
An inventory of components is central to the guidance. An SBOM is a standard way to record and share it.
Sources
- Securing the Software Supply Chain: Recommended Practices Guide for Suppliers, CISA
- Securing the Software Supply Chain: Recommended Practices Guide for Customers, CISA
- NIST SP 800-218, Secure Software Development Framework, NIST
- Executive Order 14028 resources, NIST
Last reviewed: 18 October 2026.
