Software Supply Chain Risk and Security: The 2026 Guide

Software supply chain risk is the chance that software you trust, a vendor update, a SaaS integration, an open-source package, or your IT provider's own tools, gets compromised and carries an attacker straight into your business.

You don't have to write a line of code to carry this risk. Software reaches a company through four doors, and our managed cybersecurity services team starts by asking which of the four are open. Installed programs and their updates. Cloud apps wired into each other through saved logins, tokens, and API keys. Your IT provider's remote tools. Code your people pull in.

In August 2025, attackers pulled records out of Salesforce accounts at a long list of companies without ever breaking into Salesforce. They used login tokens stolen from Drift, a chatbot tool those companies had connected to Salesforce and then, understandably, stopped thinking about. Google's threat intelligence team traced the activity from August 8 through at least August 18, 2025, and found it didn't stem from any flaw in the Salesforce platform itself. Then the attackers searched what they'd taken for AWS access keys, passwords, and Snowflake tokens.

They were already looking for the next way in.

Nobody at those companies clicked a bad link. Nobody's password was weak. The attacker came in through something that had been approved, installed, and trusted, which is why the usual advice about phishing and patching doesn't quite reach this problem. Guides on this topic tend to be written for software developers. This one is for the companies that buy software, which is nearly everyone else.

What Is Software Supply Chain Risk?

Software supply chain risk is exposure you inherit from other people's code. Every product, cloud service, and update you run was built with components and tools you didn't choose, and a compromise anywhere upstream can reach you.

NIST calls the work of managing it cybersecurity supply chain risk management, or C-SCRM. Its SP 800-161 Revision 1 guidance applies to any organization that buys, builds, or operates technology, not only federal agencies. The buying side is where your company lives.

Picture an ingredients list. The accounting system you license contains open-source libraries written by volunteers, a database engine from a third company, and an installer assembled on somebody's build server. CISA's 2026 Minimum Elements for a Software Bill of Materials, final as of July 29, 2026, uses that exact framing and calls the list "a key building block of software security and supply chain risk management." We walk through how to read one in our guide to the software bill of materials (SBOM). The simpler point for now is that when you buy software, you buy its whole family tree. Every branch of it.

Two different failures hide under the same name. One is a flaw, a mistake someone left in the code by accident, like Log4j in 2021 or any zero-day vulnerability nobody knew about yet. The other is tampering, where an attacker deliberately gets their own code into the product or its update channel. Much harder to spot.

Flaws get patched. Tampering arrives inside the patch.

How Does a Supply Chain Attack Actually Work?

A supply chain attack compromises something upstream, a vendor, an update server, an integration, or a code library, then uses the trust you've already granted it to reach you. You don't get attacked directly. Your trust does.

That trust takes four forms at a company with 20 to 1000 users. Each one has a real, well-documented incident behind it.

SolarWinds is still the example everyone reaches for. When it broke, CISA's Emergency Directive 21-01 ordered federal agencies to immediately disconnect or power down Orion versions 2019.4 through 2020.2.1 HF1, which tells you how little anyone could trust the software once the build process itself was in question. The update was real. It came from the real vendor. It just had someone else's code inside it.

Door one gets the headlines, but doors two and three are where companies your size tend to carry the most exposure, and they're the two that almost never get inventoried. A 200-person manufacturer might run a single ERP system and still have dozens of apps connected to Microsoft 365, each holding permission to read mail, files, or calendars. Somebody clicked Accept on every one of them, usually months apart and usually for a good reason. Nobody kept a list.

Why Is Software Supply Chain Risk Climbing in 2026?

Sonatype's 2026 State of the Software Supply Chain report counted more than 454,600 new malicious open-source packages in 2025, a 75% jump over the prior year, bringing the total it has identified and blocked to over 1.233 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Those public libraries are what almost every commercial product is assembled from. A year like that doesn't stay politely inside developer tools.

The Shai-Hulud worm showed how fast it moves. CISA's September 23, 2025 alert described malware in over 500 npm packages that scanned for GitHub tokens and AWS, GCP, and Azure keys, sent them to the attacker, and then spread itself by logging in to the npm registry as the developer it had just robbed. Self-replicating. No human steering required.

It's expensive, too. IBM's 2026 Cost of a Data Breach study, based on 602 breached organizations between March 2025 and February 2026, puts the global average breach at $4.99 million. According to the full IBM report, supply chain compromise was the largest single cost amplifier it measured, adding $227,250 per breach, and it took 258 days on average to identify and contain, 11 days longer than the overall average.

Roughly eight and a half months.

Why so slow? Because the traffic looks legitimate. A signed update from a real vendor, a data request from an app somebody approved back in 2022, a package your developer installed on purpose and has used every day since. Every control built to spot strangers waves it through, since technically it isn't a stranger, and that's the structural reason these incidents run long rather than any failure of effort on the part of the people watching.

Is Supply Chain Security the Same as Vendor Risk Management?

No, though they overlap. Vendor risk management asks whether a supplier can protect your data and keep delivering. Software supply chain security asks whether the code that supplier runs in your environment can be trusted.

SaaS vendors sit in both columns at once. They hold your data, and their code runs in your browser or plugs into your other systems. Our guide to building a third party risk management program covers the left column in depth, and there's a manufacturing-specific version for plants. This one stays on the right.

What Can You Control If You Don't Write Software?

More than you'd expect. A company that buys software controls four levers. What gets connected, how much access each connection holds, how updates arrive, and what's watching after trust is granted. None of them require a developer.

Installed Software and Updates

Keep automatic updates on. I know that sounds backward right after a SolarWinds paragraph. Yes, still. Turning updates off to dodge a poisoned one trades a rare problem for a common one, since in my experience unpatched known flaws are the everyday way in.

What changes is how updates land. A small pilot group of machines, maybe 5 to 10 across different departments, gets each update a few days before everyone else. Servers and line-of-business systems, the ERP, the MES running the shop floor, get a snapshot before patching, so that if an update breaks something on a Tuesday afternoon, you roll back in minutes instead of spending the evening on hold with the vendor's support line. Boring, and it works. And you keep an inventory of what's installed, because you can't act on a CISA alert about a product you didn't know you owned.

SaaS Integrations

Open this door first.

• In Microsoft 365, open the Entra admin center and go to Enterprise applications. Every third-party app with access to your tenant is listed there, along with what it can read.
• Google Workspace keeps the same list under Security, then Access and data control, then API controls.
• Salesforce? Setup has a Connected Apps OAuth Usage page. Worth a look before the next Drift.
• Turn off user consent, so employees can't approve new apps on their own. Requests go to IT instead.
• Anything unused for 90 days goes.
• For what stays, cut permissions to the minimum and restrict where it can connect from. Google's investigators recommended the same moves after Drift, along with revoking and rotating every token.

That's the whole job, really. An afternoon and the nerve to switch things off.

Your IT Provider's Tools

Important enough to get its own section below.

Code Your People Pull In

If you have developers, a website agency, or a contractor writing scripts, this door is open whether you think of it that way or not. CISA's post-Shai-Hulud guidance translates well for a business owner. Pin dependencies to known-good versions so a new poisoned release doesn't install itself, rotate developer credentials after any incident, and require phishing-resistant MFA on developer accounts like GitHub and npm. Ask your web agency whether they do all three. Some won't know.

Watch What Trusted Software Does

Prevention at the door will miss something eventually. So the last layer watches behavior after trust has been granted. When the accounting package that has run quietly for three years suddenly starts talking to an unknown server at 2 a.m., an endpoint detection and response (EDR) tool, software that watches what programs do on each machine, flags it. A security operations center (SOC), a team that monitors those alerts around the clock, then has a person decide whether it's real. EDR alone produces alerts. The SOC is what turns an alert into a decision at 2:05 instead of Monday morning.

Questions to Ask Before You Buy or Renew Software

CISA's Secure by Demand guide, published in August 2024, was written for exactly this moment, and it's the best free procurement checklist I know of. It's aimed at buyers. Here's a trimmed version with what a good answer sounds like.

Get the answers in writing, then move the important ones into the contract. A promise made on a sales call rarely survives the renewal.

One wrinkle on vendor paperwork. Federal rules used to push software makers toward filing a signed attestation that they follow NIST's Secure Software Development Framework. Executive Order 14306, signed June 6, 2025, pulled back that mandate, so don't assume a vendor has one on file. Ask to see it.

Your IT Provider Is Part of Your Supply Chain

Your IT provider installs a remote monitoring and management tool, usually called an RMM, on your machines. That's how technicians patch, fix, and support your systems without driving to your office. Convenient for everyone, attackers included. One compromised RMM platform can reach every client at once.

That's what happened on July 2, 2021. Attackers used a vulnerability in Kaseya VSA, an RMM product many IT providers ran on their own servers, to push ransomware to those providers and through them to their customers. The CISA and FBI guidance issued two days later still reads like a good checklist five years on. MFA on every account. RMM access limited to known IP addresses, or placed behind a VPN or firewall on a dedicated admin network.

So ask your provider, whoever it is:

• Is MFA enforced on every account that can reach our machines through your RMM, your own technicians' included?
• Can the RMM admin console be reached from the open internet, or only through a VPN or an IP allowlist?
• If your RMM platform were compromised tonight, what would stop a script from running on all of our machines at once?
• Who on your team can run commands on our servers? Do we get the log?
• Can we get a full list of every tool you've installed in our environment? It should take a day to produce, not a quarter, and if it takes longer, that list probably doesn't exist on their side either.

Fair questions, all of them. Good providers answer without much fuss. If yours needs a week to find out, that's an answer too. And if you run everything in-house with your own admins and no outside RMM at all, this door is smaller for you. Doors two and four aren't.

Where Do the Frameworks Fit?

You don't need a framework to start. But when a customer sends a security questionnaire, an auditor asks how you manage supplier risk, or your cyber insurance renewal suddenly includes a page about third-party software, these are the documents sitting behind the question, whether or not anyone names them.

• NIST SP 1305, the October 2024 quick-start guide for supply chain risk under NIST CSF 2.0. It walks through the framework's Govern category for supply chain, GV.SC, and it's written for organizations starting from nothing. Read this one first.
• SP 800-161 Revision 1 is the deep control catalog, heavy going for a first read but useful when a contract asks for it by name.
• NIST's Secure Software Development Framework is aimed at software makers, and version 1.2 went out as a public draft on December 17, 2025. Treat it as the bar you ask vendors to clear.
• CISA's 2026 SBOM minimum elements define what a usable SBOM has to contain, so you can tell a real one from a spreadsheet.

Companies that already measure themselves against CSF will find supply chain inside the Govern function, and a NIST CSF assessment will score it alongside everything else. Manufacturers selling into electronics and semiconductor customers are increasingly asked to prove it. Our walkthrough of a semiconductor supply chain security assessment shows what that evidence looks like. When a contract requirement is driving the work, that's a compliance readiness project, which we run as its own engagement through our compliance practice, separate from managed IT.

What Does a 90-Day Starting Plan Look Like?

Start with inventory, then cut access, then change how you buy. In 90 days, a company with 20 to 1000 users can map all four doors, remove what nobody uses, and put supply chain questions into every renewal.

Tabletop exercises, if the term is new, are one-hour meetings where leadership talks through what they'd actually do if a key vendor called tomorrow to say they'd been breached. Who gets called. Which systems get cut off first, and who's allowed to make that call. Who talks to customers. It's cheap. It also finds gaps faster than any document review.

With a formal third-party risk program and a dedicated security team already in place, you've probably covered doors one and three. Check door two anyway. Connected apps grow back like weeds, one Accept button at a time. And if you'd rather hand the mapping to someone else, a cybersecurity risk assessment covers all four doors in one pass.