In August 2022, the Enduring Security Framework (ESF) — a public-private working group led by the NSA, CISA, and the Office of the Director of National Intelligence — published the first installment of a three-part software supply chain security series, "Securing the Software Supply Chain: Recommended Practices Guide for Developers." It was the developer-facing volume; a suppliers' guide followed in October 2022 and a customers' guide in November 2022. The series arrived roughly 15 months after Executive Order 14028 (May 2021) made supply chain security a federal procurement requirement, and less than two years after the SolarWinds compromise showed how a single poisoned build pipeline could reach thousands of downstream organizations. Unlike a compliance checklist tied to a specific regulation, the ESF developer guidance is a synthesis of practices — securing the development environment itself, protecting the code before and during build, and verifying what ships — aimed squarely at the people who write and merge code, not just the security team that audits it afterward. Four years later, with SLSA, in-toto, and Sigstore now mainstream tooling, it's worth revisiting what the guidance actually asks for and how much of it teams have operationalized.
What does "securing the development environment" mean in practice?
It means treating developer workstations, CI runners, and build servers as part of the attack surface, not just the code they touch. The ESF developer guidance groups this under protecting the environments where code is written, reviewed, and built — separating build infrastructure from general-purpose developer laptops, enforcing multi-factor authentication on source control and CI systems, and limiting who can modify build scripts or pipeline configuration without review. This isn't hypothetical: the 2020 SolarWinds incident involved an attacker inserting malicious code directly into the Orion build process, and the 2021 Codecov Bash Uploader compromise persisted for roughly two months because a modified CI script silently exfiltrated environment variables — including secrets — from every customer pipeline that ran it. Both incidents targeted the build environment rather than a merged pull request, which is exactly the gap this section of the guidance addresses. A code review that never sees the CI script that actually executes doesn't catch either class of attack.
Why does the guidance treat credential and secrets management as a build-pipeline problem, not just a coding problem?
Because build pipelines routinely hold more privileged credentials than the application code they build — deploy keys, cloud IAM tokens, package-registry publish tokens — and those credentials are frequently the actual target. The guidance calls for short-lived, scoped credentials over long-lived static ones, and for keeping secrets out of source control and CI logs entirely. GitGuardian's 2024 State of Secrets Sprawl report found 12.8 million secrets exposed in public GitHub commits during 2023, a 28% year-over-year increase, with API keys and database credentials the most common categories found — and pipeline-embedded secrets are a subset of that same failure mode, just harder to see because they live in private CI logs rather than public repos. Rotating a leaked secret after the fact is damage control; the guidance's point is that a pipeline built around ephemeral, workload-scoped credentials (OIDC federation to cloud providers rather than static access keys, for instance) removes the long-lived secret from the equation before it can leak.
What does the guidance say about verifying where your code and dependencies actually came from?
It calls for provenance: cryptographic evidence of what was built, from what source, by which pipeline, using which inputs — not just a version number in a manifest. This is the same problem SLSA (Supply-chain Levels for Software Artifacts), developed by Google and now an OpenSSF project, formalizes into four levels, and that Sigstore's keyless-signing model (Fulcio-issued short-lived certificates, logged to the public Rekor transparency log) makes practical without asking every developer to manage a private key. The guidance's emphasis on knowing your dependencies' provenance also anticipates a threat that materialized two years later: the March 2024 xz-utils backdoor (CVE-2024-3094), where a maintainer account that had earned trust over roughly two years inserted an obfuscated backdoor into a widely-used compression library, discovered only because a Microsoft engineer noticed anomalous SSH login latency. Provenance attestation wouldn't have stopped a trusted maintainer from committing malicious code, but it does make the build steps that produced the artifact auditable after the fact — which is precisely the gap the guidance is closing.
How does the guidance connect to SBOMs, and has that requirement gotten stricter since 2022?
The developer guidance treats component inventory — knowing exactly what's in your build, direct and transitive — as a prerequisite for every other recommendation in it, because you cannot vet, patch, or attest to what you haven't enumerated. Executive Order 14028 pushed federal software vendors toward SBOMs and standardized attestations, and CISA spent the following years refining that guidance, including 2023 minimum-elements clarifications. That federal mandate has since loosened rather than tightened: in January 2026, OMB rescinded the memos requiring agencies to collect a standardized self-attestation form from vendors, shifting to an agency-by-agency risk-based approach where SBOM requests are discretionary rather than uniform. The guidance's underlying premise hasn't changed, though — you still can't vet, patch, or attest to a component you haven't enumerated — and what's actually changed since 2022 is tooling maturity, not the policy tailwind: CycloneDX and SPDX both reached format versions with native build-tool integration, and SBOM generation moved from a manual, point-in-time exercise to something CI pipelines produce automatically on every build. A stale SBOM from six months ago answers yesterday's question; the guidance's underlying goal — knowing what's in your software right now — only holds if the inventory updates as fast as your dependencies do.
A practical checklist based on the guidance
- Separate build infrastructure from developer endpoints; enforce MFA and least-privilege access on source control, CI, and artifact registries.
- Require review and audit trails for any change to build scripts, pipeline YAML, or CI configuration — not just application code.
- Replace long-lived static credentials in pipelines with short-lived, workload-scoped tokens (OIDC federation to cloud providers where available).
- Scan for secrets in source, git history, and CI logs — not just the current HEAD — and verify findings before treating them as urgent.
- Generate a signed SBOM (CycloneDX or SPDX) on every build, not on a quarterly cadence.
- Attach build provenance (SLSA-style) to release artifacts so consumers can verify what pipeline produced them and from what source.
- Re-scan shipped software continuously against new CVE and advisory feeds — a clean build today doesn't mean a clean artifact in three months.
How Safeguard helps operationalize this guidance
The ESF guidance describes outcomes — provenance you can prove, secrets that never leak into a pipeline, an inventory that's actually current — without prescribing a single toolchain, which is where most teams stall. Safeguard's attestation and signing pipeline produces SLSA Provenance v1, CycloneDX and SPDX SBOM, and vulnerability-scan attestations for every build, signed via Sigstore's keyless Fulcio/Rekor flow or traditional X.509/Notation for regulated environments, so "prove what built this artifact" becomes a CI step rather than a quarterly audit exercise. Secrets scanning covers source, git history, container layers, and build logs, and verifies each finding against the issuing service — AWS sts:GetCallerIdentity , GitHub's /user endpoint, and similar checks — before flagging it as live, so teams triage real leaks instead of pattern-match noise. And because continuous scanning re-evaluates every SBOM and repository against new CVE, KEV, and EPSS data as it lands — typically within minutes of publication — the inventory the guidance calls for stays current instead of degrading into a stale snapshot the moment the next dependency update ships.