Guide to Implementing Software Supply Chain Security | Endor Labs

What it is

A vendor guide (Endor Labs) that lays out the components of a software supply chain security program and gives a practical rule set for each. Beyond the definitions, it includes concrete policy examples, a checklist of SBOM fields, and a control-point model for secrets. Each section ends in a product pitch, so the framing is vendor-flavoured.

What to do

Treat SAST and SCA findings differently. The page argues that breaking the build is reasonable for vulnerable first-party code. For OSS dependencies, teams need more flexibility, because a fix may not exist upstream or an upgrade may break unrelated things.

Prioritise dependency risk beyond CVSS. It names KEV (known exploitation), EPSS (likelihood of exploit) and reachability as the added signals. Its example policies:

• Comment on a PR if it introduces a new dependency risk where a patch is available, the vulnerable function is reachable from first-party code, and EPSS gives a chance of exploit in the next 30 days above 1%.
• Open a Jira ticket if a direct dependency is no longer maintained.
• Send a Slack message if a released application version has a new critical or high vulnerability.

Use admission policies on package health. Its examples are "disallow any component with a Security Score below 6 or an Activity score below 4" and "warn if a component lacks a high-reputation contributor". It also suggests running the same check in CI as a detective control in case developers bypass the preventive one.

Check SBOMs against the seven NTIA minimum elements:

1. Supplier name
2. Component name
3. Component version
4. Other unique identifiers
5. Dependency relationship
6. Author of SBOM data
7. Timestamp

The page cites Chainguard's finding that only 1% of SBOMs fully conform. It recommends both producing SBOMs and consuming suppliers' SBOMs, so that a Log4Shell-style disclosure can be matched to affected third-party services quickly. It pairs SBOMs with VEX to mark vulnerabilities as not exploitable when the vulnerable function is unreachable.

Scan for secrets at three control points:

• A deep scan of full commit history.
• A branch scan, either in the pipeline to block PRs or run supervisory-style without touching the pipeline.
• A pre-commit hook doing a changes-only check.

It recommends validating whether a detected secret is live, so the policy can act only on valid credentials and cut noise.

Catch undeclared Python dependencies. Many Python dependencies are not in the manifest, so manifest-based SCA misses them. The page describes a four-step method: treat source code as ground truth, correlate with package manager data, correlate with the file system, and flag discrepancies. This is relevant for AI/ML codebases.

Treat pipeline tooling as dependencies. Its CI/CD hardening has three parts: discover the tools, templates and actions the pipeline consumes (and flag over-privileged jobs), scan repository configuration against policy, and verify artifact signatures before components run. It points to the OWASP Top 10 CI/CD Security Risks, calling out insufficient flow control, inadequate IAM and insecure system configuration.

Sign and verify builds. It describes Cosign/Sigstore signing, verification against public keys, and provenance through a public, tamper-resistant log. Endor Labs positions its own signing as an alternative for teams that want signature privacy (the public Sigstore log is public) without running a private Sigstore. It uses SAML/OIDC to your identity provider, a pipeline binary or GitHub Action, and a single verification call at the admission controller.

Caveats

• Several statistics are vendor-sourced or dated. These include 95% of vulnerabilities in transitive dependencies (Endor Labs research), OSS at 70-90% of codebases, and the container figure from a 2021 Dell study. Check them before quoting.
• The threshold examples (Security Score below 6, EPSS above 1%) are illustrations, not recommended values.
• The AI security section is thin: policy on data types and model vetting, with no concrete controls beyond reviewing the model's construction and creator and using HuggingFace's security features.
• The container hardening section is descriptive only. It gives no commands or concrete steps.