Software supply chain security is a serious cybersecurity issue. Most companies have known vulnerabilities in their codebases—your organization probably does, too.
Many of these vulnerabilities are carryovers from open-source code components your team (and your software vendors) use to build your applications. These vulnerabilities go unremediated for a host of reasons, including:
The list goes on. Today, most companies accept that they can’t maintain vulnerability-free code, and treat third-party vulnerabilities as an inherent risk of using software.
However, the standards and expectations for software supply chain security are changing, and what’s acceptable today won’t be acceptable tomorrow. Ever since the SolarWinds breach was discovered in 2021 (to which even the U.S. Departments of Defense, State, and Treasury fell victim), governments have ramped up initiatives to hold software providers to higher cybersecurity standards.
This shouldn’t come as a surprise. As industries mature, so do safety protocols. For example, when construction companies were building the first skyscrapers a century ago, there were no regulations in place for workers’ safety. These “cowboys of the sky” worked hundreds of feet above the street without hard hats, harnesses, or safety ropes. Working conditions were so dangerous that foremen allegedly expected one man to die for every $1 million dollars spent on a skyscraper project. This sounds like horrific negligence today, but back then, it was just considered a risk that came with the job.
The same shift is happening in software—but faster. What passes as acceptable software supply chain security today will likely be seen as grossly reckless within the next five years. In fact, the White House is actively shifting the responsibility of cybersecurity onto the entities who are making and selling software.
So it’s smart to start taking steps toward software supply chain maturity now:
1. Collect software bills of materials (SBOMs) from your vendors
2. Invest in tools and processes that alert your team to vulnerabilities
3. Set policies for requesting patches and updates from vendors
4. Require SBOMs as part of the purchasing process
5. Take inventory of your legacy systems
6. Set technical debt policies
7. Set security debt policies
You can’t mature your software supply chain overnight, but you can start auditing your policies and processes now. By taking the following actions, your organization will be better prepared to deal with vulnerabilities in your software supply chain—both the vulnerabilities in your codebase now and the ones that arise later.
If you want to secure your software supply chain, you need to know what it is you’re securing. Your first step should be collecting software bills of material from every software vendor you currently work with.
An SBOM gives you a nested inventory of every component and sub component in a given application’s code. If you collect accurate SBOMs from all your vendors, you can monitor your entire software supply chain for known vulnerabilities.
A few key things to note when you’re doing this:
You may need multiple SBOMs from a single vendor if you’re working with multiple versions of their software (or multiple custom builds). Make sure you request an SBOM for every iteration of your vendor’s software that you use.
Make it clear to your vendors that you need current SBOMs—have them send you a new SBOM with each relevant update.
For additional security, you may want to verify that the SBOMs you’re currently working with are accurate. Invest in a tool (like Finite State) that allows you to check the SBOM documents your vendor gives you against the vendor software itself.
Several types of tools exist to help organizations discover vulnerabilities:
You may not need to use all of these tools—but you do need to make sure you can monitor all the software you use.
Furthermore, tools alone won’t keep you safe. You need to set up internal processes for checking these tools and (when necessary) taking further manual actions to remediate vulnerabilities.
What happens when you discover a vulnerability in a vendor’s software, but no patch is to be found? Establish a policy for engaging vendors on this matter. Your DevSecOps team should know whom to contact on the vendor side, how to request updates and fixes, and how to follow up.
When considering new solutions, require hopeful vendors to submit a current SBOM as part of the purchasing process. This will allow you to see how the new software will affect your risk exposure before the fact.
Fair warning: this can take vendors a while to generate, so we recommend requesting an SBOM early in the purchasing conversation. Most vendors are not immediately prepared to provide their SBOM today. In the future, vendors will likely build this into their own sales process, but for the short term, expect companies to take some time to generate and share this with you.
It’s possible that your organization is still relying on systems that are 10, 15, or 20 years old. Legacy systems don’t necessarily represent a threat in and of themselves, but they’re characteristically undersupported (and sometimes they’re not supported at all).
Vulnerabilities can live in a legacy host for years before a patch is introduced, so it’s important to understand if and where your organization depends on them. If it turns out you’re still using legacy systems, now is a good time to consider retiring them and migrating to systems with better support.
Technical debt refers to use of technology that has fallen out of date. This includes two general categories of code libraries:
A mature software supply chain has clear organizational policies for handling technical debt. This might include regular technical debt reviews and limits for how out of date a system or component is permitted to fall.
Finite State can help on this front, too. You can set policies within Finite State to alert you when libraries fall out of date, or when code components have been abandoned altogether (and thereby become obsolete). Finite State can also generate technical debt reports for your team to review.
Security debt refers to the vulnerabilities that come with your technical debt. A proper SCA tool (like Finite State) makes it easy to pinpoint what your security debt is and which libraries it’s coming from.
Just like technical debt, security debt can be sorted into two categories:
A neglected security issue might persist for any number of reasons: the fix may be expensive or time-consuming, or there may be a fear of breaking your existing code if the update is not compatible with your current systems. However, these issues usually become more difficult to fix over time: the longer you wait, the more painful the update will be. Your security debt policy should protect you from this getting out of hand by limiting the degree that any security issue goes neglected.
Fundamental flaws, on the other hand, need to be gotten rid of. A good security debt policy will mandate that they’re eliminated. Furthermore, you need an action plan for removing them entirely: set clear objectives and timelines, allocate the appropriate resources, assign a task force to take care of it, and check in on the project regularly until it’s done. Fundamental flaws have no place in a mature software supply chain.
This article lists practical steps you can take to prepare for the future—a future in which today’s status quo will be unacceptable. We built Finite State to help you do this. Finite State can:
We’re helping organizations prepare for a future in which software supply chain maturity is the norm.