Skip to content

Code Signing Does Not Protect Against Build Pipeline Attacks

The bottom line: Traditional code signing does not protect against manipulation during the build process; ephemeral environments with short-lived keys and Sigstore offer more effective security.

Attackers no longer manipulate software in source code, but during compilation. Traditional code signing fails here because attackers with compromised build servers can also abuse the genuine manufacturer keys.

The attack vectors on software supply chains have fundamentally shifted. While historically direct vulnerabilities in source code or production systems were the target, today’s state and criminal actors focus on automated build infrastructure. The critical point lies at the moment of compilation — the transformation of source code into executable binaries.

Sophisticated attackers bypass traditional security measures such as code reviews, static analysis, and branch protection in Git repositories because these only capture static source code. Instead, they inject malicious code during the running build process directly in the build runner’s working memory or manipulate temporary dependencies. The SolarWinds attack with the Sunburst malware demonstrated this methodology: the malware was injected directly during compilation into the production update without leaving traces in the source code archive.

Traditional code signing with public key infrastructure (PKI) shows structural deficiencies in cloud-native environments. The model requires long-lived private keys in pipeline secrets or on hardware security modules. If an attacker gains administrative control of the build server, he can sign his manipulated software with the genuine manufacturer key completely legitimately. Regular rotation of static certificates is error-prone; in the event of key compromise, revocation through Certificate Revocation Lists is significantly delayed, during which compromised software continues to be regarded as trustworthy.

The paradigm of ephemeral build environments is being established as a countermeasure. A build runner is no longer operated as a permanently running server, but is isolated for each build step and completely re-initialized from scratch — typically through fleeting container instances in Kubernetes clusters or dedicated micro-virtual machines. Short-lived keys that exist only for a single build and cryptographic attestation via Sigstore significantly reduce the attack surface.


Source: www.it-daily.net · Published 19 July 2026
Lumi AI News — AI-assisted curation pursuant to Article 50 EU AI Act. Paraphrase and classification by Lumi News Pipeline v1.7.3.

Share on: