Seven Practical Ways to Improve Your Software Supply Chain Maturity

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:

• You lack the time and resources to implement patches
• Your tools generate so many false positives that your team is suffering from vulnerability fatigue
• The available patches aren’t compatible with your application
• There are no available patches

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

7 practical ways to improve your software supply chain maturity

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.

1. Collect software bills of materials (SBOMs) from your vendors

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.

2. Invest in tools and processes that alert your team to vulnerabilities

Several types of tools exist to help organizations discover vulnerabilities:

• Software composition analysis (SCA) tools scan the third-party code in your application for known vulnerabilities. A strong SCA tool (like Finite State) will not only flag vulnerabilities, but also give your developers guidance on fixing them.
• Static application security testing (SAST) tools scan your proprietary code for potential security weaknesses. These tools are often comprehensive, but slow.
• Dynamic application security testing (DAST) tools crawl your running application looking for ways that it might be broken or exploited by malicious actors.
• Web application firewalls (WAF) filter and monitor traffic between your solution and the Internet—sometimes blocking traffic altogether.
• Runtime application self-protection (RASP) tools monitor activity within the application as it’s running and take proactive action when they recognize potentially dangerous behavior.

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.

3. Set policies for requesting patches and updates from vendors

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.

4. Require SBOMs as part of the purchasing process

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.

5. Take inventory of your legacy systems

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.

6. Set technical debt policies

Technical debt refers to use of technology that has fallen out of date. This includes two general categories of code libraries:

• Outdated libraries, which have as-yet-unimplemented updates
• Obsolete libraries, for which there are no planned updates

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.

7. Set security debt policies

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:

• Neglected security issues are known vulnerabilities for which a remedy is available, but hasn’t been implemented yet.
• Fundamental flaws are the vulnerabilities for which no patch is available (and probably never will be).

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.

Uplevel your software supply chain maturity with Finite State

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:

• Notify your team of vulnerabilities
• Point your developers to compatible patches
• Prioritize security issues
• Verify vendor SBOMs
• Report on technical and security debt
• Block malevolent users from exploiting known vulnerabilities with - Runtime Protection

We’re helping organizations prepare for a future in which software supply chain maturity is the norm.