Evaluate new dependencies against written criteria

Description

Before adoption, a new dependency is checked against written criteria, at least:

• the name is the intended package, not a look-alike;
• it links to a public source repository that matches the published content;
• it is maintained (recent activity, responsive maintainers, security contact);
• it has a usage and history consistent with its purpose (see CB-DEP-AGE-002);
• it has no install-time scripts, or they are justified;
• its license is compatible with the product;
• its transitive tree is reasonable for what it does;
• it is needed: the same result is not a few lines of code or already available in the standard library or an existing dependency.

Rationale

Most supply chain incidents involve packages that a short look would have flagged: a misspelled name, no source repository, a single anonymous maintainer, or an install hook in a utility library.

Impact

A few minutes per new dependency.

Audit

1. Check that the criteria are written and known to reviewers.
2. Sample recent additions and check the evaluation was recorded.

Remediation

1. Write the criteria, starting from the list above.
2. Add a short evaluation section to the change request template for manifest changes.

References

• Concise Guide for Evaluating Open Source Software OpenSSF, guide, accessed 2026-10-16
• OWASP Software Component Verification Standard OWASP, standard, accessed 2026-10-16

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

Related controls

• related CB-DEP-VET-001 Review every new direct dependency before merge
• related CB-DEP-AGE-002 Wait a minimum age before adopting a new package

People and lifecycle