What do SolarWinds, Codecov, and the npm package event-stream have in common? Each became a headline because of a supply chain security failure, not a clever zero-day. Attackers keep finding that the shortest path into a well-defended organization is through the software and vendors it already trusts. And most of the mistakes that open that path are boring, repeatable, and entirely avoidable.
This article walks through the most common supply chain security mistakes, explains why they persist, and shows what actually works in practice. It covers both software supply chains, where code and dependencies flow into builds, and physical supply chains, where hardware and components flow into products and facilities.
Mistake 1: Treating Dependencies as Someone Else’s Problem
Most modern applications are mostly other people’s code. Teams add a handful of direct dependencies and inherit hundreds of transitive ones without thinking about it. The mistake is assuming that a package with millions of weekly downloads is therefore safe.
It isn’t. The event-stream npm package was maintained by a trusted developer and quietly handed off to a new maintainer in 2018; that maintainer injected malicious code targeting a cryptocurrency wallet. The ua-parser-js package, downloaded millions of times a week, was compromised in 2021 when an attacker took over the maintainer’s account and pushed a malicious release. Neither incident required breaking cryptography. Both relied on trust that nobody had verified.
What actually works: maintain an inventory of every dependency, including transitive ones, and treat “who maintains this and when was it last updated” as a real question. A dependency that hasn’t been touched in three years isn’t stable; it’s abandoned, and abandoned packages are prime targets for takeover.
Mistake 2: Running Unpinned Builds and Ignoring Lockfiles
If a build resolves “latest” on every run, every run is a new supply chain event. Teams that pin some dependencies but not others, or that commit a lockfile and then regenerate it casually during debugging, end up shipping whatever the registry served that day. (Home Security Systems: 8 Best Picks for Every Home)
The practical fix is unglamorous. Commit lockfiles. Pin versions in production builds. Where the ecosystem supports it, verify hashes or signatures so a tampered package fails the build instead of shipping. The Codecov Bash Uploader compromise in 2021 is a good reminder that even a one-line download script in a CI pipeline is a dependency; if it isn’t versioned and verified, it’s an open door.
A related mistake is trusting version ranges that look tight but aren’t. Caret ranges in semantic versioning still allow new releases. If a maintainer’s account is compromised and a malicious patch version is published, a range that “only allows patches” accepts it happily.
Mistake 3: Giving CI/CD Pipelines More Power Than They Need
Continuous integration systems hold the keys to everything: source code, build artifacts, deployment credentials, and often production secrets. Yet many pipelines run with long-lived tokens that have broad write access across repositories and cloud accounts.
The pattern that keeps showing up in incident reports is a compromised build step or a malicious pull request exfiltrating a token that was never scoped down. Short-lived, narrowly scoped credentials issued per job are the recommended alternative, and most major CI platforms now support workload identity federation so pipelines never hold a static secret at all.
Two practical habits help here:
- Pin third-party CI actions and plugins to a specific commit hash rather than a mutable tag, so a compromised upstream repository can’t silently change what runs in your pipeline.
- Review what a build job can reach. If a job that runs tests can also push to production, that’s a mistake waiting to be exploited.
Mistake 4: Storing Secrets in Source Code and Build Logs
Hardcoded credentials remain one of the most common findings in code reviews and one of the easiest things for an attacker to harvest. Secrets committed to a repository live on in git history even after deletion, and secrets echoed into verbose build logs can be read by anyone with log access.
What actually works is a combination of prevention and detection. Enable secret scanning with push protection where available, so a credential is blocked before it lands. Keep secrets in a managed vault or environment store, not in configuration files. Trim CI logging so tokens and connection strings never print. And when a secret does leak, rotate it immediately; deleting the commit is not remediation.
This is also where non-human identity management matters. Service accounts, API keys, and machine credentials vastly outnumber human ones in most organizations, and they often go unrotated for years. Comparing approaches like Astrix vs Oasis vs Entro for non-human identity security in 2026 is worth doing if your organization is trying to get a handle on machine credentials at scale.
Mistake 5: Skipping SBOMs and Build Provenance
You cannot defend what you cannot see. A software bill of materials (SBOM) is a machine-readable list of the components in a piece of software, and it’s the difference between answering “are we affected?” in minutes versus weeks.
US Executive Order 14028, signed in May 2021, pushed SBOM adoption into federal procurement, and CISA and NTIA published guidance on minimum SBOM elements the same year. Build provenance frameworks such as SLSA go a step further, recording how an artifact was built so consumers can verify it came from the expected source and process.
The common mistake isn’t refusing to produce an SBOM. It’s producing one once, filing it, and never regenerating it. An SBOM is only useful if it’s current and if someone actually queries it when a new vulnerability drops.
| Practice | Weak version | Strong version |
|---|---|---|
| Dependency inventory | Annual spreadsheet | Auto-generated, per-release SBOM |
| Build verification | Trusting CI output | Signed provenance attestations |
| Vulnerability response | Ad hoc email threads | Queryable SBOM plus a response playbook |
Mistake 6: Assuming Vendors and Partners Are Secure
Third-party risk is where supply chain security and vendor management collide. Organizations routinely onboard SaaS tools, contractors, and hardware suppliers with a questionnaire and then never revisit them.
The SolarWinds Orion attack, disclosed in December 2020, is the canonical example: a trusted IT management vendor’s build system was compromised, and malicious updates were distributed to thousands of customers through a legitimate, signed channel. No amount of perimeter defense stops that. What helps is limiting what a vendor’s software can reach, segmenting networks, and requiring vendors to disclose their own security practices and incident history.
For physical supply chains, the same logic applies. A home or business that installs connected devices without checking firmware update practices has imported a vendor’s security posture into its own network. That’s why reviews of the best internet security options in Australia now routinely factor in device-level risk, and why choosing home security systems involves asking who patches the firmware and for how long.
Mistake 7: Overlooking the Physical and Consumer Supply Chain
Supply chain security isn’t only about code. Counterfeit components, tampered hardware, and insecure IoT devices are supply chain problems too. A cheap camera or lock bought from an unknown seller may arrive with default credentials, no update path, and a cloud backend nobody has assessed.
Practical guidance that actually helps:
- Buy connected devices from vendors with a published vulnerability disclosure policy and a stated support window.
- Change default credentials before a device touches the network, and put IoT devices on a separate network segment.
- Prefer devices that support local control or work without a mandatory cloud account, which reduces exposure to a vendor outage or breach. Reviews of the best outdoor security cameras without a subscription often highlight this for exactly that reason.
Good starting points for a home setup include a shortlist of the best smart locks for home security and a look at the best wireless outdoor security camera options, but the selection criteria matter more than the specific model: update support, credential handling, and network behavior. (How much social security will i get at 62)
Mistake 8: Having No Playbook for a Supply Chain Incident
When a dependency is compromised, the clock starts immediately. Organizations that haven’t planned for it spend the first day figuring out who owns the response, where the dependency is used, and how to rebuild.
A usable playbook answers four questions in advance: How do we determine whether we’re affected? Who can authorize an emergency rebuild or rollback? How do we communicate with customers? What do we do about credentials that may have been exposed during the window? Teams that can answer those in hours rather than days consistently come out of supply chain incidents with less damage.
What Good Looks Like in Practice
None of these fixes is exotic. The organizations that handle supply chain risk well tend to share a few habits: they know what they’re running, they pin and verify what they build, they scope credentials tightly, and they rehearse the bad day before it happens. Frameworks like NIST’s Secure Software Development Framework and CISA’s guidance on defending against supply chain attacks give structure, but the habits matter more than the paperwork.
The through-line across every mistake above is unexamined trust. Every dependency, pipeline token, vendor, and connected device is a trust decision. Making those decisions deliberately, and revisiting them, is most of the job.
Conclusion
Supply chain security mistakes are rarely dramatic. They’re unpinned builds, over-privileged tokens, unread vendor questionnaires, and SBOMs nobody queries. Each one is small; together they form the path attackers actually use. The good news is that the fixes are well understood, mostly cheap, and largely about discipline rather than new tools. Start with visibility, tighten the credentials, and write the incident playbook before you need it.
Frequently Asked Questions
What is the most common supply chain security mistake?
Unmanaged dependencies are the most common. Teams add packages without tracking transitive dependencies, pinning versions, or monitoring maintainer activity, which leaves them exposed to typosquatting, account takeovers, and abandoned-package hijacks.
What is an SBOM and why does it matter?
A software bill of materials is a machine-readable inventory of the components in a piece of software. It matters because it lets an organization answer “are we affected?” quickly when a vulnerability or compromised package is announced, instead of relying on guesswork.
How do dependency confusion attacks work?
Dependency confusion exploits package managers that check public registries before private ones. An attacker publishes a malicious package under the same name as an internal package, and the build system pulls the public, malicious version instead of the private one. Scoping private packages and configuring registry priority prevents it.
Are open-source dependencies less secure than commercial software?
Not inherently. Open source is often reviewed by more eyes and patched faster. The risk comes from how it’s consumed: unpinned versions, unmonitored transitive dependencies, and abandoned projects. Commercial software carries its own risk, since you’re trusting a vendor’s build process instead.
How can small teams improve supply chain security without a big budget?
Start with three things: commit lockfiles and pin production dependencies, scope CI credentials to the minimum and rotate them, and enable secret scanning with push protection. All three are free or near-free and close the most commonly exploited gaps.
What should an incident response plan for supply chain attacks include?
At minimum: a way to identify where an affected component is used, authority to trigger an emergency rebuild or rollback, a customer communication process, and a plan for rotating any credentials exposed during the incident window. Rehearse it once a year.
None of this requires a dedicated security team to start. A single engineer can pin dependencies, enable push protection, and scope a pipeline token in an afternoon, and those three changes close the gaps attackers reach for first. The order matters less than beginning: pick the mistake above that your organization is most exposed to today, fix it this quarter, and add the next one after. Supply chain security improves through accumulation, not through a single sweeping program.
