Client Portal
Access your security dashboard and reports
The software supply chain is the new attack surface. SolarWinds, Codecov, and thousands of dependency confusion attacks demonstrate that compromising build systems yields access to every downstream consumer. Cryptographic provenance establishes trust from source to deployment.
Executive Order 14028 (Improving the Nation's Cybersecurity) mandates software supply chain security for federal contractors. NIST SP 800-218 (Secure Software Development Framework) establishes baseline practices. OMB M-22-18 requires SBOM provision for software sold to federal agencies.
Organizations selling to the U.S. government must demonstrate secure development practices including: build environment hardening, provenance attestation, dependency scanning, and cryptographic signing of all artifacts.
Code signing traditionally answered a narrow question: "Was this binary produced by the claimed publisher?" Modern supply chain security demands broader provenance: "Was this artifact built from the claimed source, using the claimed build process, with all dependencies verified, in a tamper-evident environment?"
The SLSA framework (Supply-chain Levels for Software Artifacts) codifies these requirements into graduated assurance levels. SLSA Level 1 provides basic provenance documentation; Level 3 requires hardened build platforms with non-falsifiable provenance; Level 4 demands two-party review and hermetic builds. Each level represents increasing resistance to supply chain attacks.
Sigstore operationalizes these principles through keyless signing—ephemeral keys generated at build time, backed by identity from OIDC providers, with signatures recorded in an immutable transparency log (Rekor). This eliminates key management overhead while providing stronger guarantees than traditional code signing.
Traditional code signing suffers from key management complexity: private keys must be generated securely, stored in HSMs, rotated periodically, and revoked when compromised. Key compromise invalidates all previously-signed artifacts; key loss prevents future signing. Sigstore eliminates this burden through keyless signing.
# Sign a container image (keyless) $ cosign sign --yes ghcr.io/myorg/myimage:v1.0.0 Generating ephemeral keys... Retrieving signed certificate from Fulcio... Pushing signature to registry... Uploading to transparency log (Rekor)... tlog entry: https://rekor.sigstore.dev/api/v1/log/entries/... # Verify signature $ cosign verify \ --certificate-identity "builder@myorg.iam.gserviceaccount.com" \ --certificate-oidc-issuer "https://accounts.google.com" \ ghcr.io/myorg/myimage:v1.0.0 Verification: PASSED
The SolarWinds breach (discovered December 2020) represents the canonical supply chain attack against software build systems. Russian state actors (APT29) compromised SolarWinds' build infrastructure, injecting malicious code into the Orion software update process. The backdoored updates were properly signed with SolarWinds' legitimate code signing certificate—demonstrating that traditional signing is necessary but insufficient.
Attack Mechanism: The SUNSPOT implant monitored build processes for Orion compilation, replacing source files during build with backdoored versions. The malicious code was compiled into legitimately-signed binaries, bypassing all signature verification checks.
Prevention: SLSA Level 3+ requirements would have prevented this attack through: isolated build environments (no persistent access), non-falsifiable provenance linking binaries to source commits, and reproducible builds enabling independent verification that source produces expected output.
An SBOM provides a complete inventory of software components—direct dependencies, transitive dependencies, and their versions. When a vulnerability like Log4Shell (CVE-2021-44228) emerges, organizations with comprehensive SBOMs can immediately identify affected systems; those without face weeks of manual auditing.
| Format | Maintainer | Primary Use Case | Federal Acceptance |
|---|---|---|---|
| SPDX | Linux Foundation | License compliance, vulnerability tracking | ISO/IEC 5962:2021 |
| CycloneDX | OWASP | Security analysis, VEX integration | ECMA-424 |
| SWID | ISO/IEC | Software asset management | ISO/IEC 19770-2 |
OMB M-22-18 requires federal agencies to obtain SBOMs for all software purchases. CycloneDX and SPDX are the recommended formats per NTIA minimum elements guidance.
Software supply chain security has rapidly evolved following high-profile incidents.
Our engineers will evaluate your build systems and software delivery pipeline, providing a roadmap to SLSA compliance and federal procurement readiness.
Tell us about your security requirements. We respond within 24 hours.
Access your security dashboard and reports