10 security tool categories needed to shore up software supply chain security

By Ericka Chickowski

CSO contributor, CSO |

As security leaders progress in their establishment of software supply chain security programs, they face a good news-bad news situation with the tools available to them — literally: the technology is rapidly advancing for good and for bad.

The good news of the rapidly advancing software supply chain security technology is that the brisk pace of innovation provides increasing opportunities to gain greater visibility and transparency into the vast array of components and code that feed into software portfolios.

The bad news, however, is that experimentation and innovation are going in many different directions at the same time and the tools landscape is a confusing mash-up of new and evolving category acronyms and niche products.

Some of them are more traditional application security tools that are advancing to be more developer-friendly. Others are traditional developer tools that are bulking up security-focused controls and features to meet the challenge of supply chain risks. Still others are emerging from the DevSecOps world — purpose-built to foster mutual collaboration between those tribes.

"One of the reasons it's so hard to get a clear picture of software supply chain security is that there are so many pieces in the supply chain where something can go wrong," Tom Goings, product consultant at Tanium tells CSO. "You can have vulnerabilities introduced directly into software, like the SolarWinds example from a few years ago, vulnerabilities in common libraries like Log4j, or even something like a compromised certificate authority (CA)."

While several software supply chain security product stacks and platforms several software supply chain security product stacks and platforms that are starting to consolidate on the market, the feature mix of these products is all over the map.

The main tool category these platforms tend to center around is software composition analysis (SCA) and tools generating software bills of materials (SBOMs), those so-called 'ingredient lists' of modern software. While SCA and SBOMs tend to form the backbone of a lot of software supply chain security tools, that really should just be the tip of the iceberg for CISOs trying to build out a roadmap to support a comprehensive program for managing supply chain risks.

"When they're looking at supply chain security, people are focused on using tools like SCA and they're looking at SBOMs," Dale Gardner, senior director and analyst for application security at Gartner, tells CSO. "Those are very important parts of the solution. But they're really just kind of a very partial solution."

Many other moving parts are involved, including secrets management, dependency mapping, and management, CI/CD pipeline security, effective repository management, and more. Most experts agree that security teams will be hard-pressed to find everything they need from one vendor.

"I would argue, there isn't a single vendor that handles all challenges associated with software supply chain security in a way that would fit all organizations’ requirements," explains Michael Born, senior manager of application security at consulting firm Coalfire. He tells CSO that lack of consolidation isn't necessarily a bad thing. "It'd potentially pit organizations into risks associated with vendor lock-in and could mean the organization matures or changes faster than what the vendor could keep up with."

This fragmentation is a result not only of the organic innovation coming from several different technical perspectives (dev-focused tooling, ops-focused tooling, security-focused tooling) but also the fact that there's a range of different use cases being addressed.

"We've got to get pretty specific on which risk or which use case we're talking about to be able to find the right software solutions or overall sort of solution stack to be able to solve those," explains Sharon Chand, the cyber risk secure supply chain leader for Deloitte's Cyber Risk Services practice. "Because what kind of solution I need really will depend on where I sit in that software supply chain security scenario. If I'm a producer of software it'll look different than if I'm a consumer of software. And more often than not everybody is going to be both at certain points in the overall supply chain lifecycle."

How organizations put it all together will depend highly upon their use cases, infrastructure, and the make-up of their teams' skills and culture. Unfortunately, there's no easy button for building this stack out just yet.

The following list offers CISOs a good starter checklist for planning out the software supply chain security solution stack that will work for them. The list isn't 100% exhaustive — and it'll likely change fast. But it includes the major tool categories and features security leaders will likely want to consider for their software supply chain security roadmap.

SCA tools may be best known at this point for their role in software supply chain security, but this category's origin story started in even more prosaic territory. These tools were initially conceived to help dev teams track their open-source component usage within their builds to get a handle on license compliance. As supply chain security started to gain more traction, SCA tools built in deeper analysis and management of vulnerabilities and security risks tied to the tracked components and became one of the marque methods for organizations to generate SBOMs and govern their open-source usage. Mend.io (formerly WhiteSource), FOSSA, and Synopsys Black Duck are prime examples of this evolutionary path.

SCA isn't the only option for generating SBOMs. Some other SBOM generation methods include using command line interface (CLI) tools like CycloneDX CLI and SPDX Tool, runtime analysis like Rezilion, or binary analysis like ReversingLabs. But SCA tends to be table stakes for those vendors building out software supply chain solution stacks or ecosystems. Some of them are SCA vendors who have branched out into the other tools categories described below — through internal development or acquisition. Others may have started with a platform mentality with devs in mind from the start, including SCA within a mix of supply chain tools; Snyk is a good example of that. There have also been more partnerships like the one announced between Synopsys and ReversingLabs recently that broadens out supply chain security capabilities without locking customers into a single platform.

Securing the software supply chain at heart is an appsec problem, so it only follows that traditional appsec code scanning tools are going to play a part in this solution stack. SAST (static application security testing), DAST (dynamic application security testing), IAST (interactive application security testing), and RASP (runtime application scanning protection) tools, along with judicious use of penetration testing can help organizations test their own internal code and provide further checks into third-party code to act as a backstop for risks that "might otherwise get missed using common SCA or SBOM testing tools and techniques," says Born of Coalfire.

Maintaining multiple layers through a full slate of code scanning is crucial, he says, as are those pen test spot checks.

"SCA and SBOM products rely on known, previously identified vulnerabilities whereas a thorough application penetration assessment may identify vulnerable code usage when examining third-party libraries and frameworks that may have previously gone unreported elsewhere," he says.

As organizations create their own SBOMs and ingest SBOMs from their vendors, the aggregation, enrichment, and management of these artifacts are going to be an increasingly important part of operationalizing them. For example, 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 include component health checks like the OpenSSF Scorecard data and exploit prediction scoring system (EPSS) scores from CISA's Known Exploited Vulnerabilities (KEV) database.

Additionally, simply aggregating SBOM information across software portfolios and lines of business will be a growing concern for security leaders. This is still a newly-emerging area that hasn't really coalesced into an industry analyst-identified category, so CISOs have to look for these features in SCA+ type tooling, open source tools, and new platforms that are blazing what they hope will be their own category-defining paths. Some examples at play include Cybellum, Anchore, and Rezilion, as well as new open-source tools like Bomber.

Shared secrets scanning and management are fast moving from a standalone tools category to a feature that's being folded into every flavor of software supply chain security tooling. That's because secrets embedded in source code, configuration files, and infrastructure code are still rampant in development and live environments and there's a dire need to get a handle on the problem.

"Secrets such as credential files, private keys, passwords, and API tokens should not be committed to a source control repository," recommends a recently updated Gartner report. "Use a secrets management tool to securely store and encrypt secrets, enforce access controls, and manage secrets (that is, create, rotate, and revoke)."

This is a fundamental tooling component, as attackers can leverage shared secrets to completely undermine the integrity of an organization's software supply chain.

Dependency management and analysis is another somewhat nebulous category with a high degree of overlap with other tools categories like SCA and SBOM aggregation. But it's worth the call-out because it gets to the heart of some of the gnarliest software supply chain security problems.

Some of the biggest complaints security advocates have about the state of SBOMs today is that they still struggle to communicate transitive dependencies related to the enumerated software.

CISOs and their teams are going to need better ways to map out and manage the hidden web of dependencies that span across their applications, APIs, CI/CD pipeline components, and infrastructure as code. Some tools available include dependency mapping tools that performance and resilience stakeholders also lean on like those from Datadog and Atlassian. Additionally, SCAs and SBOM management tools often fold these features into their mix. One notable player to hit the market recently on this front is Endor Labs, which came out of stealth mode in October 2022 describing itself as a 'dependency lifecycle management' solution. Last month the firm was a finalist in RSA Conference's Innovation Sandbox.

While artifact repositories and container registries aren't security tools per se, using them together with disciplined policies and procedures can play a big role in managing supply chain risks. Setting up trusted artifact repositories and container registries is a fundamental part of the infrastructure for establishing 'secure guardrails' for developers. Offering centralized sources of approved components is a proactive way to head off problems and establish sound governance of what goes into an organization's software.

"The repositories act as a trusted source for sanctioned and vetted artifacts and software components," Gartner analysts wrote. "This enables centralized governance, visibility, auditability and traceability into software 'ingredients'."

Code signing is increasingly becoming the best practice for ensuring the integrity of code and containers as developers commit and deploy software over its lifecycle. It's a process that's not only crucial for building strong internal controls against tampering but also for building customer trust for products that are shipped to external customers. Naturally, code signing certificates are a favored target for software supply chain attackers and so CISOs and their teams are going to need to ensure they pick the right tools and establish controls to make sure their code signing process is truly secure. Some of the heavy hitters in this category include Garantir, Keyfactor, CircleCI, Cosign, and Venafi.

The continuous integration/continuous delivery pipeline is part of the software 'factory' that developers lean on to produce their code and is, therefore, an intrinsic part of the whole supply chain. As such, security tools to harden these environments are part and parcel of a sound supply chain security program. We've already tackled secrets management, which is one important facet of this category. Others include CI/CD policy and governance management, like what companies like Apiiro and Cycode are producing, as well as well-implemented privileged access control and strong authentication.

Most of the tools described so far are focused primarily on digging deep into the third-party components used within internally developed software. But what about all of that third-party commercial software that organizations don't have as much visibility into? This is where third-party risk management (TPRM) tools and processes play a role. Even with federal SBOM requirements vying to push greater transparency by software vendors in the coming years, at the moment most organizations are flying pretty blind. While TPRM risk scoring tools like SecurityScorecard or RiskRecon aren't going to solve that fully, they can at least act as a proxy for risk that could potentially have organizations identify where they need to work with certain vendors and software providers to dig deeper into their code.

"Where I think the TPRM offering can come in is if there's risk and I'm able to identify risk, maybe that's where I really want to focus my efforts around SCA and understanding the composition of the software," says Deloitte's Chand. "It becomes a risk mitigation technique rather than a peanut butter solution I spread over all of the software I'm producing or acquiring."

She says the world of software supply chain security is still missing a solid tooling link between appsec risks and business risks and thinks the next big opportunity for innovation will likely rest in how vendors and practitioners can link TPRM platforms and broader supply chain risk management (SCRM) processes with data from SBOMs and the CI/CD pipeline.

The underlying infrastructure used to test and deploy code is also code itself and a fundamental part of the supply chain. As a result, CISOs should consider at a minimum including infrastructure as code (IaC) scanning and security tools as a part of their broader supply chain security initiative. These tools tend to straddle the line between software supply chain security tooling and cloud-native application protection platforms (CNAPP), which arguably starts to get into cloud security and general security operations territory. But CNAPP offers a lot of other supply chain security support, particularly regarding container visibility and runtime security. Containers are a growing attack target in the software supply chain and runtime security measures can provide a backstop for workloads once they hit production.

Copyright © 2023 IDG Communications, Inc.