Robert Rothenberg

At the 2026 Perl Toolchain Summit Salve Nilsen and I proposed some ideas that we have been discussing on and off for the past several months for CPANSec, for a CPAN Meta v3 Specification.

Why does the specification need to be extended?

Version 2 of the CPAN Meta Spec (CPAN distributio n metadata specification) is does not allow the addition of new data, except using fields prefixed by "x_".

However, there is a need to include additional metadata about:

• external dependencies (services, libraries, files, or environment variable)
• embedded external libraries, e.g. zlib or bootstrap.
• licensing
• vulnerability reporting
• parent-child relationships (e.g. forked project)
• fixed vulnerabilities in this fork or in embedded libraries
• code and documentation generated through automation or using LLMs
• how and where to report security vulnerabilities
• project funding and sponsorship
• how the project is supported by the maintainers
• enumeration of community health documents, e.g. SECURITY.md, GOVERNANCE.md and AI_POLICY.md

This is too much information to embed in existing META.json files, and some of this metadata exists in alternative formats, for example:

• SBOM (Software Bill of Materials) files
• Attestations
• VEX files
• Common Lifecycle Enumeration (CLE)
• Project Description (DOAP) file
• OSSF Security Insights File
• REUSE

Note that most of this data is not necessary for installing CPAN modules. It exists mainly for documentation and auditing:

• generating SBOMs for an application using its dependencies
• auditing software for security vulnerabilities
• auditing software for license compliance
• displaying the external documentation for a module such as the security policy

Specification

The specification is simple:

1. All new metadata will be saved in the CPAN-META directory at the root of the distribution and software repository.

2. All files and subdirectories saved in that directory will have well-known names.

   Currently there is automation-policy.json for the AI and Automation Policy metadaya, that I have worked with Nicolas Rochelemagne. This will be discussed in a separate blog post.

3. The metadata should never be added as "x_" keys to the META.yml or META.json files.

4. This metadata may be provided as a separate file from a distribution.

The proposed specification can be found at https://github.com/CPAN-Security/cpan-metadata-v3

To suggest addition or changes, please create an issue or pull request.

Tooling

There are not yet tools for handling the METAv3 specification.

The tools will need to minimise the workload for project maintainers.

Modules should be configurable, testable and installable without any tools that support this specification. However, metadata may be useful for tools that understand them, for example, to ensure external dependencies are met.

Thanks

Thanks to the organisers of the PTS for their hard work and hospitality, and to the sponsors who are keeping the Perl ecosystem growing:

• The Perl and Raku Foundation,
• Grant Street Group,
• Geizhals Preisvergleich,
• Vienna.pm,
• SUSE,
• Trans-Formed Media LLC, - Ctrl O,
• Simplelists,
• Harald Joerg,
• Michele Beltrame (Sigmafin),
• Laurent Boivin.