You write secure code, but does that imply your application is fully secure? All it takes is single network call or a bash script that runs unnoticed on your machine!
### Attackers don’t break in anymore - they get shipped in.
What is software supply chain?
Software today is assembled, not written from scratch.
The software supply chain includes all components, processes, and people involved in building, packaging, and delivering software.
Typical application (web app/mobile app/thick client), along with internal code, is built using
- Open-source libraries (npm, PyPI, Maven)
- Build tools and CI/CD pipelines
- Container images and base OS layers
All these components together form software supply chain.
Think of it as a pipeline
Why it matters?
Software or applications today are mix of multiple open-source, third party dependencies. You don’t control everything in your software.
A single vulnerable dependency can compromise your whole application. Build pipeline that is tampered can ship malicious code that you never intended in production.
Threat Landscape - Risks & Attack Techniques
Modern software is no longer built in isolation. It pulls code from dozens of external sources, relies on automated pipelines, and ships artifacts across distributed systems. This interconnected model makes the software supply chain a high-value target for attackers.
Let’s break down the key risks - along with how attackers actually exploit them.
1. Malicious Dependencies
One of the most common entry points is through dependencies.
Attackers exploit the fact that developers trust package managers by introducing malicious packages into the ecosystem. This is often done via:
- Typosquatting - creating packages like
reqeustsinstead ofrequests - Dependency Confusion - publishing a public package with the same name as an internal one
When the build system resolves dependencies, it may unknowingly fetch and install these malicious packages.
Result: Malicious code executes during build or runtime - often without any visibility.
2. Compromised Maintainers
Instead of creating new packages, attackers sometimes go after existing trusted ones.
By taking over maintainer accounts (recent Axios breach is best example for this), they can push updates that appear legitimate but contain hidden backdoors. Since the package is already widely trusted, these updates propagate quickly.
A well-known example is the event-stream npm compromise.
Result: A trusted dependency turns into an attack vector overnight.
3. CI/CD Pipeline Attacks
CI/CD pipelines are powerful - and dangerous if misconfigured.
They often have:
- Elevated privileges
- Access to sensitive secrets
- Permissions to deploy to production
Attackers target pipelines by injecting malicious steps, modifying build scripts, or exploiting weak access controls.
Result: Full control over the build and release process - attackers can ship malicious software directly to users.
4. Artifact Tampering
Even if your code and pipeline are secure, the final artifact itself can be targeted.
Attackers may:
- Replace binaries or JARs
- Inject backdoors into container images
- Modify artifacts in registries
Without integrity checks (like signing and verification), there is no way to ensure the artifact hasn’t been altered.
Result: Users download and execute compromised software, believing it is genuine.
5. Insecure Base Images
Modern applications heavily rely on container images, often built on top of public base images.
If these base images are:
- Outdated
- Unverified
- Embedded with malware
…the risk propagates to every container derived from them.
Result: A single weak base image compromises entire environments at scale.
6. Secret Leakage
Secrets are the backbone of modern systems - and a prime target.
They often leak through:
- Build logs
- Hardcoded configurations
- Misconfigured CI/CD pipelines
Once exposed, attackers can use these credentials to move laterally, access systems, or escalate privileges.
Result: Initial access turns into deeper, systemic compromise.
Supply chain attacks are effective because they exploit trust and automation at scale - compromise once, impact thousands.
Security Controls & Best Practices
Understanding the risks is only half the story. The real question is: how do you secure something as complex and distributed as the software supply chain?
There’s no single fix. Security here is about layered controls across the entire lifecycle - from code to deployment.
1. Visibility First - Know What You Are Shipping
You can’t secure what you can’t see.
Start by generating an SBOM (Software Bill of Materials) - a complete inventory of all components in your application.
Multiple open-source and enterprise tools help you build this inventory as well as scanning for known vulnerabilities via CVE based scanning. Some advanced tools nowadays can now scan for malicious behaviour, dependency metadata, lateral movement and actual source code of open-source packages as well instead of just scanning for known CVE IDs.
This gives you:
- Full dependency visibility
- Faster vulnerability detection
- Better incident response
If you don’t know what’s inside your software, neither will your defenses.
2. Secure Dependencies - Reduce Blind Trust
Dependencies are the most common attack surface.
Best practices:
- Pin exact versions (avoid “latest”). Make use of lock files to lock down dependencies to specific version.
- Use trusted registries only
- Continuously scan dependencies for vulnerabilities
Treat every new dependency as untrusted code entering your system.
3. Integrity & Provenance - Verify What You Build
How do you know your artifact hasn’t been tampered with?
Use code signing and artifact verification:
- Sign build outputs
- Verify signatures before deployment
Trust should be verified, not assumed.
4. Harden CI/CD Pipelines - Protect the Control Plane
Your pipeline is your most powerful asset - and your biggest risk. If your pipeline is compromised, everything downstream is compromised.
Secure it by:
- Enforcing least privilege for pipeline roles
- Isolating build environments
- Storing secrets in secure vaults (not in configs/logs)
- Auditing pipeline changes
5. Secure Container Images - Build from Clean Foundations
Containers inherit everything from their base images.
Best practices:
- Use minimal and trusted base images
- Regularly scan images for vulnerabilities
- Avoid running containers as root
- Rebuild images frequently to patch issues
A secure image today can become vulnerable tomorrow - keep scanning.
6. Secrets Management - Eliminate Exposure
Secrets should never be:
- Hardcoded in code
- Printed in logs
- Stored in plain text
Instead:
- Use secret managers (Vault, cloud-native solutions)
- Rotate secrets regularly
- Limit access using least privilege
A leaked secret is often the beginning of a much larger breach.
7. Shift Left + Continuous Monitoring
Security shouldn’t be a final step - it should be continuous.
- Scan early (pre-commit, build stage)
- Monitor continuously (runtime, registries)
- Automate checks in pipelines
This reduces the window of exposure and catches issues before they reach production.
Closing Thought 🧠
Supply chain security isn’t about eliminating risk - it’s about controlling trust at every step.
The goal is simple: ensure that what you build, ship, and run is exactly what you intended - nothing more, nothing less.
