Software Composition Analysis: The Changing Role of SCA

Author: Ramon Regex, VerSprite DevSecOps Team

Analyzing and improving software security isn’t a human-scale problem anymore. In the average business, the attack surface is vast and growing daily. Hundreds — even thousands — of attack vectors, machines, and mind-boggling masses of data could exist. Development, Security, and Operations (DevSecOps) teams face growing supply-chain complexity and ever-evolving threats. SCA, or Software Composition Analysis, has been one of the most popular means of detecting vulnerabilities of open-source components within software.

In a world where Open-Source Software (OSS) is the norm, with some 70-90% of development teams using OSS libraries, SCA tools can help developers identify, analyze, and control compliance and security risks in software and open-source code. OSS is a boon to developers because it helps drive innovation; nonetheless, it can expand the attack surface for threat actors.

Even though SCA can be effective for all companies in its current form, hackers have gotten more sophisticated in their attack methods, and OSS is a common attack vector. Therefore, SCA solutions will need to evolve as threat actors do.

In this blog, we’ll discuss what SCA is now and what the next evolution of SCA might be.

What Is SCA?

Software Composition Analysis uses code-base and related binaries to identify open-source components and determine applicable licenses. The process also detects dependencies within software and checks whether any known vulnerabilities exist within them. It is a crucial part of any Software Development Lifecycle (SDLC) because it helps your DevSecOps team track direct and transitive dependencies within your projects.

Once this process is completed, the output generally consists of several items:

• Software Bill of Materials
• Known Security Vulnerabilities
• License Compliance
• Operational Risk Profile

Since its inception in 2002, SCA has grown exponentially, which has led to the creation of tools specifically for software composition analysis. These tools vary in functionality, but most will automate discovery and mitigation processes. These tools will suggest a newer, non-vulnerable version of the dependency. Specific tools can take this one step further by automatically opening a Pull Request (PR), on which your test suites are executed, which maximizes developer ergonomics.

The Limits of SCA

In complex code bases, upgrading dependencies isn’t always straightforward because vulnerabilities can reside in transitive dependencies. Also, vulnerable components in application code are not always exploitable in runtime environments, which results in multiple reports of false positives. This can take significant effort to triage.

Vulnerable dependencies can exist across the entire software delivery pipeline, including development tools and plugins, build modules, or even hidden within Infrastructure-as-Code (IaC) tools.

SCA lacks visibility into these components and cannot always determine whether they have potential vulnerabilities. However, coupled with intelligent and judicious use of the proper tools and practices, SCA will still get the job done.

So What’s Next for SCA?

Anyone in cybersecurity knows that threat actors are evolving. Compromising software repositories isn’t their only weapon, so cybersecurity teams in general, and DevSecOps teams in particular, shouldn’t limit themselves to code analysis. They need to analyze and defend the entire software supply chain. Modern software supply chain security platforms should cover both infrastructure and applications.

Cybersecurity is packed with jargon and buzzwords; everyone wants to get in on the next big thing. The demand for SCA tools means that some companies will make a product and stick flashy labels. If something is hot, and people see an opportunity to generate more revenue, they’ll claim their product can do better.

The Evolution of SCA

The biggest driver of change for SCA tools is stricter government policies. Rightfully concerned about software supply chain security, new government policies require organizations to use SCA tools that provide complete visibility into the applications and software they develop, embed, package, assemble, and buy. To that end, many government agencies expect a Software Bill of Materials (SBOM) from the companies they purchase their software packages. 

To meet stricter government regulations and ensure your team’s software is as secure as possible, here are a few capabilities you should look for in SCA solutions.

Automated Policy Governance

Every company has different ways of managing OSS security and compliance risks. Whether you flag some packages manually or deny specific packages by default, it’s time-consuming. Analyzing dependencies and vulnerabilities to inform decisions takes valuable time that most developers prefer to use elsewhere. Therefore, a robust policy engine is necessary when choosing an SCA solution. Automated policy management tools allow your development team to stay on task because they won’t have to check and create rules manually.

High Signal-to-Noise Ratio

SCA solutions should make life easier for your development team. You need a tool that will deliver minimal false positives; that is, the tool should proactively differentiate high-risk vulnerability or license issues that could impact security and compliance in production. This requires a tool that can read the context within the code. Simultaneously, the tool must integrate with the developer ecosystem and not interrupt the development process.

Effective SCA tools should address risk mitigation issues in the software development lifecycle as early as possible. That means you want an SCA tool that completely integrates into your existing CI/CD pipelines, allowing users to monitor code continuously and preventing vulnerabilities from shipping to production.

CI/CD Integration

Regardless, any SCA platform you choose must provide accurate, current, actionable analysis. This will allow your developers to remediate open-source security vulnerabilities and compliance violations across the SDLC before they become significant issues. Most importantly, any SCA tool should integrate with developers’ native toolsets.

Software supply chain security has been a sore spot in the past, and it truly needs to be recognized as a separate activity within the application security ecosystem. In response to that need, a few companies have introduced tools that supposedly can extend the breadth of coverage. This new approach is called Pipeline Composition Analysis or PCA.

What Is PCA?

A potential evolution of traditional SCA is the PCA approach, which uses runtime analysis data throughout the development pipeline. The PCA approach connects all the tools and infrastructure that comprise your SDLC, providing complete visibility into your development pipelines. If you have greater coverage, you have a better chance of securing your software supply chain and stopping attacks before they happen.

You can make connections and correlations between process execution, network, and file access, giving you a better understanding of your environment and risk. It could help you triage your security posture with additional scanning and reporting tools. PCA expands the definition of dependencies and scans for them in development tools, build modules, and Infrastructure as Code (IaC) introduced dependencies.

There has been talk bandied about PCA—Pipeline Composition Analysis—as the future of SCA. It sounds fancy, but it’s simply another way of talking about Continuous Integration/Continuous Deployment (CI/CD) monitoring.

We’ll have to wait and see whether this supposed new security superhero lives up to the hype. In the meantime, you can boost your SCA capabilities with CI/CD monitoring tools and policy engines.

The Future of Software Composition Analysis

In today’s fast-paced software development landscape, security teams face the challenge of reducing risks and minimizing time-to-market. Developers are invested in open-source security and license compliance but need automated scanning and issue analysis that aligns with their daily workflows.

Ultimately, SCA tools should be designed with developers in mind. Developer adoption is critical for any SCA tool to significantly impact an organization’s security and compliance posture.

Open-source software has evolved over the past decade, and so have SCA tools. However, these tools must provide better integration with a developer’s workflow and give proactive, contextual guidance throughout the SDLC for quick and effortless remediation. Whether PCA will be that evolution is yet to be determined.

VerSprite’s DevSecOps team can provide you with actionable security insights to help your organization identify and mitigate risk efficiently throughout the SDLC. Talk with our team to find out how you can augment the security of your next build.

Sources:

1. https://fossa.com/learn/complete-guide-software-composition-analysis
2. https://cycode.com/blog/pipeline-composition-analysis-the-next-generation-of-sca/