Document status: ⚠️ DRAFT

[!CAUTION] What you see here is a DRAFT of the CPAN Author's Guide to Secure Software Development by the CPAN Security Group (CPANSec). As long as this document is in DRAFT, all of the points and ideas below are open to revision, deletion or amending – by you!

The need for Secure Software Development on CPAN

As of December 2024, we have new guidelines and legislation introduced in the EU (NIS2 and the Cyber Resilience Act), with US equivalents (EO 14028), introducing new requirements regarding software security. These requirements are directed at many businesses and institutions to raise the baseline level of security in the software they produce and in sectors they operate. A substantial part of these depend on software published on CPAN. This means there is now a greater need for CPAN distributions to take their security posture into account.

To help in this shift, CPANSec has put together several guides intended to assist any developers publishing on CPAN to improve their distributions and code.

Secure by Design and Secure by Default

  1. EU Cyber Resilience Act, Annex I, Part I
    • A good illustration of what is expected from CPAN users
  2. CISA’s Secure by Design Pledge

Improving your distribution

Keep your security metadata up-to-date

  1. Read the CPAN::META::Spec and make sure all relevant fields are correct and up-to-date
  2. Ensure also that your list of requirements (dependencies) is complete, up-to-date, correct and takes into account any security issues
    • This also means unused (zombie) requirements are removed
    • This includes embedded/included and transitive dependencies
    • This also means reducing assumed (phantom) dependencies to none, by making them explicit

Share your security metadata

  1. Add a security.txt file to your project website
  2. Add a distribution security policy to your distribution
    1. Add the same to your project repository (Github instructions)

Add security tests to your code

  1. Learn how to use perltaint to detect and defang input from untrusted sources
  2. Add tests for taintedness to your codebase, to verify that your code actually handles untrusted input as expected
  3. Check out CPANSec’s guide to vulnerability testing

Practice symbol import discipline

  1. Use App::perlimports to get a better idea of what symbols you are using

Reduce the amount transitive dependencies

  1. The more modules you depend on, the larger the attack surface you may have to defend
    • If necessary, help your upstream maintainers to trim down their dependency graph

Ensure your project is sustainable

  1. Have at least one other trusted co-maintainer
    • You can add a co-maintainer in PAUSE
  2. Have a succession plan
    • Describe who among your co-maintainers will take over your project if you become permanently unavailable
  3. Communicate these clearly through common channels
    • Keep an up-to-date list of co-maintainers and contributors in your repository, e.g. in an ‘Acknowledgements’ or ‘Contributors’ section in the documentation
    • Add a CONTRIBUTING.md file, to make it easier for both new and old contributors to help

Select an appropriate Open Source license

  1. Pick an OSI-approved Open Source license, and add it both to your project repo and other metadata

Improving your code

Use a secure Random Number Generator

  1. Read the CPAN Author’s Guide to Random Data for Security

Use safe cryptographic algorithms

[!NOTE] TODO

Use certificates correctly

[!NOTE] TODO

Further reading

  1. Perl’s perlsec documentation
  2. OpenSSF Open Source Best Practices Badge program
  3. SEI CERT Secure Perl Coding Standard
  4. NIST Secure Software Development Framework
  5. CISA Product Security Bad Practices guide

License and use of this document

You may use, modify and share this file under the terms of the CC-BY-SA-4.0 license.

Acknowledgements

  • Salve J. Nilsen (main author)