Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain
Attackers are targeting CI/CD pipelines and developer tools instead of application code, requiring total SDLC visibility and strict security controls While supply chain threats have been quietly compounding over the past decade, the last 12–18 months have triggered a drastic shift in the scale and velocity of these attacks.
Attackers are targeting CI/CD pipelines and developer tools instead of application code, requiring total SDLC visibility and strict security controls While supply chain threats have been quietly compounding over the past decade, the last 12–18 months have triggered a drastic shift in the scale and velocity of these attacks. Rather than just hunting for bugs in finished software, attackers are targeting the everyday tools and code developers rely on. We've observed attackers spending years pretending to be helpful contributors just to hide backdoors in core software, as seen in the XZ Utils vulnerability (CVE-2024-3094) . We've seen attackers hijack accounts to drop malware into popular libraries, like in the Axios supply chain attack .
From there, it hits three distinct targets: The main takeaway is that open-source and third-party packages touch every single phase of the software development lifecycle (SDLC).
True supply chain resilience requires continuous visibility between local developer endpoints, automated pipelines and cloud runtime workloads. By transitioning to brief OIDC authentication and enforcing end-to-end cryptographic provenance, teams can establish an unbroken chain of trust.
Generating a software bill of materials (SBOM) at the end of a build is great for compliance, but an SBOM alone simply doesn't cut it anymore. A standard application SBOM typically only lists the code libraries developers explicitly add to their software.
What changed
Defending against automated supply chain attacks requires shifting from reactive code scanning to strict execution control across the entire build path.
Who is affected
They routinely execute installations across a massive array of ecosystems — npm install , pip install , cargo build , go get , mvn install and many more — while simultaneously juggling 10–30 integrated development environment (IDE) extensions.
Because tools, IDE extensions and package managers run with high privileges, organizations must lock down the developer environment by disabling lifecycle install scripts ( --ignore-scripts ), enforcing package cooldown periods, restricting CI/CD egress traffic, using ephemeral CI/CD servers and pinning dependencies down to exact commit SHAs.
Why this matters
From there, it hits three distinct targets: The main takeaway is that open-source and third-party packages touch every single phase of the software development lifecycle (SDLC).
The technical picture
True supply chain resilience requires continuous visibility between local developer endpoints, automated pipelines and cloud runtime workloads.
By transitioning to brief OIDC authentication and enforcing end-to-end cryptographic provenance, teams can establish an unbroken chain of trust.
How organizations are responding
Generating a software bill of materials (SBOM) at the end of a build is great for compliance, but an SBOM alone simply doesn't cut it anymore.
A standard application SBOM typically only lists the code libraries developers explicitly add to their software.
What to watch next
Watch for additional exploitation reporting, newly published indicators, and changes to vendor guidance.
What remains unknown
The available reporting does not establish whether the issue is being actively exploited in the wild.
The available reporting does not establish who is behind the activity, if an attacker is involved.