Spice up Your Software Supply Chain Security

Dependency Validation

Introduction

This is the first of several blogs I will do on securing Software Supply Chains (S3C) which will cover topics such as:

• SBOMs
• Provenance
• Security and Compliance
• Observability

This blog will outline how you can improve your Software Supply Chain Security practices to reduce the opportunities for a bad actor compromising your builds while you incorporate internal or external dependencies with your code. These include items such as libraries, scripts, etc and their source. It will also suggest tooling to help you achieve this.

Most companies have implemented some form of a software supply chain practice at this stage. These usually cover the basics of coding, storing, building, packaging, and artifact storage. Many have yet to make their software supply chain practice secure. Remember the SolarWinds Orion compromise or the infamous and widespread Log4J Log4shell vulnerability?

The CyberArk 2022 Identity Security Threat Landscape Report shockingly stated:

“64% of respondents could not stop an attack from a compromised software supplier. At the same time, 71% of organizations were victims of software supply chain attacks, resulting in data loss or asset compromise”.

Bad actors are becoming very efficient at exploiting these stage 0 vulnerabilities.

Designing security into a SSC practice should be done upfront, not as an afterthought. This will reduce the attack surface and vectors available to bad actors. See the SLSA website for examples of source and build attack vectors. It will also save a lot of time, effort, and pain for all concerned. It’s vital all stakeholders play their part and make it part of your company’s SSC culture from the beginning.

Mitigating dependency risk

The 16th century English philosopher Sir Francis Bacon wrote:

“Knowledge is power”

Ok, he wasn’t talking specifically about external dependencies but he could have been, in that the more you know about the dependencies you, ahem, depend upon, the better you can evaluate their security posture and the risk they pose if used within your organisation. It is not practical to manually review all the external libraries and Images you are probably using in your team, let alone company, so automation and tooling is key.

With that in mind I’ll discuss some actions you can take now which will greatly increase your knowledge of dependency usage, and as part of this discussion I will mention various tools I’ve received positive feedback from clients about.

1. Understand and manage where dependencies can be pulled from. Conduct an audit by scanning your source code repos and rather than allow direct pulling from upstream, public registries, introduce an internal, trusted registry service from which all external dependencies should be pulled. As well as JFrog’s Artifactory, the major hyperscalers (GCP, AWS, Azure) all provide private image and artifact registries which have the ability to proxy upstream sources as well.
2. Every dependency that is pulled into your organization should be scanned for vulnerabilities on a regular basis. There are a multitude of open source and commercial tools for doing this. A typical approach is to include it as part of your Continuous Integration (CI) pipelines, however artefacts should be scanned regularly as new vulnerabilities are found all the time, so you can’t just depend on scanning as part of your build process.
3. Keep a central inventory of what dependencies are used in which applications and in which environments. This information is invaluable when you need to quickly understand the implications of a particular Common Vulnerabilities and Exposures (CVE) for your organization. We have found OWASP’s Dependency Track and Defect Dojo tools useful for the purpose.
4. When evaluating whether to use a particular open source project, if it is hosted on Github, use Scorecard to understand its security health. Also search for the project on deps.dev.

Tools

There are many tools, both open source and commercial, for scanning and evaluating images, code libraries and other artefacts. These are the tools I’ve received positive feedback from clients about:

Artifact Registries

• Artifactory
• GCP Artifact Registry
• Harbor

Scanning:

• Cloud infrastructure configurations misconfigurations — Checkov
• Container Image Vulnerability Analysis — Trivy or Grype
• Code Vulnerability Scanning — Snyk
• Code Quality Analysis — SonarQube

Artifact inventory management: Dependency Track or Defect Dojo

Evaluating an open source project: Scorecard or deps.dev

Summary

Implementing Dependency Validation as part of your Supply Chain Security is vital. Bad actors are targeting companies earlier and earlier in their development life cycle. This makes it even more important for companies to secure their SSC practice now rather than pay the price later.

Getting buy-in from all stakeholders up front as a culture change can be the hardest hurdle to overcome. Do your due diligence up front, and put in place the validation and controls as a matter of urgency. You won’t regret it.

There are some excellent initiatives out there you can refer to regarding Supply Chain Security including:

• Supply chain Levels for Software Artifacts SLSA (pronounced Salsa)
• OWASP Foundation Software Component Verification Standard.
• National Cyber Security Centre UK (NCSC) Supply Chain Security Guidance
• Centre for Internet Security (CIS) Software Supply Chain Security Guide
• NIST National Initiative for Improving Cybersecurity in Supply Chains (NIICS),