Model | Implementation | Secure Build | Software Dependencies
Benefit
Available information on known security issues in dependencies
Activity
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.
Question
Do you have solid knowledge about dependencies you're relying on?
Quality criteria
You have a current bill of materials (BOM) for every application |
You can quickly find out which applications are affected by a particular CVE |
You have analyzed, addressed, and documented findings from dependencies at least once in the last three months |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Benefit
Full transparency of known security issues in dependencies
Activity
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.
Question
Do you handle 3rd party dependency risk by a formal process?
Quality criteria
You keep a list of approved dependencies that meet predefined criteria |
You automatically evaluate dependencies for new CVEs and alert responsible staff |
You automatically detect and alert to license changes with possible impact on legal application usage |
You track and alert to usage of unmaintained dependencies |
You reliably detect and remove unnecessary dependencies from the software |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Benefit
Handling of security issues in dependencies comparable to those in your own code
Activity
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.
Question
Do you prevent build of software if it's affected by vulnerabilities in dependencies?
Quality criteria
Your build system is connected to a system for tracking 3rd party dependency risk, causing build to fail unless the vulnerability is evaluated to be a false positive or the risk is explicitly accepted |
You scan your dependencies using a static analysis tool |
You report findings back to dependency authors using an established responsible disclosure process |
Using a new dependency not evaluated for security risks causes the build to fail |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Stream Guidance
- SAMM team guidance Google Doc
- Be the first to add to the Community guidance for this Stream!
Want to contribute?
Complete this Google Form with guidance for this Stream.
To learn more about Stream guidance for the SAMM model, see the Stream guidance page.