What Is Software Supply Chain Security?

Software supply chain security is the practice of protecting everything that goes into your software besides the code your own team writes: open source packages, build tools, publishing accounts and the pipeline that ships updates. Its goal is to make sure each piece is what it claims to be, comes from where it claims to come from, and has not been tampered with before it reaches your customers.

Reviewed by Hari Gopal Sharma, Co-Founder & CTO · Updated 2026-10-23

Why most of your app is other people's code

Modern software is assembled more than it is written. A typical web or mobile app pulls in hundreds or thousands of open source packages for things like dates, payments, file uploads and network requests, and each of those packages has dependencies of its own. Black Duck's 2026 Open Source Security and Risk Analysis report, which audited 947 commercial codebases, found open source in 98% of them and an average of 581 known vulnerabilities per codebase. None of this is a reason to avoid open source. It is the reason someone on your team has to know what is inside your product and keep track of it.

What a supply chain attack looks like

In a supply chain attack, nobody breaks into your servers directly. Instead, attackers poison something you already trust. On March 31, 2026, two malicious versions of Axios, a widely used JavaScript library for making web requests, were published to npm. Microsoft reported that they quietly added a dependency that installed a remote access trojan on developer machines and build servers, and attributed the attack to a North Korean state actor. In August 2026, a worm in the Shai-Hulud family spread through keyv and related caching packages. Singapore's Cyber Security Agency counted over 1,300 compromised package versions, built to steal developer credentials and spread further.

When the publishing system itself has a gap

Sometimes the weak point is not a package but the system that decides who may publish one. In October 2026, Bloom Security disclosed a flaw it called SlugFest in npm Trusted Publishing, a feature meant to make releases safer by removing stored passwords and tokens. npm linked a package to a GitHub repository by its name rather than its permanent ID, so if a maintainer renamed or deleted a repository, someone else could claim the old name and publish new versions. More than 1,500 packages were exposed. GitHub shipped a fix on October 2, 2026, and Bloom said it had not seen the flaw exploited in the wild. The lesson is that abandoned and renamed projects carry real risk.

The core defenses in plain terms

A lockfile records the exact version of every package your app uses, so a fresh install today gets the same code as last week instead of whatever was published an hour ago. Pinning goes further by refusing automatic upgrades until a person approves them. A software bill of materials, or SBOM, is what CISA calls a list of ingredients: an inventory of every component in your product, useful when the next alert lands and you need to know in minutes whether you are affected. SLSA, short for Supply chain Levels for Software Artifacts, is an industry framework for proving how a piece of software was built and that nobody altered it along the way.

How AI coding tools change the risk

AI coding assistants and agents now choose and install packages on their own, often faster than anyone reviews the choice. Bloom Security pointed out in its SlugFest research that tools such as Claude Code, Codex, Gemini and Cursor can pick dependencies, install them and run their install scripts with limited human review. That speed is useful, and it also means a bad package can enter your product without a person ever deciding to add it. You can keep using these tools. Treat every new dependency as a decision that someone reviews, and run installs in environments where a malicious script cannot reach your secrets.

How we approach supply chain security at AetherCraft

We use AI coding tools heavily, and we pair that speed with a few fixed habits. Every project commits a lockfile and pins dependency versions, and upgrades go through review rather than landing automatically. We keep secrets in a managed store instead of in code or developer laptops, give build systems the least access they need, and rotate credentials when an advisory touches anything we use. We can produce a component inventory for a client product on request, watch security advisories for the packages we depend on, and keep tested backups. Most importantly, a named engineer owns every deploy, so there is always a person who can answer what changed and why.

Questions to ask your development team

You do not need to read code to check whether your supply chain is in good hands. Ask whether the project uses a lockfile and pinned versions, and who approves dependency upgrades. Ask whether they can list every open source component in your product within a day, and what happened the last time a major npm alert came out. Ask where passwords, API keys and tokens live, and how quickly they can be rotated. Ask who has permission to publish or deploy, whether those accounts use two factor authentication, and whether anyone reviews packages added by AI tools. Clear, specific answers are a good sign. Vague ones tell you where to start.

Frequently Asked Questions

Is open source software unsafe to use?

No. Open source is in almost every commercial product, and much of it is maintained with great care. The risk comes from using it without tracking it. Packages get abandoned, maintainer accounts get hijacked, and known vulnerabilities pile up when nobody upgrades. Open source is safe to build on when someone keeps an inventory, reviews changes and responds to security alerts.

What is a lockfile and why does it matter?

A lockfile is a file in your project that records the exact version of every package your app installs, including the packages those packages depend on. Without it, a fresh install can quietly pull a newer version published minutes ago, which is exactly how malicious releases like the 2026 Axios versions reached build servers. With it, changes only happen when someone chooses to make them.

Do small companies really need an SBOM?

Probably not as a formal compliance document on day one, but you do need the information an SBOM holds. When a serious alert comes out, the first question is whether you use the affected package and which version. If your team can answer that quickly from an inventory, you lose hours instead of days. Enterprise and government customers increasingly ask for one too.

What should we do if a package we use is compromised?

Follow the advisory from a trusted source such as the vendor, Microsoft or a national cybersecurity agency. Usually that means removing the bad version, checking build logs to see whether it was ever installed, treating affected machines as compromised, and rotating any credentials they could reach. Then confirm which clean version you are pinned to and document what happened so the next response is faster.

Does using AI to write code make supply chain risk worse?

It can, mainly because AI agents install packages and run scripts faster than people review them, and they occasionally suggest packages that are outdated or do not exist. The same tools can also help by flagging old dependencies and drafting upgrades. The difference comes from process: reviewed dependency changes, isolated build environments, managed secrets and a person accountable for what ships.

Related Terms

Built for Your Industry

Book a Discovery Call. Eduardo Diaz leads every AetherCraft engagement personally.