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, and correct
      • This also means unused (zombie) requirements are removed
      • This includes security issues in embedded/included and transitive dependencies
      • This also means reducing assumed (phantom) dependencies to none, by making them explicit
      • …
    • take into account any security issues
      • …

Share your security metadata

  1. Communicate your policies and details around security issues

Add security tests to your code

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

Practice symbol import discipline

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
    • 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 who are your contributors, co-maintainers and successors 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. Ensure you license is commonly used
    • Pick an OSI-approved Open Source license, and
    • add it both to your project repository and other metadata

Improving your code

Use a secure Random Number Generator

  1. Read the CPAN Author’s Guide to Random Data for Security, and
    • Check and fix your code for any of the bad practices mentioned there

Use safe cryptographic algorithms

[!NOTE] TODO

Use certificates correctly

[!NOTE] TODO

Use secure authentication

[!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
  6. OWASP Cheat Sheet Series

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)