In the last post of AST Guide for the Disenchanted, we identified the minimum appsec risks that need to be addressed as a part of your DevSecOps pipeline. The two risks are: known and unknown vulnerabilities. In today’s post, we’ll focus on how software composition analysis can help you address those known vulnerabilities.

You are what you eat. Developing applications works the same way.

Software is eating the world. With the exponential speed at which applications are proliferating into every aspect of our lives, it comes as no surprise that developers often write code to assemble them. Organizations leverage an intricate supply chain to source chunks of code or whole applications as the building blocks of their larger applications. Standardization and modularity is key for scaling, but it is not considered best practice for minimizing cybersecurity risk.

Sourcing from the cyber supply chain makes sense. Why recreate code that exists and is even available for free?

Free is rarely really free. Wide code adoption is often falsely assumed to be secure. Developers assume security is an upstream responsibility, so they take the stance of, “not-my-code, therefore not-my-problem”. This is a dangerous presumption to make. But, how do you test code that’s not yours?

The challenge in securing third-party applications and code.

Enterprise applications contain hundreds of components, whether their third-party, free and open source software (FOSS), or commercial off the shelf (COTS). Security best practices and standards mandate that each of these components be verified before implementing them into your applications. Code for FOSS are publicly available, so they are simple to verify. Code for third-party applications and COTS components are not available, so they are harder to secure.

That’s where software composition analysis, or SCA, comes in. Software composition analysis (SCA) tools can scan binaries to uncover known vulnerabilities.

Listed below is an in-depth, at-a-glance view of SCA’s technical capabilities: 

Software Composition Analysis (SCA)

Description

Generates a bill of materials for applications and the corresponding known vulnerabilities within them.

Approach

Black- or white-box, depends on vendor solution

Application State During Testing

Nonrunning State

Accuracy

Medium-High; While SCA can flag vulnerable components, it does not mean that the component is exploitable or reachable. 

SDLC Phase

Design

CI/CD

Pre-Deployment and post-deployment (vendor dependent); AST solutions integrated earlier in the SDLC is desired for DevSecOps. Studies have shown testing early and often manages unexpected remediation costs and effort. 

Remediation Actionability

High

DevSecOps Best Practice

Offer a whitelist of code components developers can source from before development begins

What are the key attributes to consider in an SCA solution?

Software composition analysis has recently gained popularity due to the persistent challenge of securing the software supply chain. There’s also a plethora of options out there. There are two key buying criteria to consider.

First, is the ability to conduct binary analysis. The majority of software composition analysis tools conduct white-box analysis. However, a truly versatile SCA solution that is able to secure third-party, free and open source software (FOSS), and commercial off the shelf (COTS) must be able to consume binaries.

{{code-cta}}

Until next time…

In this post of AST Guide for the Disenchanted, we covered how to address known vulnerabilities using SCA as a part of your DevSecOps pipeline. 

Stay tuned for Part 5, to learn what solutions to leverage to address unknown vulnerabilities as a part of your DevSecOps pipeline.  For immediate information or a demo, contact us at [email protected].