Cybersecurity used to feel more straightforward. Most organizations focused heavily on threats like phishing attacks, weak passwords, ransomware, exposed databases, and insecure APIs. Those risks still matter and continue to impact companies globally.
But over the years, the threat landscape has expanded significantly.
Today, attackers are increasingly targeting the software supply chain itself: the packages, libraries, build systems, CI/CD workflows, container registries, and developer tools organizations rely on every day.
Instead of attacking one company directly, attackers can compromise a trusted dependency, release pipeline, or container image and quietly spread malicious code to thousands of downstream users.
That shift has made supply chain attacks one of the fastest-growing cybersecurity risks developers face today.
Why Supply Chain Attacks Are So Dangerous
Modern software is built on layers of dependencies.
A single application may depend on hundreds or even thousands of open-source libraries, third-party APIs, Docker images, automation tools, and deployment workflows.
This allows teams to build products faster than ever before. Developers don't need to reinvent authentication systems, database connectors, UI frameworks, or infrastructure tooling because someone has often already built it.
But that convenience comes with risk.
If attackers compromise one widely used package, they can potentially impact thousands of organizations at once. If they compromise a CI/CD workflow, they can inject malicious code into legitimate releases. If they compromise a container image, that malicious code can move directly into production environments.
That's what makes supply chain attacks so efficient.
Developers Can Unknowingly Install the Attack
The most dangerous part is how normal these attacks often look.
A developer updates a dependency. A CI/CD workflow runs. A Docker image gets deployed. A release appears legitimate.
Everything feels routine until teams realize malicious code was quietly stealing credentials, tokens, cloud secrets, developer data, or customer information.
Attackers understand that developers trust their tools and workflows. That trust is exactly what they exploit.
A Recent PyPI Example
A recent example involved the elementary-data package on PyPI, a widely used open-source tool for data teams working with dbt pipelines.
Attackers pushed a malicious version (0.23.3) designed to steal SSH keys, Git credentials, AWS, GCP, and Azure credentials, Kubernetes secrets, Docker secrets, .env files, cryptocurrency wallets, and system logs and shell history.
The attack also spread to Docker images because the project's release workflow automatically built and pushed container images from the same compromised code.
What made this incident particularly interesting was that researchers found attackers did not compromise a maintainer account directly. Instead, they exploited a GitHub Actions workflow weakness through a malicious pull request comment that triggered script injection. That exposed the project's GITHUB_TOKEN, allowing attackers to forge what looked like a legitimate release.
A clean version was later released, but anyone who downloaded the malicious package still had to assume their systems were compromised.
Bigger Attacks Prove This Is a Larger Problem
The PyPI incident is only one example.
The compromise involving the widely used Axios npm package showed how attackers can target packages used by millions of developers and applications. The Shai-Hulud malware campaign demonstrated how attackers can spread malicious code across multiple packages while targeting developer credentials and cloud secrets. And the SolarWinds breach remains one of the clearest examples of how trusted software updates can become massive attack vectors.
These incidents may look different, but they all share one common theme: attackers are exploiting trust at scale.
Should Developers Stop Trusting Open Source?
Some people respond to these incidents by saying open source software cannot be trusted.
That's the wrong conclusion.
The real lesson is that no software should be trusted blindly. Even private software companies using proprietary code regularly face major breaches, vulnerabilities, and CVEs. Organizations building their own internal tools still deal with security incidents caused by flawed code, poor configurations, and compromised infrastructure.
Closed-source software is not automatically safer just because fewer people can inspect it.
Open source remains one of the most important drivers of innovation in software development. It enables collaboration, transparency, and faster development across the entire industry.
The problem is not open source. The problem is blind trust without verification.
What Teams Can Do
Pin your dependencies
Avoid automatically pulling the latest package versions in production environments. Use lockfiles, pinned versions, and controlled update processes so teams can review changes before deployment.
Secure your CI/CD pipelines
Your pipelines often have access to deployment permissions, package publishing rights, cloud credentials, and signing keys. Treat them like critical infrastructure. Limit permissions, require approvals, and avoid executing untrusted input in automated workflows.
Protect your secrets
Many supply chain attacks are built to steal credentials first. Use secret managers, rotate credentials regularly, avoid storing sensitive tokens locally, and follow least-privilege principles.
Be careful with Docker images
Never blindly trust latest tags. Pin images by version or digest, scan them for vulnerabilities, and verify where they come from before deploying them.
Monitor your dependencies
Your dependencies are part of your attack surface. Track security advisories, monitor package changes, review maintainers, and use tools like Software Bills of Materials (SBOMs) and dependency scanners.
Developers Are Now Part of the Security Boundary
Developers are no longer separated from cybersecurity conversations.
Every dependency installed, workflow configured, token created, and deployment automated can either reduce risk or create new vulnerabilities.
That does not mean every developer needs to become a full-time security engineer. But it does mean software supply chain awareness is now part of building responsibly.
Sources: - StepSecurity: elementary-data compromised on PyPI and GHCR via GitHub Actions script injection