Software Supply Chain Security Checklist

This is an article from DZone's 2022 Enterprise Application Security Trend Report.

For more:

Read the Report

Software security is a critical part of any product, but it can be a second-class consideration for many projects when time and budget pressures are applied. It is not enough to deliver working software; our deliveries must also be trustworthy and secured against known vulnerabilities. For many applications, the security of thousands or even millions of Personal Information (PI) records — and even entire company networks — rests upon the security of our applications. 

Since the stakes are so high, we must perform our due diligence when securing our products against vulnerabilities and earn the trust of our customers and users.

In general, vulnerabilities can come from our application code and dependencies (the software supply chain). We must be deliberate about the dependencies we introduce into our product and ensure they do not compromise our application. 

5-Step Checklist for Securing Your Software Supply Chain

The checklist below details five simple but essential steps that we can take to ensure that our software supply chain is secure and that we are delivering the most trustworthy software possible to our customers and users. 

1. Be Proactive

As professionals, we are responsible for securing our products. When we release a product, we put our names and seals of approval on the product. We are fallible, but when we release our product to customers with vulnerabilities and are not diligent in fixing them, that reflects poorly upon our company and us. 

Even when vulnerabilities come from the dependencies we include in our product, it is still our responsibility to patch our application and remove the vulnerabilities. We have decided to use those dependencies, and we must, therefore, assume the responsibility of adequately vetting and upgrading those dependencies, especially when known vulnerabilities arise. Ultimately, if our product compromises a user's or customer's security, the fault rests with us, and we must do everything within our purview to protect our users and customers. 

2. Know Every Dependency

Any code we include in our application — even transitive dependencies pulled in by our dependencies — can compromise our application. Therefore, it is our responsibility to enumerate our application's dependencies. This enumeration is sometimes called a Software Bill of Materials (BOM) and is analogous to a BOM in more traditional sectors, such as manufacturing. 

We can find a list of all dependencies (including transitive dependencies) in our application using the command-line interface for our package manager. For example: 

• Maven – mvn dependency:tree 
• Gradle – gradle -q dependencies 
• NPM – npm list --all 

We must keep our BOM up to date and in sync with the dependencies included in our product. One of the simplest ways to ensure this consistency is to generate our BOM as a step in our automated build pipeline. Each time we build our application, our build system produces a new BOM. As we add, change, or remove dependencies, the BOM generated for each build will be updated accordingly. 

3. Track the Latest Vulnerabilities

Once we know what our product depends on, we must track the security state of those dependencies. Keeping up to date with security bulletins and the Common Vulnerabilities and Exposures (CVE) system can be daunting, but there are resources we can use to help us. 

The following are some of the most common databases that contain up-to-date lists of existing software vulnerabilities: 

• GitHub Advisory Database
• US National Vulnerabilities Database
• MITRE CVE Database

4. Automate the Process

Even for the most trivial project, keeping tabs on our dependencies and cross-referencing them with security bulletins can be overwhelming. We should automate these security steps as much as possible, and our build pipeline should run them each time we build our product. Whenever possible, we should also leverage the tools already available to us. 

For example, if we host our application on GitHub, we can use Dependabot, and if we host our application on GitLab, we can use dependency scanning. 

5. Audit Dependencies

Every dependency in our product brings with it a set of vulnerabilities. Even the most ubiquitous dependencies, like log4j, can be compromised (see Log4Shell). Therefore, we should always have a minimalist approach to our dependencies. If a dependency is unused, we should remove it immediately, and if the security risk posed by a dependency outweighs its reward, we must find an alternative. Finding unused dependencies and generating warnings for such dependencies can often be performed automatically (e.g., mvn dependency:analyze for Maven) and should be added as a step in our build pipelines.

Conclusion 

We are responsible for the security of the products we deliver, even when vulnerabilities come from dependencies in our supply chain. Our customers' and users' trust in our products rests upon our diligence in finding and patching the vulnerabilities within our code and supply chain. Maintaining a professional mindset, understanding our exposure, tracking the latest vulnerabilities, automating our processes, and auditing our products go a long way in ensuring that our products meet the highest security standards and protect the data and systems of our users.

This is an article from DZone's 2022 Enterprise Application Security Trend Report.

For more:

Read the Report