Around 2017, the field of software composition analysis started to really take off. The whole idea was that developers could get insight into the risk posed by the open source library ecosystem they were building upon, the direct dependencies, and the dependencies nested under those. This type of scanning built upon the static code analysis insights that development teams were receiving, looking for bugs in their custom-written code. Composition analysis tools began to differentiate themselves in a few key areas:
- Ease of integration into the CI/CD process
- Proprietary vulnerabilities in addition to the public CVEs
- Language and framework coverage
- Ability to determine whether the vulnerable code is actually being used
This particular market evolved rapidly with competition between open source projects (OWASP Dependency Check), commercial vendors, and the code management tools like GitHub building native tooling to support.
Market Evolution
Fast forward a few years, Executive Order 14028 started an industry-wide conversation around Software Bill of Materials (SBOM) artifacts, which is effectively a breakdown of the dependencies and build environment that make up a given piece of software. This took place following the industry getting rocked by vulnerabilities like Log4Shell, which was just another widespread issue in the open source library ecosystem.
Similar market dynamics emerged around SBOMs, with open source projects and commercial vendors emerging to contribute to the SBOM conversation. Unlike software composition analysis, there are more layers to the conversation happening around SBOMs. Here are a few particularly interesting dimensions I’ve heard:
- Integrity signing and verification of different layers of software tying into the Zero Trust conversation
- Scanning an SBOM for vulnerabilities in the same (or equivalent) way that software composition analysis works
- Managing SBOMs for software not being written, built, and deployed internally (COTS providers, SaaS tools, etc.)
One of the fascinating things about this market shift is what it does to the existing application security tools and platforms.
Collision in the SBOM Market
Software composition analysis vendors have been expanding their features or consolidating with other vendors to be more inclusive of other dimensions of the application security space. This growth is effectively trying to create the “single pane of glass” application security platform: scanning libraries, custom code, containers, infrastructure as code, integrating with bug trackers, and so on.
On the flip side, the SBOM discussion continues to build momentum and if (more likely when) organizations begin to utilize SBOMs for both internally developed and third-party software. Then, it alleviates some need for software composition analysis in its purest sense. To expand on that last point, even if a security team saw 100% adoption of its SCA tooling by the development teams at its organization, that would still leave all of the SBOMs of COTS tools running across the organization as well as SaaS or PaaS tools running.
The total addressable problem space is larger than the internal development teams and you don’t have the same ability to integrate into a CI/CD pipeline for a third party.
With that said, will the application security platform companies change the way they bundle and license their products? Will they begin to sell access to their data instead of, or on top of, their opinionated toolset?
Questions a CISO Must Ask
These changing market dynamics prompt a number of questions that I believe must be asked while designing and building an application security program. Some of these questions are consistent with other dimensions of the security field while others are more AppSec-specific.
- Do we plan on ingesting SBOMs from third parties? If so, do we want to manage two different tools for SBOMs and SCA?
- How important is it that we have one tool or platform to handle many different problems versus a bunch of different tools and providers?
- Do we plan on building integrations across different phases of the development lifecycle?
- Do we plan to ingest or report on data being collected from different phases of the development lifecycle?
- What parts of this process are we comfortable being handled by SaaS solutions versus running it ourselves or using open source?
- How much adoption can we expect to get from development teams on the security tools we’re purchasing (i.e., number of total code repositories versus number integrated with SCA)?
There is no “right” answer, of course. Every organization and security program has a different and unique context. But thinking through these kinds of questions can help reduce risk or surprises as things unfold.
Want more cybersecurity insights? Visit the Cybersecurity channel:
