CPAN Risk Assessment Guide

Document status: ⚠️ DRAFT

CPAN Dependency Risk Assessment

This guide is INFORMATIONAL and should be considered as a continuously developing document. Please ensure you check this document regularly for updates.

Corrections or improvements to this text can be filed in the security.metacpan.org issue tracker. Pull requests are also welcome.

Assessing risk in the CPAN ecosystem

Methodology and Reading materials

• CHAOSS Community metrics
• PAUSE Operating Model with commentary
• The Deming Principles on managing quality.
• The NIST Cybersecurity Framework 2.0, and related Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations guidelines.
• The EO 14028 Software Security in Supply Chains guide
• …

Assessment recommendations

These items apply to all dependencies that use CPAN as a publishing and/or distribution channel. This also applies to modules that are re-packaged for other native packaging ecosystems (e.g. Debian DPKG or AlmaLinux RPM), though some recommendations may be different for packages that are distributed there.

Security

1. Dependencies are up-to-date, and automated mechanisms to check for updates are in place and regularly checking
2. Tests include an automated vulnerability check (e.g. using CPAN::Audit or Test::CVE) that are executed regularly
3. Dependencies and related metadata are made available in a vendor-neutral SBOM format

Sustainability

1. Project completeness — Look for signs of documents and other artifacts that are commonly expected in open source projects. E.g.: README, LICENSE, Changes and CONTRIBUTING files; A public source code repository; A public bug tracker; A community communications channel.
2. Upstream placement in the River of CPAN — An indication of this can be found on MetaCPAN’s reverse dependency list (example).
3. Bus-factor — How many active developers with indexing permissions exist? You can find this out on MetaCPAN (example in left column).
4. Advocacy visibility — Is the project (or one of it’s reverse dependencies) actively mentioned in social media or common community channels?
5. Funding options — Does the project offer low-effort ways for users to donate to it? E.g. Ko-fi or Paypal donation links, or maybe even Github Sponsors, or Tidelift
6. Collaboration metrics — Forum activity; Issue triage and responsiveness; Merge requests.

Community responsiveness

1. Number of old unmerged pull-requests
2. Number of open and stale issues
3. Forum availability and searchability
4. Availability of support from other community members

Project infrastructure

1. Relevant, well-developed and functional test-suite
2. Active use of Software Composition Analysis tools
3. …

Coding practices

1. Correct and updated dependency list, that takes known vulnerabilities into account
   • Author
   • Build
   • Test
   • Runtime
2. Avoid compiled code from untrusted sources
3. Avoid code generation at build time, test time or runtime
   • Code generators can be exploited too
4. Avoid build and test plugins
   • Plugins may be enabled unintentionally, and thereby create difficult-to-detect attack vectors
5. Developer focus on code understandability
   • Obscure or difficult-to-understand code makes exploit detection more difficult, and therefore a better target for attackers
6. …

Mitigating risk in the CPAN ecosystem

See the CPAN Risk Mitigation Guide.

See Also

1. See https://neilb.org/adoption/ for a better list of candidates for adoption if you are open for taking responsibility beyond your direct dependency requirements.
2. How to adopt a CPAN distribution
3. The PAUSE Operating Model
4. Blog post: How will NIS2 affect the supply chain security approach?

Legislative background

NIS2

• Article 21(2)(d); (⚠️ unconfirmed)
• Article 22; (⚠️ unconfirmed)
  • Recitals (90), (91); (⚠️ unconfirmed)
• For internal risk assessments
  • Recital (85); (⚠️ unconfirmed)