The Importance of Third-Party Dependency Management in Software Development
In today’s development world, it is common practice to rely heavily on a variety of third-party components, libraries/packages, and frameworks to expedite development work. While these components can be useful, using them in our applications also introduces risks that could make our application vulnerable to certain attacks.
Security is a fundamental aspect of application development, especially in the context of the imminent European Cyber Resilience Act (CRA). This law will require companies to take security measures throughout the software development lifecycle. Therefore, at Capitole we believe that it is extremely important to adopt measures to protect our applications from the threats that may arise from these third-party dependencies.
This is where Software Composition Analysis (SCA) comes in.
What is SCA?
SCA is a process of identifying and evaluating the security risks associated with software dependencies in our projects. Its goal is to help us obtain an inventory of all third-party components used in our projects. Thanks to this inventory, we can determine which dependencies could be affected by known vulnerabilities, such as those identified in the Common Vulnerabilities Enumeration (CVE) system.
As we mentioned earlier, using third-party components can present several risks, including:
Obsolete components: Not updating our project dependencies can lead to vulnerabilities that have been patched in newer versions.
Known vulnerabilities: Even recent versions may have vulnerabilities that have either not been discovered or have not been patched yet, so it is important to be aware of them to mitigate them.
High-risk components: These are components that have access to sensitive data and are critical to our application’s security. SCA helps us identify these components and take additional security measures to protect them adequately.
Therefore, it is important that we integrate mechanisms into our development cycle that allow us to audit these components that we do not develop ourselves.
How to implement SCA?
To implement Software Composition Analysis (SCA) in our projects, we will rely on the tools provided by OWASP (Open Web Application Security Project). This process consists of three fundamental steps:
Step 1: Analysis
All software dependencies are identified using the previously mentioned inventory or bill of materials (BOM).
Step 2: Identification and Detection
Known vulnerabilities (CVEs) present in those dependencies are detected.Step 3: Mitigation
The recommendations suggested to mitigate the risk associated with these vulnerabilities and prevent their exploitation are followed.
To carry out this process, we will use three OWASP tools, all of which are open source and free:
- OWASP Dependency Check: This tool scans our project for dependencies, compares them to a database of known vulnerabilities, and generates a detailed report that includes the criticality of the vulnerabilities, their description, and possible solutions. To implement this tool in our project, we will download it from https://owasp.org/www-project-dependency-check and run the command at the root of our project. As a result, we will obtain HTML with the analysis results.
- OWASP Cyclone DX: This tool facilitates the generation of our Bill of Materials (BOM), which is essential for analyzing our dependencies. To do this, we will use its repository and choose the version depending on the project in which we want to run it (Node, Python, Maven) https://github.com/CycloneDX When we run the tool, we will obtain a JSON with the list of materials. WASP Cyclone DX: This tool makes it easy for us to generate our bill of materials (BOM), which is essential for analyzing our dependencies.
- OWASP Dependency Track: Finally, this tool provides us with a control panel where we can organize our projects. It feeds on the Bill of Materials (BOM) generated with Cyclone DX to identify our dependencies and manage them effectively. To use Dependency Track, on the one hand we will need a Bill of Materials (which may have been previously generated with CycloneDX) and deploy the docker that they provide us on their website https://docs.dependencytrack.org/getting-started/deploy-docker
These tools that OWASP provides us with are multiplatform tools so we can run them in all types of projects. In addition to identifying vulnerabilities, as NPM audit could do, it also analyzes the age of the components and the software licenses of them, apart from which they can be integrated with tools such as Jenkins and the results of the reports can be generated in different formats.
Recommendations
By following these recommendations, we will be ensuring the security of our project with respect to third-party dependency management:
Use resources from trusted sources: When selecting libraries and frameworks, we must make sure that they come from trusted and maintainable sources. This involves considering aspects such as update times, reputation on platforms like GitHub, and the effective resolution of reported issues. Opting for trusted sources reduces the risk of introducing vulnerabilities into our project from the start.
Keep components updated: It is recommended to perform periodic updates of our components. In this way, we can ensure that we are up to date with security patches and bug fixes, thus mitigating the risk of exploitation of known vulnerabilities.
Conclusion
In conclusion, effective management of third-party dependencies in software is crucial to ensure the security and integrity of our projects. By integrating SCA into the development cycle of these, we can identify and mitigate the risks associated with the use of external components.
Bibliography:
- https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
- https://owasp.org/www-community/Component_Analysis
- https://owasp.org/www-project-cyclonedx/
- https://owasp.org/www-project-dependency-check/
- https://owasp.org/www-project-dependency-track/
Alberto Castillo Molina
Senior Back-end Developer at Capitole
Your Content Goes Here