Software composition analysis (SCA) allows organizations to identify third-party and open source components that have been integrated into all applications, and for each of these components, it identifies:
- Open security CVEs (if any)
- Out-of-date library versions & age
SCA easily answers the question: are any of my organization’s applications relying on a vulnerable library? By offering a centralized application security platform and insightful executive-level dashboards that provide a holistic view of an organization’s application security posture, SCA offers the ability to track remediation trends and improve your remediation rate and time-to-fix.
It also provides a wide-array of benefits, such as visibility into multiple types of risk that can be introduced by third-party and open source components. Risks can include known vulnerabilities, intellectual property risk and technical debt related to component age.
Three SCA Use Cases
1. Top-down risk discovery
Given a critical application, there is a need to know its competition and risk profile. Applications are only as secure as their weakest parts – code that developers “built” or third-party libraries they “borrowed”. Scanning just one of these parts will not show the complete risk profile – both security and legal – for the application.
SCA allows the ability to identify third-party and open source components that have been integrated into applications, commonly known as Bill of Materials (BOM). It informs you about the licenses for each of them and identifies out-of-date libraries that should be upgraded or patched. SCA also tells you if any open source frameworks have open CVEs that must be addressed.
2. Bottom-up risk discovery
SCA also offers security control. Using open source or third-party code components (frameworks, plug-ins and libraries) significantly reduces software development time. But when there is zero-day announced, what do you do?
When a zero-day exploit is announced, it’s important to quickly know which applications are affected so the right developers can be contacted to remediate them. Using SCA, you can easily know which applications are using a particular library, either directly or transitively, and vulnerabilities can be easily remediated.
SCA also allows for multiple choices of open-source libraries that developers may use to achieve the same functionality. These can be tracked by their age and how many versions behind the latest version they are before approving a given library for developers to use.
3. License management & utilization
Lets say, for example, an organization paid for 25 licenses of a popular third-party library, but its developers are overutilizing it in 30 applications. Or, on the flip side, there may only be 10 applications that are using the licenses, so an organization would want to stop underutilizing these licenses and save on the costs. To combat these issues, SCA provides organizations with the benefit of license management & utilization.
According to the U.S. District Court for the Northern District of California, “Copyright owners who distribute their software under an open source software license may be able to enforce violations of the terms and conditions of the license both as a breach of contract and infringement of copyrights.”
If developers are using a library that has two types of licenses – a paid commercial version and a free version with an LGPL license, or commonly called Copyleft GPL- this means that they typically can’t be used for commercial applications. However, SCA provides the quick ability to know if they can or cannot be used.
SCA helps you to know how many and which applications are using a library, and thus gives more control and ability to abide by the licensing arrangements.
How to Spot a Quality SCA Solution (and How WhiteHat Fits the Bill)
Up to 90 percent of today’s source code is composed of open source components. When taking this into consideration, it would seem to make sense that SCA should be included in all static application security testing (SAST) solutions. Yet, most companies do not offer SCA within their SAST or deeply integrated in their application security platform.
In WhiteHat’s view, this is backwards. Everyone has experienced times when there are numerous tools stacked on top of each other that don’t always integrate, and it can be wildly disruptive to the process, and to the results obtained.
To counter this, companies must make sure SCA is integrated into their SAST solutions, and by extension, into their corresponding application security platforms. Having yet another SCA solution that needs to be managed separately should be avoided. And developers don’t have the time or the interest in learning how to use another different solution. Instead, they like to use the tools of their choice – tools like IDE, Jira, etc. and not security platforms.
Instead, organizations need to find a solution that is flexible, and is integrated with the existing application security platform–a solution that treats SCA findings no differently than any other vulnerabilities, and helps prioritize SCA findings alongside other vulnerabilities.
At WhiteHat, we offer SCA either standalone or integrated with SAST in its WhiteHat Sentinel Source Standard and Sentinel Essentials offerings. Both types of tests are invoked from, and results delivered to, the WhiteHat Sentinel platform, which unifies assessment and analysis.
Another way to spot a quality SCA solution is by ensuring that it understands your organization’s dependencies well, whether they are direct or transitive dependencies. This is a problem that seems easy until you start digging deep. To do so, a solution that is reliable and can detect n-th level dependencies in a dependency chain is needed. If it misses a library, it can easily miss a vulnerability.
The pace of software development isn’t slowing down anytime soon, and this won’t change as many organizations are either in the middle of their digital transformation journey, or looking to increase productivity and speed going forward. But while the pace continues to grow, it is imperative to maintain security along the way.
The solution or service that is chosen should fit the needs you have now, but keep in mind that it’s just as important to choose technology that will help you get to where you want to be in the future.
Given the speed of development and the adoption rate of DevOps release automation platforms, security teams will never be able to keep up and keep that code secure. Therefore, the SCA solution you choose must be designed to give security teams visibility into development environments.
Perhaps most importantly, finding is just half the equation. Fixing is the other half. The goal of an SCA solution is to help fix the security flaws that are found by risk-rating them and helping determine how to prioritize them, all while offering remediation guidance. Fixing vulnerabilities must be part of the plan when addressing risk in open source code.