## Introduction
Most applications rely on third-party components to provide functionalities such as logging, templating, database access, and more. These components streamline software development, saving time and effort. However, like any software, they can contain vulnerabilities, whether introduced during their creation or through subsequent updates. This means applications may unknowingly include exploitable vulnerabilities, posing potential security risks.
## Description
**Vulnerable and outdated components** are software or libraries that are no longer supported or contain known security vulnerabilities. These components can expose applications to serious risks, including injection flaws, unauthorized access, buffer overflows, and much more.
Keeping software components like frameworks and libraries up to date is key for minimizing security risks, but the process requires careful management to avoid new issues. Updates can sometimes introduce breaking changes that only surface during production. Applications that fall behind on updates may face significant challenges, especially if multiple versions must be skipped to catch up. This can delay the resolution of urgent vulnerabilities, leaving systems exposed to potential exploits. A thoughtful update process is essential, which includes thoroughly reviewing release notes. These notes often highlight important changes that could impact application functionality.
The following examples highlight the significant risks associated with vulnerable or outdated third-party components:
- [Heartbleed](https://heartbleed.com/): Heartbleed was a critical vulnerability in **OpenSSL**, a widely used library for encrypting communications. The flaw allowed attackers to read sensitive data, such as private keys and passwords, directly from the memory of servers using affected versions of OpenSSL.
- [Struts2](https://arstechnica.com/information-technology/2017/03/critical-vulnerability-under-massive-attack-imperils-high-impact-sites/): The Struts2 vulnerability was a remote code execution flaw in **Apache Struts2**, a popular Java framework for building web applications. This vulnerability allowed attackers to execute arbitrary commands on servers by exploiting improperly processed HTTP requests.
- [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell): Log4Shell was a severe vulnerability in **Log4j**, a widely used Java logging library. This flaw enabled remote code execution through a simple maliciously crafted log entry, impacting countless systems that relied on Log4j as a core dependency.
## Mitigation Techniques
Effectively managing vulnerable components is essential to ensuring the security, reliability, and compliance of modern software applications. Two key strategies for addressing these challenges are **Component tracking and management** and **Proactive vulnerability detection**. Together, these approaches enable teams to identify, monitor, and mitigate risks associated with third-party dependencies throughout the Software Development Lifecycle (SDLC). Below, we explore each technique and their integration within the SDLC.
### Component tracking and management
Track and catalog all software components in your application to gain visibility into dependencies and ensure they are properly managed. This foundational step helps identify potential risks and simplifies the process of mitigating vulnerabilities.
This can be typically achieved with a [Software Bill of Materials (SBOM)](https://www.cisa.gov/sbom). An SBOM is an essential tool for tracking and managing third-party dependencies in a project. A SBOM is a formal set of machine-readable metadata describing your software application. SBOM is a listing of all components, their licenses, version and origin.
An SBOM generally lists the following details for each component:
- **Author Name**: The creator of the component.
- **Vendor Name**: The organization or individual providing the component.
- **Component Name**: The name of the dependency.
- **Version**: The specific version of the component.
- **Component Hash**: A unique hash to identify the component’s integrity.
- **Unique Identifier**: A general ID within the SBOM for easy reference.
- **Relationship**: Defines how the component relates to the package or application.
Additional information can include:
- **Security Scores**: Indicators of the component's risk level.
- **Common Vulnerabilities and Exposures (CVEs)**: Known vulnerabilities associated with the component.
- **Severity**: The impact level of identified vulnerabilities.
There are 3 main formats:
- **[SPDX](https://spdx.dev/)**: Maintained by the Linux Foundation, it focuses on software licensing and compliance. It supports multiple file formats, including JSON, YAML, and RDF/XML, and provides detailed metadata about software components and their relationships.
- **[CycloneDX](https://cyclonedx.org/)**: Created by OWASP, it is tailored for security and DevSecOps workflows. It provides advanced metadata for dependencies, vulnerabilities, and risks, supporting formats like JSON, XML, and Protocol Buffers.
- **[SWID](https://www.iso.org/standard/65666.html)**: An ISO standard (ISO/IEC 19770-2) that tracks software installation, lifecycle, and licensing. SWID tags are typically XML-based and are widely used for asset management and software inventory tracking.
Below is an SBOM example in CycloneDX format:
```json
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"version": 1,
"metadata": {
"timestamp": "2023-12-06T12:00:00Z",
"tools": [
{
"vendor": "CycloneDX",
"name": "CycloneDX CLI",
"version": "1.4.0"
}
],
"component": {
"type": "application",
"name": "Sample Project",
"version": "1.0.0",
"description": "A sample project to demonstrate a CycloneDX SBOM."
}
},
"components": [
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/
[email protected]",
"hashes": [
{
"alg": "SHA-256",
"content": "ef6c12f4ebf9e4f8e78bd4a3a7ea6bf94f37d6e907aa48e4bbd2b5c4b99f89bc"
}
]
},
{
"type": "library",
"name": "express",
"version": "4.18.2",
"purl": "pkg:npm/
[email protected]",
"hashes": [
{
"alg": "SHA-256",
"content": "b50f0df343b6b8d5f2a5dc9477082b4b567d8b0b514c1a9f0b8bfb4a8ebc6c9d"
}
]
}
],
"dependencies": [
{
"ref": "pkg:npm/
[email protected]",
"dependsOn": []
},
{
"ref": "pkg:npm/
[email protected]",
"dependsOn": []
}
]
}
```
### Proactive vulnerability detection
Implement automated tools, such as Software Composition Analysis (SCA), to continuously scan dependencies for known vulnerabilities. This ensures early detection and prioritization of risks based on severity and impact.
Software Composition Analysis (SCA) tools have the flexibility to both generate and utilize Software Bill of Materials (SBOMs). Many SCA tools automatically create SBOMs as part of their analysis process, scanning the codebase and dependency manifests (e.g., `package.json`, `pom.xml`) to catalog all direct and transitive dependencies. Additionally, SCA tools can consume pre-existing SBOMs to analyze dependencies and assess risks.
#### Sample open source tools
- **[OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)**: An open-source tool that identifies known vulnerabilities in project dependencies using the National Vulnerability Database (NVD).
Several commercial tools are also available that offer features such as:
- Real-time vulnerability scanning and dependency analysis.
- License compliance management and Software Bill of Materials (SBOM) generation.
- Integration into CI/CD pipelines and development environments.
- Continuous monitoring of artifacts, containers, and packages for vulnerabilities.
### Integration with the SDLC (Software Development Lifecycle)
Integrating SBOMs and proactive vulnerability detection into the Software Development Lifecycle (SDLC) ensures comprehensive coverage and continuous improvement in managing third-party dependencies and reducing risks.
|Phase|Main Task|SBOM|SCA|
|---|---|---|---|
|Planning|Establish security policies and define dependency management guidelines.|Create preliminary SBOM templates for compliance tracking.|Set up SCA tools and configure policies for license compliance and vulnerability thresholds.|
|Development|Integrate security tools directly into the development environment.|Generate initial SBOMs or update existing ones as dependencies are added or modified.|Use SCA tools to provide real-time feedback, such as IDE plugins for dependency analysis and pre-commit hooks for validation.|
|Build|Automate dependency scanning during CI/CD processes.|Generate comprehensive SBOMs, capturing all direct and transitive dependencies (e.g., CycloneDX, SPDX).|Run automated vulnerability scans and enforce security gates based on severity ratings.|
|Testing|Validate the integrity and compliance of dependencies.|Cross-reference SBOMs with vulnerability databases to identify risks and validate completeness.|Leverage SCA tools to test for outdated components and transitive dependencies that may introduce risks.|
|Deployment|Ensure secure and compliant deployments.|Include SBOMs with deployment artifacts and validate them against updated vulnerability databases.|Run final SCA scans on production-ready artifacts, ensuring runtime dependencies are secure.|
|Maintenance|Monitor for emerging vulnerabilities and keep dependencies up-to-date.|Regularly refresh SBOMs to reflect changes and cross-reference with new vulnerabilities.|Use tools for continuous scanning and proactive alerts.|
#### Planning phase
- **Main focus**: Establish a strong foundation for secure software development by defining policies and selecting tools.
- **Key actions**:
- Draft dependency management and vulnerability handling guidelines.
- Configure SBOM formats to align with project requirements (e.g., CycloneDX for security workflows).
- Onboard SCA tools into the project's pipeline.
#### Development phase
- **Main focus**: Provide immediate feedback to developers, preventing vulnerabilities early in the process.
- **Key actions**:
- Integrate IDE plugins (e.g., OWASP Dependency-Check).
- Apply pre-commit hooks for dependency validation.
- Generate initial SBOMs or update existing ones as dependencies are added.
- Enforce coding standards that prevent dependency misuse.
#### Build phase
- **Main focus**: Generate and verify SBOMs during the build process.
- **Key actions**:
- Automate SBOM generation (e.g., using CycloneDX or SPDX plugins in Maven or Gradle).
- Configure CI/CD pipelines to halt builds with critical vulnerabilities.
- Ensure transitive dependencies are accurately cataloged.
#### Testing phase
- **Main focus**: Validate software integrity and detect vulnerabilities in third-party components.
- **Key actions**:
- Validate SBOM completeness and check for outdated or high-risk dependencies.
- Conduct vulnerability scans against known databases like NVD or OSV.
#### Deployment phase
- **Main focus**: Ensure secure deployment artifacts.
- **Key actions**:
- Include SBOMs with deployment packages to facilitate transparency and audits.
- Validate runtime dependencies against updated vulnerability databases.
#### Maintenance phase
- **Main focus**: Continuously monitor and update dependencies post-deployment.
- **Key actions**:
- Regularly refresh SBOMs to reflect updates.
- Monitor environments for new vulnerabilities using tools like Black Duck or Veracode.
- Schedule regular audits to ensure compliance and security.
## Python
### Versioning
Although Python has no official guidelines for versioning, it is usually done using a version string in the format: "major.minor.patch".
- The _major_ version number indicates a major release or significant change in the library, such as new features.
- The _minor_ version number indicates minor updates that do not make significant changes in the library.
- The _patch_ version number is incremented with each bug fix or security update. _Be aware that some security updates can be released in a major version if they include breaking changes._
The version constraints for the libraries required for a project can be specified in the `requirements.txt` file. Versioning is typically managed using a package manager such as [`pip`](https://packaging.python.org/en/latest/key_projects/#pip), which will install those libraries specified in the `requirements.txt` file.
Also, consider using [`pipenv`](https://pipenv-fork.readthedocs.io/en/latest/basics.html) package manager which makes use of a `Pipfile` (that contains the package versions) and a `Pipfile.lock` (that contains the actual versions installed and their dependencies). This offers additional protection against OSS supply chain injection attacks due to the hash of the package archive included for each package in the lock file.
### Dependency scanning
There are many third-party solutions available, one of which is available in pip is a tool called [`pip-audit`](https://pypi.org/project/pip-audit/). The tool sends the collection of the dependencies covered in the local project to the [Python Packaging Advisory database](https://github.com/pypa/advisory-database) and requests a report on known vulnerabilities. The flag `pip-audit --fix` can also be used to automatically update the packages that contain vulnerabilities.
### Alternatives
Additionally, there are a number of other tools available as well. Another would be:
- [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/), which can scan dependencies in Python, .NET, and Java, among other languages for known vulnerabilities.
---
## References & Resources
- OWASP:
- [OWASP Top 10 A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)
- [OWASP Cheat Sheet Series - Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)
- CWE
- [CWE-937](https://cwe.mitre.org/data/definitions/937.html)
- [CWE-1035](https://cwe.mitre.org/data/definitions/1035.html)
- [CWE-1395](https://cwe.mitre.org/data/definitions/1395.html)
- [Aquasec SBOM](https://www.aquasec.com/cloud-native-academy/vulnerability-management/open-source-vulnerability-scanning/)