Keep a record of all dependencies used throughout the target production environment. This is sometimes referred to as a Bill of Materials (BOM). Consider that different components of the application may consume entirely different dependencies. For example, if the software package is a web application, cover both the server-side application code and client-side scripts. In building these records, consider the various locations where dependencies might be specified such as configuration files, the project's directory on disk, a package management tool or the actual code (e.g. via an IDE that supports listing dependencies).

Gather the following information about each dependency:

• Where it is used or referenced
• Version used
• License
• Source information (link to repository, author's name, etc.)
• Support and maintenance status of the dependency

Check the records to discover any dependencies with known vulnerabilities and update or replace them accordingly.

This is the official guidance provided by the OWASP SAMM Team.

This guidance is based on the approved community submissions.

Evaluate used dependencies and establish a list of acceptable ones approved for use within a project, team, or the wider organization according to a defined set of criteria.

Introduce a central repository of dependencies that all software can be built from.

Review used dependencies regularly to ensure that:

• they remain correctly licensed
• no known and significant vulnerabilities impacting your applications are present
• the dependency is still actively supported and maintained
• you are using a current version
• there is a valid reason to include the dependency

React timely and appropriately to non-conformities by handling these as defects. Consider using an automated tool to scan for vulnerable dependencies and assign the identified issues to the respective development teams.

This is the official guidance provided by the OWASP SAMM Team.

This guidance is based on the approved community submissions.

Maintain a whitelist of approved dependencies and versions, and ensure that the build process fails upon a presence of dependency not being on the list. Include a sign-off process for handling exceptions to this rule if sensible.

Perform security verification activities against dependencies on the whitelist in a comparable way to the target applications themselves (esp. using SAST and analyzing transitive dependencies). Ensure that these checks also aim to identify possible backdoors or easter eggs in the dependencies. Establish vulnerability disclosure processes with the dependency authors including SLAs for fixing issues. In case enforcing SLAs is not realistic (e.g. with open source vulnerabilities), ensure that the most probable cases are expected and you are able to implement compensating measures in a timely manner. Implement regression tests for the fixes to identified issues.

Track all identified issues and their state using your defect tracking system. Integrate your build pipeline with this system to enable failing the build whenever the included dependencies contain issues above a defined criticality level.

This is the official guidance provided by the OWASP SAMM Team.

This guidance is based on the approved community submissions.