+I-SB-B Stream B: Software Dependencies
---+I-SB-1-B Identify application dependencies
---+I-SB-2-B Review application dependencies for security
---+I-SB-3-B Test application dependencies

I-SB-B Stream B: Software Dependencies

External libraries are a significant part of modern software. The activities in this stream help create a view of external libraries and ensure their security strength is adequate.

1. Pregled

I-SB-1-B Identify application dependencies

Maturity level 1 objective of the practice: Build process is repeatable and consistent.

Benefit: Available information on known security issues in dependencies

Short description: Create records with Bill of Materials of your applications and opportunistically analyze these.

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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Security Engineer
  • Developer
I-SB-2-B Review application dependencies for security

Maturity level 2 objective of the practice: Build process is optimized and fully integrated into the workflow.

Benefit: Full transparency of known security issues in dependencies

Short description: Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications.

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 promptly 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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Architect
  • Developer
  • Security Engineer
I-SB-3-B Test application dependencies

Maturity level 3 objective of the practice: Build process helps prevent known defects from entering the production environment.

Benefit: Handling of security issues in dependencies comparable to those in your own code

Short description: Analyze used dependencies for security issues in a comparable way to your own code.

Maintain a whitelist of approved dependencies and versions, and ensure that the build process fails upon the presence of a dependency not 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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Security Engineer
  • Architect
  • Developer

1.1 Sklici

1.2 Ugotovljene zahteve

1.3 Povezani predpisi

2. Ugotovljene zahteve

Zahteve

3. Povezani predpisi

Predpisi
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.