Software supply chain security is rapidly advancing but bringing both good and bad news to security leaders implementing the programs. On the good side, it provides an increasing opportunity to gain visibility and transparency into the vast array of components and code that goes into software portfolios. On the bad side, experimentation and innovation are going in many different directions at the same time, making the tools landscape confusing. There’s a range of applications available, from traditional application security tools that are advancing to be developer-friendly to tools in the DevSecOps world built to foster mutual collaboration between those tribes.
There are so many pieces in the supply chain where something can go wrong because you can have vulnerabilities introduced directly into software, vulnerabilities in libraries, or even with a compromised certificate authority. Even with several software supply chain security product stacks and platforms starting to consolidate on the market, the feature mix of these products is still all over the map.
Software Composition Analysis (SCA) and tools generating software bills of materials (SBOMs), so-called “ingredient lists” of modern software, form the backbone of many software supply chain security tools. However, that’s not enough to build a comprehensive program to manage supply chain risks. Experts agree that security teams will be hard-pressed to find everything they need from one vendor, and there is no gold standard for software supply chain security.
The development of a software supply chain security solution stack will depend highly on an organization’s use cases, infrastructure, and the make-up of their teams’ skills and culture. While there is no easy way to build this stack out, there are ten categories that CISOs can tick off when creating a roadmap for their software supply chain security stack:
1. SCA and SBOM generation
2. Code scanning and pen tests
3. SBOM enrichment and aggregation
4. Secrets management
5. Dependency mapping and management
6. CI/CD pipeline security
7. Repository management
8. Risk profiling and scoring
9. Incident response
10. Supply chain visibility and analytics
SCA tools are initially conceived to help development teams track their open-source component usage within their builds to get a handle on compliance. Synopsys Black Duck, Mend.io (formerly WhiteSource), and FOSSA are examples of these tools. While SCA plays the leading role, some other SBOM generation methods include using Command Line Interface (CLI) tools, runtime analysis, or binary analysis. Traditional Appsec code scanning tools like SAST, DAST, IAST, and RASP are required to secure the software supply chain further and provide more checks into the third-party code.
To operationalize SBOMs, the aggregation, enrichment, and management of these artifacts are going to be an increasingly important part of the process. Adding vulnerability exploitability exchange (VEX) information will be an increasingly important part of contextualizing SBOMs. Similarly, data that these tools could potentially enrich SBOM information with includes component health checks like the OpenSSF Scorecard data and exploit prediction scoring system (EPSS) scores from CISA’s Known Exploited Vulnerabilities (KEV) database.
Shared secrets scanning and management are rapidly becoming a feature that’s folded into every flavor of software supply chain security tooling, and secrets embedded in source code, configuration files, and infrastructure code are a growing concern.
Supply chain visibility and analytics involve viewing the entire supply chain, from software development to the organization’s deployment. Risk profiling and scoring tools are used to assess third-party and internal software for vulnerabilities. If a supply chain security failure occurs, companies must have a plan. Therefore, creating an incident response plan and investing in CI/CD pipeline security is vital.
In conclusion, software supply chain security is more relevant than ever. However, organizations can only ensure supply chain security by having a comprehensive plan and using multiple tools to protect themselves from vulnerabilities. Since there’s no “easy button” to build the software supply chain security solution stack, security leaders must assess their organizations’ needs and use cases to fully understand the risks and plan appropriately.

