Software composition analysis 101 Information Security Specialist

The term software composition analysis (SCA) is relatively new to the security world. But similar approaches have been used since the early 2000s to indicate security verifications on open source components. SCA has become an evolution of that. A SCA tool allows you to gain visibility into your open source components so you can manage and mitigate any security, license, or compliance issues. Using a SCA tool with advanced features such as automation, and integration throughout your architecture can help you build and deploy quicker and safer.

How it works

But how those SCA tools work, and how can they help identify and remediate issues on open source libraries that are being used in your codebase? Well, first, to be able to generate a graph of the components that are part of specific software and any issues related to them, we need to rely on at least three pieces of information:

• Application Manifest: A file that gives instructions on how the software should work, provides a list of dependencies required, and may also contain required permissions and versions compatibility
  
• Vulnerability Data Sources: A public or private database of vulnerability information. The most common public one is the National Vulnerability Database (NVD)
• Dependency Metadata: The metadata related to the dependencies you have on your code, such as version, packaging, license, etc.

SCA tools generate a Software Bill of Materials (SBOM) including the identified source code, which is then checked against several databases, including the NVD. By comparing the SBOM against other databases, you can quickly identify and remediate any critical security or legal issues.

Challenges of open source components

With the information above, you can better understand how your application is built and its open source software. You can also identify which libraries are outdated or have a known vulnerability in them. This is great, but there are other issues that you need to be aware of when applying this technique or using an SCA tool to identify the problems on third-party software.

1. Indirect dependencies

First, there are the direct dependencies, which are the ones you call directly in your code. Those are easier to list, identify their versions, and fix. But then, they can also depend on other libraries that they use, and so on. These are called indirect or transitive dependencies. If those are outdated or vulnerable, it will be hard for someone to fix them directly unless they are the owner or maintainer of that code.

2. Unreported security bugs

It is ubiquitous for security researchers to make a vulnerability public by creating a CVE and providing details on how the attack works and how to fix it. But in the open source world, not every vulnerability gets a CVE. Why? Mainly because the CVE process is prolonged and centralized. Usually, there is no benefit for a developer to report a security bug unless they need someone to fix it for them.

3. Increased effort

The effort to remediate those issues found on third-party software is much higher than the effort to identify them. It is not just simply updating the libraries to the latest version. It requires the execution of a series of unit and regression tests to ensure that everything is still working as intended. And that, most of the time, either doesn’t exist or isn’t automated.

Considerations for choosing your SCA tool

SCA tools and techniques are here to stay, and their usage is increasing in many organizations where security is a priority, especially now with the increase of Supply Chain Attacks. Security teams can’t keep up with all the new vulnerabilities being published daily. Make sure to look for solutions that can:

• Enable deeper insights via continuous monitoring, scanning and the latest CVE knowledge from a robust vulnerability database
• Provide extensive reporting into open source risks across monolith and microservices applications such as outdated libraries, versions of components used, and more
• Prioritize and auto-remediation of critical alerts to help developers fix issues quickly without interruption to workflows
• Seamlessly integrate into DevOps pipelines and with their favorite tools, such as GitHub, Azure Developers, and notification systems like Slack and Jira
• Uncover licensing issues before deployment, ensuring continuous compliance and avoiding data breaches and fines
   

Next steps

Trend Micro has partnered with Snyk to bring you Trend Micro Cloud One™ – Open Source Security by Snyk. This innovative solution provides automated visibility into open source risks for security operations teams. See how Trend Micro Cloud One – Open Source Security by Snyk can help you identify, manage, and resolve open source risks with a free 30 day trial.

Want more information? Check out this video.

Read More HERE