Securing the Code Factory: Why SDLC Infrastructure Has Become a Core Cloud Risk
For years, software security focused on the final product: the code that ships. Today, attackers are increasingly targeting the systems that build the software itself.
The shift is logical. Breaching a single app yields limited returns, whereas compromising the infrastructure that builds thousands of apps can quietly scale impact across an organization. As application security gets stronger, attackers are looking elsewhere, including under-protected parts of the software development lifecycle (SDLC).
We talk a lot about software supply chain security. In practice, much of the real risk lives inside the SDLC itself: the internal machinery that builds and ships our code. Think of it like a factory. Source code is just the raw material. The CI/CD pipelines, build runners, and IDEs are the assembly line. And attackers have learned that access to the factory often matters more than access to any single product.
A Turning Point: The Ultralytics Hijack
This shift became clear with the hijack of the Ultralytics AI library. While package compromises on PyPI aren’t new, the Ultralytics incident marked an inflection point because of how it occurred. The attackers exploited the machinery of the code factory itself.
By manipulating GitHub Actions via maliciously crafted branch names in pull requests, a technique known as a Pwn Request, an external actor injected a cryptominer directly into the release package. This exploit bypassed traditional code reviews because the malicious code wasn’t in the source repository. Instead, it was introduced during the automated build process at execution time. The lesson was simple and uncomfortable: even clean source code cannot protect a compromised build system.
Scale Arrives: The Shai-Hulud Waves
If Ultralytics was the warning shot, the Shai-Hulud waves demonstrated how quickly SDLC infrastructure attacks can scale. The Shai-Hulud 2.0 campaign hit over 25,000 developer stations or CI runners and compromised popular projects, including Zapier and Postman.
The Shai-Hulud actors weren’t focused solely on injecting malware. Their primary goal was access and harvesting credentials that unlocked broader environments. The worm scraped CI/CD secrets, GitHub tokens, cloud credentials, and other secrets from build environments. These secrets were then exfiltrated to public GitHub repositories, often using one compromised account to host data stolen from another.
What made Shai-Hulud particularly dangerous was its long tail. Even after malicious packages were removed from public registries, the exposure persisted. It lingered in private registries that failed to sync revocations and through IDE extensions that remained active on developer machines.
Downstream Impact: Trust Wallet
The downstream impact became clear at the end of last year with the Trust Wallet incident, where $7 million was reportedly stolen following a malicious update to their browser extension. Research suggests this was a direct downstream consequence of the Shai-Hulud campaign.
The attackers didn’t exploit a zero-day in Trust Wallet’s code. Instead, they leveraged credentials, including GitHub tokens and Chrome Web Store secrets, that had been exfiltrated during earlier SDLC infrastructure compromises. With these stolen credentials, they were able to take control of the distribution pipeline itself. The incident underscored a recurring pattern in modern supply chain attacks in that the initial compromise is often just the starting point, while the real impact comes later and not necessarily from the same attacker.
A Framework for Defending the Factory
These incidents exposed a critical gap: most security programs are built to protect runtime environments, not the systems that create them.
The SDLC Infrastructure Threat Framework, or SITF, helps address this gap. SITF is an educational, open-source framework designed to help organizations move beyond simple checklists. It maps attacks across the five pillars of the code factory: Endpoint/IDE, VCS, CI/CD, Registry, and Production. It catalogs more than 75 SDLC-specific attack techniques, including Action Cache Poisoning and Imposter Commits.
What makes SITF valuable is its practicality and focus on attack flow. It connects techniques to enabling risks and relevant security controls, making it easier to interrupt attacks earlier.
A practical example:
- Technique: Pivot from self-hosted container runner into K8s cluster
- Enabling Risk: Overprivileged runner pod identity
- Control to prevent / detect the technique: K8s sensor on runner cluster
By visualizing how an attacker moves from a developer’s IDE to a CI/CD runner and eventually to a package registry, teams can pinpoint where a single control meaningfully reduces risk. For example, the persistence seen in Shai-Hulud could have been reduced through stronger private registry governance and trusted publishing controls, areas SITF highlights based on their position in the attack path.
How Security Teams Can Get Started With SITF
SITF is designed to be prescriptive, actionable, and easy to use. It’s open source and runs entirely client-side, either in the browser via GitHub Pages or locally using static HTML files. There is no installation script, signup, or server to deploy, and no data leaves a user’s machine.
The entire technique library is driven by a machine-readable JSON source of truth, meaning anyone can contribute SITF techniques and scenarios to the community. This also enables security teams to pull the latest updates to ensure threat models account for the newest supply chain tradecraft.
Attackers are no longer focused solely on application vulnerabilities. They are targeting the systems that developers rely on to build, test, and ship software. Treating build pipelines as background utilities is no longer sufficient. They are production systems in every meaningful sense.
Frameworks like SITF help teams understand how these attacks unfold and where defensive controls matter most. Securing the code factory starts with visibility into the factory itself, and an acknowledgment that SDLC infrastructure is now a first-class security concern.
KubeCon + CloudNativeCon EU 2026 is coming to Amsterdam from March 23-26, bringing together cloud-native professionals, developers, and industry leaders for an exciting week of innovation, collaboration, and learning. Don’t miss your chance to be part of the premier conference for Kubernetes and cloud-native technologies. Secure your spot today by registering now! Learn more and register here.
The post Securing the Code Factory: Why SDLC Infrastructure Has Become a Core Cloud Risk appeared first on SD Times.
Tech Developers
No comments