Checkmarx Software Supply Chain Security

Checkmarx Software Supply Chain Security is the build-and-release governance product inside the Checkmarx One Supply Chain pillar. It implements SLSA (Supply-chain Levels for Software Artifacts) build provenance attestation, Sigstore-compatible code signing, SBOM lifecycle management, and supply-chain attack-surface visualization. Where Malicious Package Protection blocks dependencies before the build and SCA scans dependencies after the build, Software Supply Chain Security covers the build itself: what was built, by what pipeline, from what sources, with what reviewers, signed by what key.

SLSA alignment is the load-bearing capability for regulated programs. SLSA defines four levels of build provenance maturity, with SLSA Level 3 typically required for federal and high-assurance commercial programs. Checkmarx generates SLSA-compatible attestations as build artifacts, so a downstream consumer can verify that this binary came from this commit, built by this pipeline, with these source dependencies. EO 14028, NIST SSDF, and supply-chain mandates increasingly require this evidence; programs without it have to retrofit later.

Sigstore-compatible signing closes the loop. Build artifacts get signed with short-lived keys backed by an OIDC identity, signatures get logged to a public transparency log (Rekor) or a private equivalent, and consumers verify signatures before deployment. The pattern eliminates long-lived signing keys that get stolen and forgotten and replaces them with verifiable, ephemeral signing tied to the actual identity that built the artifact.

What breaks Software Supply Chain Security adoption is partial implementation. Programs that turn on SLSA attestation but skip signing, or generate SBOMs but never verify them downstream, or sign artifacts but do not enforce signature verification at deployment end up with documentation rather than enforcement. Merito's engagement implements the full chain: build provenance generation, signing, transparency log, SBOM lifecycle, and downstream verification. Without that, the program ships SLSA Level 1 documentation and calls it Level 3.

Merito has audited supply-chain governance programs that generated SBOMs nobody verified, signed artifacts nobody checked at deployment, and produced SLSA attestations that no downstream consumer ever read. The documentation existed; the enforcement did not. Software Supply Chain Security is useful only when the full chain runs end to end: attestation at build, signing with short-lived keys, transparency logging, SBOM attachment to artifacts, verification at deployment, and rejection of artifacts that fail the policy.

Merito recommends Software Supply Chain Security specifically when the program is subject to EO 14028, NIST SSDF, federal contracting requirements, or sector-specific supply-chain mandates. For programs without those drivers, the value is real but the urgency is lower; SLSA Level 1 or Level 2 is often a defensible baseline. Merito surfaces the actual compliance landscape during scoping rather than upselling SLSA Level 3 as a default.

Sigstore-compatible signing replaces long-lived signing keys, which are the single most common supply-chain incident shape. Programs that maintain RSA signing keys in HSMs and rotate them every two years are running on borrowed time; programs that use ephemeral keys backed by OIDC identity have already moved past that risk. The migration is not optional for high-assurance programs.