5 steps to increase your software supply chain security program

BY ERIC SHERIDAN

How can security teams better keep their products protected from code to cloud? By implementing a software supply chain security program.

Every software company thinks their products are secure—but how can organizations really know that they are?

Product or application security shouldn’t come as an afterthought once development is done. And, while many teams are including security earlier into the software development lifecycle (SDLC), security should really be injected at each step of the SDLC—especially since the majority of software creation contains third-party components.

How can security teams better keep their products protected from code to cloud? By implementing a software supply chain security program.

WHY SOFTWARE SUPPLY CHAIN SECURITY MATTERS

Much in the same way that we think of a supply chain in an industry like manufacturing—sourcing raw materials, having them shipped to a factory, assembly, distribution—we should think of a supply chain when it comes to software development. The software supply chain encompasses all the people, processes, and technologies used to write, build, test, deploy, operate, and consume software. Just like you would want to keep all the stages of a manufacturing supply chain secure, organizations should prioritize the ways in which they can keep all the stages of the SDLC secure.

The reasons for prioritizing software supply chain security are many. A number of data breaches today happen through third-party software, and by 2025, Gartner estimates that 45% of organizations will experience an attack on their third-party software’s vulnerabilities. Additionally, 63% of organizations lack centralized control over their third-party relationships, meaning they trust that the third-party developers have done their due diligence in making that software secure. At the end of the day, your organization wants to deliver a product that is secure from base code to deployment and beyond, free from vulnerabilities that would compromise your customer’s data and assets.

Where can those vulnerabilities happen during the SDLC? It’s rare that software is written from scratch today, as it is typically assembled from components other people wrote. You inherit not just the useability of the third-party component, but the risk associated with poorly-written or maliciously-written code as well—as has been the case in the rising number of open-source developers carrying out activist movements through various protestware. You’re also using components created by someone who doesn’t report to you, doesn’t follow your security practice, and has no obligation to respond to your request for changes. How do you secure that?

These reasons, and many more, are why security teams need to be diligent in securing each step of the software supply chain.

FIVE STEPS TO BUILDING A SOFTWARE SUPPLY CHAIN SECURITY PROGRAM

Creating a way to secure your software supply chain is a necessity if you want to reduce risk for your customers and have a more thorough understanding of the code-to-cloud development of your products. In order to start building a program, follow these five steps.

Step 1: Inventory Your Assets

The first step is to understand what assets you actually have in your organization so you’ll have a comprehensive understanding of what needs to be secured.

As you go about doing this, think beyond just third-party components to the people, repositories, infrastructure, development toolchains, and other contributors to the development of your products. Certainly use open-source tools like Backstage to help you catalog your software, but don’t assume the tools in this space are accurate. Trust, but verify.

Step 2: Prioritize Your Assets

Now that you have a catalog of your assets, the next step is to prioritize them to see which problems or concerns you need to solve first. Do so by adding context to what they are so that your team’s limited time, resources, and budget can be allocated efficiently. For example, knowing what assets constitute a “lunch menu app” and which ones constitute an “HR admin app” can help you rank your security needs appropriately.

Try to avoid total reliance on internal questionnaires for this process. Instead, leverage the past results from existing security testing tools at your disposal, which can provide additional insight. Or, just have a conversation with the stakeholders over a team lunch to learn more.

Step 3: Run Your Analysis

Next, begin running software composition analysis (SCA) tools against your prioritized assets, generating digitally signed SBOMs along the way. Once you and your team gain confidence in the tooling, integrate them into your CI/CD pipelines.

Make sure that you have an understanding of how your teams build apps before selecting the software composition analysis tools that you’ll use. Ultimately, you’ll want to have whatever you pick integrated and automatically enforcing policies in the future. Again, don’t assume the results are 100% accurate. Take time to review and select those tools that work best for your team.

Step 4: Verify

Once you’ve run your analysis, digitally sign and verify all software release artifacts. As you select a strategy, choose one that’s “transparent but visible”—in other words, it happens automatically without everyone having to understand how it works. Cosign and Connaisseur are great examples of tools that help achieve this in the Kubernetes space.

However, it’s easy to overlook that this strategy is actually being implemented. Consider developing some basic scripts that periodically verify whatever configurations that are necessary are in place, similar to the concept of a health check.

Step 5: Require Digital Signatures For External Assets

Finally, require digital signatures for all external assets and verify the signature before consumption. Again, you can do this through automation to save time and energy. Consider capturing several architectural patterns that document how to implement this in a few scenarios based on technologies common within your organization. However, make sure to only accept signatures produced using certificates backed by certificate authorities you trust.

BETTER SECURITY FOR YOU AND YOUR CUSTOMERS

Great product security happens at every step of the development lifecycle. Teams who want to put better, more thorough security practices in place can start with the steps above to reduce overall risk, improve your security posture, and ensure that your customers will be safe in the future.