Supply Chain Attacks Shift to Build Pipelines

The SolarWinds breach in 2020 served as a critical example of modern threats targeting build platforms, rather than directly compromising source code.

Malicious code was injected into the Orion software during its build process, illustrating how an attack can bypass typical security layers.

No developer machines or the source code itself were directly harmed, highlighting a sophisticated approach where software can be tampered with before reaching the consumer.

This incident proved that even robust application security can be undermined if the integrity of the build process is not guaranteed.

This high dependency on external code means developers frequently rely on upstream providers like Microsoft or Red Hat to deliver secure and untampered software.

The prevalence of open-source components introduces a significant blind trust problem, as the origins and integrity of a large part of any application are not directly controlled by the end-user organization.

Tag-based signing, such as using semantic versions like '1.0.0', provides human-readable labels but is inherently insecure due to its mutability.

Attackers can easily overwrite these tags to point to malicious artifacts, making it appear as though a trusted version has been deployed.

Digest-based signing, utilizing cryptographic hashes like SHA-256, is recommended as it verifies the exact content of an artifact, thereby preventing any unauthorized tampering.

Public tools like Rekor increase visibility but can also expose details about the frequency and content of signatures, which organizations must consider.

During a demonstration, the speaker used `cosign` to sign an image, generating a verifiable identity linked to a GitHub account, and recording this action in Rekor.

The signature process uses OpenID Connect (OIDC) to confirm the publisher's identity, providing a robust mechanism for traceability.

By signing an artifact with a GitHub account, publishers establish a clear trail that links the artifact to a specific email address and verifiable issuer.

Verification confirms both the identity of the publisher and the issuer of the signature, ensuring the artifact can be traced back to an expected and trusted entity.

Attackers often exploit old experimental branches in repositories because these branches typically lack strict enforcement of modern review policies.

Stale branches may contain legacy vulnerabilities in their dependencies that can be reactivated or leveraged, posing a security risk.

By pushing malicious code to non-protected nightly build branches, attackers can bypass critical CI/CD pipeline checks, deploying compromised software into the system.

The SLSA framework, which the Open Source Security Foundation has adopted, establishes a common vocabulary for security guidelines across the software development life cycle.

SLSA focuses on the entire software development life cycle, from the initial producer to the final consumer, ensuring comprehensive coverage.

The framework explicitly distinguishes between securing Git repositories and the critical processes of building and publishing software artifacts, addressing each stage with specific requirements.

The SLSA framework defines progressive security levels based on the integrity of provenance: Level 1 requires the mere existence of provenance, while Level 2 demands authentic provenance.

To achieve the highest tier, Level 3, provenance must be unforgeable and cryptographically signed, ensuring its integrity and authenticity.

Reproducible builds are a key requirement for achieving these higher levels, as they provide a consistent and verifiable process for generating artifacts.

GitHub claims SLSA Level 3 compliance, though further analysis suggests discrepancies in practice.

Azure DevOps, in contrast, is noted as only reaching Level 1 in a demonstrated scenario, indicating a significant gap in its current capabilities.

Selecting the appropriate build platform is critical for organizations aiming to adhere to higher tiers of the SLSA framework and ensure robust supply chain security.

Build triggers, such as pull request merges, provide essential context for verification, as understanding how a product is produced is crucial for validating its integrity.

Determining the validity of an artifact necessitates project-specific knowledge of its production methodology, which can be a complex and labor-intensive task.

Comprehensive metadata, including dependencies, workflow definitions, and runner details, enables reproducible builds and aids in thorough verification processes.

This standard allows for linking signatures, Software Bill of Materials (SBOM), and build provenance directly to specific artifacts, creating a comprehensive audit trail.

Producers can use OCI registries to sign metadata files and securely associate them with the primary artifact, enhancing the overall trustworthiness of the software supply chain.

Consumers play a crucial role in actively verifying the evidence generated by producers, such as adherence to SLSA build levels.

Organizations can implement security policies, for instance, by rejecting artifacts produced at a lower 'level one' in favor of those achieving a more secure 'level three'.

The verification process is not uniform and heavily depends on the specific organizational infrastructure and security requirements of each consumer.

A long-standing issue in the NuGet ecosystem, open since 2024, stems from the public NuGet feed modifying packages after a producer uploads them.

These server-side changes alter the cryptographic digest of the artifact, causing the package pulled by consumers to differ from the one originally built by the developer.

This post-upload modification breaks the chain of cryptographic verification, as the final digest no longer matches the build provenance, undermining trust in the integrity of packages.

A platform team has developed a four-step promotion model for artifacts, designed to rigorously verify their integrity and compliance.

Tools like Terraform or various certificate managers are tested against this model before they are approved for use within the system.

The primary objective of this model is to ensure that all claims made by producers regarding their artifacts are both feasible and accurate, enhancing overall security.

Open Policy Agent (OPA) is used with Gatekeeper to define and enforce deployment requirements for Kubernetes environments, ensuring that only compliant artifacts are deployed.

An experimental OPA provider allows the system to pull build provenance JSON directly from a registry, enabling real-time security checks during deployment.

This system is configured to block deployments if artifacts lack proper provenance, an SBOM, or clear vulnerability reports, thereby automating critical security gatekeeping.

Recent research has uncovered supply chain attacks, such as 'Shy Hulud,' that are capable of producing cryptographically valid SLSA build level 3 provenance, challenging existing security assumptions.

Attackers have grown sophisticated enough to extract signing keys and meticulously recreate valid artifacts, effectively bypassing previously robust security layers.

The Megalodon attack specifically demonstrates the extraction of SSA keys, OIDC tokens, and even source code, proving that advanced adversaries can still compromise systems despite strong security measures.