Hardening

Supply Chain Security: Sigstore Signing and Real SBOMs in CI/CD

Por Equipe Basilisk ·

How Basilisk ships cosign, SLSA, and CycloneDX across real pipelines to blunt SolarWinds-style attacks, XZ Utils backdoors, and dependency confusion.

When the XZ Utils backdoor (CVE-2024-3094) nearly reached stable Linux distros in March 2024, it made one thing painfully clear: signing a GitHub tag no longer counts as supply chain security. The software supply chain has become priority real estate for attackers because a single compromised maintainer pushes malicious code to millions of hosts within hours. At Basilisk OffSec we sit on both sides: we simulate attacks against client pipelines and help teams close the doors we walk through. This post consolidates what we actually deploy in production CI/CD using Sigstore cosign, SLSA level 3, and CycloneDX SBOMs, with bias toward pragmatism over compliance theater.

Step one is abandoning the long-lived private signing key sitting in a secret manager. Cosign keyless uses OIDC from GitHub Actions, GitLab CI, or Buildkite to mint an ephemeral certificate via Fulcio, valid for 10 minutes, and records the signature in Rekor, an append-only transparency log. That eliminates a whole category of signing key leaks, which was the pivot in the 2021 CodeCov incident. A typical workflow has three jobs: reproducible build, sign with cosign sign --yes, and attest with SLSA Provenance v1.0 predicate. On client projects we measured a 90 percent reduction in credential rotation time after migrating from PGP keys to keyless, and that ties directly into what we discuss in AppSec Shift-Left: SAST, SCA and Secrets Scanning Without Slowing the Team.

An SBOM is not an XML file no one reads. We generate CycloneDX 1.6 with Syft at build time, including SHA-256 hashes for every component, SPDX license, and supplier. The file travels next to the OCI image as a referenced artifact, not buried in an S3 bucket. To validate, we run Grype on the pull request and again in the background against the registry, because fresh CVEs land after merge. We pair this with policy-as-code through Kyverno or Conftest, blocking deploys when the SBOM carries a dependency above CVSS 7.0 without a documented exception. The same policy pattern reappears when we discuss Linux Server Hardening: Applying CIS Benchmark Without Breaking Production on production servers.

SLSA (Supply-chain Levels for Software Artifacts) became the reference framework after Google and OpenSSF standardized v1.0 in 2023. Level 1 only requires a versioned build script. Level 2 demands a hosted builder with signed provenance. Level 3, where we want to land for sensitive projects, requires build isolation, non-forgeable provenance, and hermetic builds. In practice we use GitHub Actions with the reusable workflow slsa-framework/slsa-github-generator, which produces an in-toto attestation signed by the runner itself via OIDC. An attacker who pwns a maintainer still has to break the GitHub builder, raising attack cost by orders of magnitude. For teams already wrestling with Dependency Confusion and Typosquatting: Practical Defense for Dev Teams, SLSA closes the publisher side.

Consumer-side verification matters as much as producer-side signing. On Kubernetes clusters we deploy the Sigstore policy-controller admission webhook with a ClusterImagePolicy that requires every image in production namespaces to carry a valid cosign signature, OIDC identity from basilisk.example, and SLSA attestation from the expected builder. We configure soft-fail in staging to avoid blocking emergency deploys, and hard-fail in prod. We also run cosign verify-blob on CLI binaries pulled to analyst workstations, wired into the workflow described in OPSEC for Security Researchers: Building a Personal Threat Model, because offensive teams download a lot of tooling from sketchy origins and that becomes an obvious vector.

Where reality breaks: non-reproducible builds, timestamps embedded in Go binaries, transitive dependencies that drift between git pull and CI, and maintainers who refuse 2FA. The pre-2.0 XZ project showed social takeover signals that no signature catches. That is why we recommend combining cosign+SLSA+SBOM with periodic critical-maintainer review, OpenSSF Scorecard running weekly across the top 50 dependencies, and red team exercises that simulate maintainer compromise, similar to engagements described in Adversary Emulation with Caldera and MITRE ATT&CK in a Corporate Lab and Purple Team in Practice: Building a Red vs Blue Feedback Loop. Technology without a maintenance process turns into expensive theater.

Practical takeaway: start small and measurable. This week, add cosign sign keyless to a single pipeline, generate a CycloneDX SBOM with Syft, and publish it as an OCI artifact next to the image. Next sprint, switch on mandatory cosign verify in one staging namespace. Within 30 days you have leverage to require SLSA L2 from vendors and evidence to respond when the next XZ lands, because another one is coming. The implementation cost on an existing pipeline runs about 2 to 4 engineer hours; the cost of skipping it is fielding a Sunday call asking whether you signed the container currently mining Monero in production.

Nenhum comentário ainda

Seja o primeiro a comentar.

Deixe seu comentário

Entre com sua conta Canverly para comentar. Você pode usar a mesma conta em qualquer site da rede.

Entrar com Canverly