Supply Chain Software Is a National Security Issue Now Whether You're Ready or Not

March 20, 2026

I want to be honest about something before I start: I did not fully understand what a Software Bill of Materials was six months ago. I had seen the acronym. I had nodded at it in meetings. Derek once said something about it in the break room and I thought he was talking about Star Wars again, so I said "cool" and got my coffee and moved on. He was not talking about Star Wars. He was talking about federal procurement requirements. I should have listened.

Here is what is happening, stated plainly: the software that runs supply chains - the ERP systems, the inventory platforms, the logistics tools, the vendor portals - is now being treated by the U.S. government as a matter of national security. Not metaphorically. Literally. There are executive orders. There are Department of Defense memos. There are penalties. And the vast majority of small and mid-size businesses that sell to, touch, or operate anywhere adjacent to the federal government have no idea any of this is coming for them.

I think that is a problem. I think it is a bigger problem than anyone in the business software conversation is admitting. And I think the window to deal with it quietly is almost closed.

How We Got Here: A Cascade of Very Bad Days

You have to start with SolarWinds. In December 2020, the SolarWinds attack sent shockwaves around the world - attackers gained unauthorized access to SolarWinds' software development environment, injected malicious code into Orion platform updates, and created a backdoor called Sunburst, potentially compromising national security. The attack affected 18,000 organizations, including government agencies and major corporations. Think about that number. Eighteen thousand. Not because the attackers hacked 18,000 companies directly. Because one software vendor got compromised and everyone who trusted that vendor's update process got hit too.

In IronNet's 2021 Cybersecurity Impact Report, 85% of SolarWinds victims said the attack had an impact ranging from "small" to "significant," and on average the attack cost companies 11% of their annual revenue. Eleven percent of annual revenue. For most businesses, that is not a bad quarter. That is a company-ending event delivered through a software update they had no reason not to trust.

Then came a string of incidents that made SolarWinds look like a warmup. 2024 brought the CDK cyberattack that crippled North American car dealerships, and the Snowflake breach that exposed data from 165 prominent organizations. The July 2024 IT outage - a flawed update to cloud-based security software - triggered malfunctions in 8.5 million Microsoft Windows devices, disrupting airlines, banks, broadcasters, healthcare systems and payment infrastructure worldwide.

That last one was not even an attack. That was just a bad update. Which, honestly, might be more frightening.

The number of attacks detected in the software supply chain doubled again in 2024, indicating that the industry is mainly defenseless against these growing risks. And supply chain attacks were first thrust into mainstream consciousness by SolarWinds in 2020 - and fast forward to 2025, they are accelerating and rapidly evolving.

Watercolor illustration of a cozy kitchen pantry with neatly organized jars and cans on wooden shelves, one jar filled with a dark mismatched substance that blends into the otherwise orderly scene — Showed this to Derek and he immediately pointed at the wrong jar. I had not noticed it until he said something. That felt accurate.

The Government Started Paying Attention. Then Got Complicated About It.

After SolarWinds, Washington did something. Software supply chain security became a priority of the Executive branch with Executive Order 14028, Section 4, mandating appropriate software security practices to safeguard critical government supply chains and assets. The practical requirement that followed was something called an SBOM - a Software Bill of Materials. An SBOM is a "formal record containing the details and supply chain relationships of various components used in building software," similar to food ingredient labels on packaging.

The logic is sound. If you know exactly what ingredients are in your software, you know which ones go bad when a vulnerability drops. You can react faster. You can stop the bleeding before it starts. EO 14028 requires any software vendor selling to the federal government to provide an SBOM. That is not a suggestion. That is a condition of doing business.

Then, in January 2025, a follow-on executive order set a new standard for transparency and security in software procurement, mandating that the Federal Government only acquire software from providers who can demonstrate adherence to secure development practices. And the Department of Defense has been even more direct: a 2025 memo to senior Pentagon leadership made clear that the DoD must ensure information and communication technologies deployed in every warfighting domain are capable of securely and reliably operating within contested environments.

Here is where it gets complicated. In January 2026, the Trump administration issued Memorandum M-26-05, which rescinded the Biden-era requirement for all federal agencies to obtain a standardized self-attestation from software producers before using their software, noting that the prior approach diverted agencies from developing tailored assurance requirements. So the specific form is gone. The signal is clear: the federal government is moving away from a one-size-fits-all approach and will instead allow each agency to develop tailored requirements.

A lot of businesses read that and exhaled. They should not have. M-26-05 does not eliminate agencies' obligations to ensure security of the software and hardware they purchase. The rules got more flexible, not weaker. What that actually means is that different agencies will ask for different things, which means vendors now have to be prepared to satisfy multiple different security documentation requests instead of one standard form. That is not easier. That is more work for more people who are already stretched thin.

Tory at the office called this "an opportunity for agility." Tory is going through a lot right now - his car situation alone is a whole thing - but he is not wrong that there is opportunity here. He is just also not wrong that it is going to be hard.

The Part Nobody Is Talking About: This Hits B2B Companies Directly

Here is the thing I keep coming back to. Most of the coverage of supply chain software security frames this as a big-company, big-government story. CISOs at defense contractors. Federal IT teams. Fortune 500 compliance departments. And sure, those people are in the room. But they are not the only ones in the room.

While not all commercial software immediately requires an SBOM by law, the market pressure and contractual requirements from customers seeking supply chain assurance mean they are quickly becoming a de facto requirement for any enterprise. If you sell software - or use software that connects to a company that sells software to the government - you are in this chain. The growing adoption of open-source software, external libraries, and cloud-based services has increased software supply chain complexity, and this interconnectivity makes every linked component a potential attack vector.

I was setting up a project management integration a few months back - trying to get our workflow tool to connect to a client's vendor portal. I had it running on the wrong environment for about three days. Every sync was pulling from a staging instance instead of production. I did not notice because everything looked fine. The data was just slightly old. That is basically the metaphor for this whole situation. Everything looks like it's working. The risk is invisible until it is very visible.

In 2025, Sonatype identified 454,648 new malicious packages, with over 99% of open source malware occurring on npm - evidence that attackers increasingly optimize for developer workflows, credentials, and build environments. And by 2023 and 2024, delays in fixing vulnerabilities had increased significantly, with some projects taking over 400 days to release secure updates, and one reaching 470 days. That is a gap you could drive a freight train through. And nation-states are doing exactly that.

The January 2025 executive order highlights the cyber risk posed by foreign nations and criminals targeting the U.S., prioritizing China as the most active and persistent cyber threat, with Russia, Iran, and North Korea also named explicitly. When four countries are named by name in an executive order about your software vendor's security practices, that is not background noise. That is the current operating environment.

What Actually Changed in 2025 and What It Means

A few things happened in 2025 that I think deserve more attention from the business press than they got.

First, OWASP - the organization that publishes the most widely used web application security risk list - published its 2025 Top 10 Guide for Critical Web Application Security Risks and included a new category, "Software Supply Chain Failures," as the third-most critical risk. Third most critical. Out of ten. That is not a niche concern anymore.

Second, the attacks got nastier in ways that feel personal. The Shai Hulud 2.0 supply chain attack exploited compromised npm maintainer accounts between November 21 and 23, 2025, with attackers using stolen credentials to push trojanized versions of legitimate packages including those from Zapier, ENS Domains, PostHog and Postman, embedding malicious payloads. Zapier. That is a tool people use to automate their newsletter signups and CRM syncs. We have written about CRM tools on this site. The idea that the integration layer between your CRM and your email tool could be a national security attack surface is wild. It is also true.

Third, in 2024, the National Institute of Standards and Technology announced it would cease enriching CVEs - the vulnerability tracking system that AppSec teams have relied on for decades - denying teams critical information such as severity scores, patching statuses, and lists of affected products. In 2025, 65% of open source CVEs were left without CVSS scores by NVD, forcing teams to triage without consistent severity signals. So the government is simultaneously demanding higher software security standards while degrading the infrastructure that helps companies understand what to fix. I do not have a polite way to describe that situation.

Linda mentioned over lunch that Gerald had to replace all the smoke detectors in their house last year because a regulatory change required a different type, but the replacement parts were on a six-month backorder. She said it very calmly, like that was just a thing that happened. That is kind of what this feels like for mid-market software vendors right now. The rules are real. The tools to comply are not always available. You comply anyway or you lose the contract.

My Actual Opinion on This

Here is where I land, and I want to be direct about it: I think most B2B companies are dramatically underestimating how fast this becomes a contract requirement rather than a best practice.

The EU is already ahead. The EU Cyber Resilience Act mandates third-party supplier assessments, continuous software monitoring, vulnerability scanning and transparent Software Bill of Materials, with non-compliance penalties of up to €15 million or 2.5% of an organization's global revenue. The CRA enters full enforcement in 2027, but its impact is already felt - manufacturers and software providers are actively reshaping their product development, procurement, and compliance workflows well ahead of the deadline.

In the U.S., even with the current administration's shift toward flexibility over standardization, the DoD's Office of the Chief Information Officer is working with acquisition and security leaders to develop a framework that establishes clear cybersecurity and supply chain risk management requirements, rigorous software security verification processes, and secure information-sharing mechanisms. That framework is coming. When it arrives, it will not grandfather in companies that were not paying attention.

And the private sector follows the government on this. It always does. Defense contractors started requiring SBOMs from their sub-vendors. Then large manufacturers started requiring them from their software vendors. Then mid-market procurement teams started putting supply chain security questions in their RFPs. This is not a hypothetical trajectory. This is what is happening right now.

I looked at a project management setup for a client a while back - I was trying to figure out whether their workflow software had any documentation on component dependencies. It did not. I ended up in the wrong section of their documentation portal for about forty minutes before realizing I was reading archived content from 2019. Not their fault. Not a thing most vendors have even thought about yet. But it will be a disqualifying gap within two years for anyone selling into mid-to-large enterprise or government-adjacent markets. I would look at how the consolidation happening in industrial software is already reshaping these expectations - bigger vendors are absorbing compliance capacity that smaller players simply do not have.

What This Means If You Run a Business

I am not going to tell you to go hire a CISO. Not everyone can do that and I would not know what one costs anyway (Stephanie once told me a number for a security audit that I am still not sure was real). What I will say is that there are three things that are not that complicated and matter a lot right now.

One: know what software you are running and where it comes from. Software, hardware, managed services, cloud services and SaaS applications are all part of the software supply chain, and all could introduce vulnerability risk. That project management tool. That integration platform. That billing software. If you do not know the component breakdown of what you are running, you cannot respond when something in it goes bad.

Two: start asking your vendors about their security practices before someone asks you. The question "do you have an SBOM for this product?" will feel strange to say the first time. Say it anyway. If the vendor looks at you blankly, that is useful information. It tells you where you are in their priority queue.

Three: understand that the regulatory environment is not stable. Governments and regulatory bodies are imposing stricter cybersecurity mandates - the U.S. Executive Order on Improving the Nation's Cybersecurity emphasizes the need for secure software development practices, and non-compliance can result in legal penalties and loss of business opportunities. The specific forms and frameworks will keep changing - they have already changed three times in four years. But the direction is not changing. The direction is toward more transparency, more documentation, and more accountability across the whole chain, not just at the top.

The companies that treat this as a compliance checkbox will spend the next five years scrambling to meet requirements that keep moving. The companies that treat it as a real operational concern - the software we depend on could be a vector for attack, so we should actually know what is in it - will end up ahead of the curve without necessarily meaning to be.

I hold the elevator for people even when I am running late. I know that is not directly relevant. But I think there is something to be said for the habit of not assuming your situation is fine just because nothing has gone wrong yet. The people who missed the SolarWinds exposure were not careless. The attackers infiltrated SolarWinds' build environment and embedded malicious code into software updates for the Orion platform, distributed to thousands of government agencies and corporations - representing a new attack level where adversaries exploited vulnerabilities deep within the development pipeline to compromise trusted software used by high-value targets. The victims trusted a vendor they had every reason to trust. The trust was not misplaced. The security was.

Your supply chain software is a national security issue whether you work in national security or not. The question is just whether you are going to find that out from a policy update or from something worse.

I would prefer the policy update, personally.