In this final instalment of articles exploring security test automation, I take a closer look at Software Composition Analysis (SCA).
Open source software has grown considerably over the last few years. As engineers struggle with the writing of code that meets ever-increasing demands of the business, they do not want the distraction of writing logic to integrate those business rules into the architecture of the application. Instead, they want to use code that already does boring stuff so they can focus on adding value to their products and delivering solutions faster. The result is the proliferation of open source software adorning application code. Typically, around 80% of application source code produced by an organisation is written outside the organisation. This raises a lot of questions: Do you know which third party components are used in your applications? Are they secure and compliant? Are you compliant with their license agreements? Are there any unsupported or incompatible components? Without having this visibility, you are at risk of exposing your organisation to potential security breaches, license misuse and potentially difficult-to-find runtime errors.
This is where Software Composition Analysis (SCA) tooling helps. Basically, SCA tools scan your applications to identify which versions of open source software (OSS) components are used. Furthermore, they continue down the dependency chain to identify all versions of OSS within your application whether directly referenced or indirectly referenced. They then determine whether there are known vulnerabilities within those components, cross-referenced with a vulnerability database such as the National Vulnerability Database (NVD) maintained by the National Institute of Standards and Technologies (NIST), or a custom vulnerability database (more on this shortly). The severity of each vulnerability is given a score based on how easy it is to find and exploit, and the impact it would have. This is known as the Common Vulnerability Scoring System (CVSS). Most SCA tools will document how to remedy the vulnerability. This usually involves upgrading to a more secure version of the component, or switching to a more secure component with similar functionality.
Although the aforementioned NVD contains a long list of common vulnerabilities, it is by no means comprehensive. Many SCA providers maintain their own lists of vulnerabilities that supplement the NVD. Some have greater coverage than others, such as focusing on specific languages and frameworks. Therefore, when choosing which tools to use, it is important to assess their vulnerability coverage, as well as their accuracy and ability to help engineers not only identify vulnerable components, but fix them too.
The dependency graph can be very deep within an application which means that a few lines of code written by one of your engineers that uses one or more third party components, can potentially pull in 10s or 100s of other dependencies into the application. A good SCA tool will help your organisation establish a list of dependencies directly or indirectly used within your applications. This visibility is crucial to managing your vulnerabilities and, as explained next, your licenses.
SCA tools can determine whether the licenses associated with each component are being adhered to correctly within your application. There are many types of licenses, some more permissive than others. For example, proprietary licenses are normally associated with commercial products and are normally closed source, meaning that you enter into a commercial agreement to procure the license for exclusive use within your organisation. However, free and open source software (FOSS) is normally much less restrictive. Nevertheless, some open source licenses apply certain rules to restrict how the software is shared and used within your organisation and with your customers. SCA tools flag these types of licenses allowing you to make choices related to your organisation’s licensing strategy.
The rate at which open source components are added to applications within an organisation, and the rate at which new vulnerabilities affecting those components are discovered means that you should use SCA tools continuously to monitor your software. Therefore, most SCA tools integrate into the CI/CD pipeline allowing your engineers to identify issues as soon as they appear. A number of SCA tools can also integrate with the integrated development environment (IDE) giving engineers the opportunity to identify and fix issues while writing code, when it is cheaper and less disruptive to do so.
I strongly recommend that your organisation’s automated security testing strategy includes software composition analysis. If you choose not to, you are effectively excluding a significant amount of your application’s codebase from security analysis. Although SAST, DAST and IAST are effective at targeting source code written by your own engineers, this accounts for a small proportion of your entire code base. Having visibility of the vulnerabilities and licensing rules within the open source components is crucial for keeping your customer data secure. In fact, SCA and SAST, are both static analysis tools, and complement each other within an automated security testing framework. While SAST, as well as DAST and IAST, identify vulnerabilities in your application’s source code, SCA identifies vulnerabilities in your application’s dependencies. Thus giving you a comprehensive overview of your application’s vulnerabilities.
If you are interested in learning more about how automated security testing improves the security of your products without impacting delivery cadence, we are happy to help.