Software Composition Analysis Scans

Recently it has been stated that "the average software application depends on more than 500 open-source libraries and components". And the fact is that many times, the libraries used in the applications bring with them other dependencies. There are direct and transitive dependencies. The latter are the necessary components for the components directly linked to the application. It has also been said that, nowadays, almost all existing applications make use of these resources, and it has even been estimated that open-source code constitutes more than 75% or 80% of the code of the average application. As we once shared in this blog, proprietary code ends up serving more as an assembler and function invoker. (For more details on open-source software, read this post.)

However, several issues arise with the growth of the open-source ecosystem and the extensive use that applications make of these resources. Many developers and companies don't pay enough attention to which components they are using. They can easily lose track of the material they have in their products and the associated dependencies. The management of dependency trees is becoming more complex, and the exposure to risk increases as components are introduced into applications. The latter is due to the existence of bugs and vulnerabilities within these resources. Many organizations do not take into account the quality and security flaws that may be present in open-source components. This is where the process we focus on in this post comes in: software composition analysis (SCA). (By the way, to know what to consider when choosing open-source code to use, read this post).

As we said, SCA scans can report the application's open-source components. Specifically, the tools can generate a "software bill of materials" (SBOM). This is an inventory, a detailed list of resources and dependencies. An SBOM is typically expected to provide each component's name, version, file path or location in the scanned app, release date, source, checksum and license information, among other data. SBOMs can be generated by scanning manifest files (files with metadata for a set of files) or build artifacts (to apply binary fingerprinting). Even a mixture of both approaches can be used for more precise reports. Achieving this will depend on the capabilities of the SCA tools. SBOMs are usually delivered as text files in JSON, XML, or similar formats.

After SBOM, one of the objectives of SCA scans can be to help detect license conflicts. The idea is that the application's owner can solve them and avoid future legal disputes, such as those related to compromised intellectual property. The SCA, in this case, identifies the open-source software licenses associated with the components being used within the application for comparison with the policies of the organization involved. Although access to the source code of those resources is free, its use may be limited by some restrictions. Licenses for open-source code may vary in their requirements for rights such as copy, modification and redistribution.

We know that there are hundreds of open-source licenses that have unique requirements for people who plan to use the resources for personal or commercial purposes. There are also licenses with a wide variety of requirements within them. They can be so many that it comes to be considered a "negative aspect of the open-source movement because it is often difficult to understand the legal implications of the differences between licenses." The most common types of licenses in open source are those categorized as permissive. These tend to manage fewer restrictions on the use of components. They often do not require monetary or intellectual compensation and, therefore, represent a low risk. On the other hand, the riskiest, especially for commercial use, are the so-called reciprocal or copyleft licenses. These require some compensation for the use of the code.

One of the fundamental objectives in SCA scans, which, in fact, is the one we pay most attention to at Fluid Attacks, is vulnerability detection. Specifically, what we have here is a correlation of components with databases of known security vulnerabilities, such as the National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposures (CVE). The tool identifies the specific versions of the components used in the application and, as a product of the comparison with the databases, points out in them the associated or corresponding vulnerabilities. Depending on the configurations, some tools can report whether such vulnerabilities are exploitable. There are tools that even provide recommendations for vulnerability remediation.

When a vulnerability in open-source code is publicly reported, as was the case recently with "Text4Shell" (similar to the notorious "Log4Shell") in the Apache Commons Text library, it is not long before means of exploitation are also published and become effective. The team in charge of an SCA tool must ensure that it can identify this vulnerability as soon as possible. Ideally, an SCA tool should keep up to date with new vulnerabilities emerging. After accurate SCA scanning with the updated tool, a company will be able to know if its application uses the affected component (if it didn't already know). It will see if the resource has such a vulnerability and what it must do to remediate it. (In the case of Text4Shell, this is resolved with the update delivered by the Apache Software Foundation.) The sooner the company discovers all this, the better for the remediation task and reducing its risk exposure.

At Fluid Attacks, we recognize the importance of early and continuous implementation of SCA scans. We focus primarily on helping you identify security vulnerabilities in your open-source components and direct and transitive dependencies. We have several public sources and our own dataset for vulnerability detection. In addition, we are always looking to keep up to date with new security issues as they arise. For this, we are supported by our security research team.

At Fluid Attacks, we are part of an expansive modern DevSecOps culture, and we help you in its implementation. We can then put our SCA tool into action from the beginning and during the phases of your SDLC, keeping pace with your developers. We seek to reduce obstacles that prevent fast and secure software development as much as possible. Every time your team adds new components, you can ask for an assessment and receive SCA reports (including SBOMs) with evidence and recommendations. You get all these reports on our platform. There, you can understand, manage and prioritize the vulnerabilities to be remediated. It's worth noting that no matter whether or not a vulnerable open-source code library or component is being invoked for execution from your app at that time, we help you detect and remediate it to avoid either present or future security risks.

To complement the work of SCA scans, we have automated SAST and DAST and manual penetration testing. Some time ago, we published here a post where you can know the differences between SAST, DAST and SCA. Generally speaking, while SCA focuses on vulnerabilities in the open-source software components you use, SAST pays specific attention to vulnerabilities in the source code your developers write for your application. DAST, meanwhile, looks at the running application to detect vulnerabilities in its functionalities and operations. On the other hand, manual pentesting focuses on more complex issues that the tools miss, including, for example, business logic flaws. In fact, the manual work of our ethical hackers also allows the verification of the tools' results and the detection of zero-day vulnerabilities, thus seeking to avoid false positives and false negatives in final reports.

If you are interested in detecting vulnerabilities with our SAST, DAST and SCA tools, we invite you to subscribe to our 21-day free trial. If you have any questions, do not hesitate to contact us.