Author

Robert Rothenberg

Writing software with Perl and developing websites since the mid-1990s. Currently based in England.

9 minute read

CNA Vulnerability to Fix and Disclosure Workflow

Status: ⚠️ DRAFT

1. Report

Security reports may come from various places (module authors, users, security researchers, other CNAs or even CPANSec).

All reports should become a ticket in the CPANSec CNA issue tracker, using the “Vulnerability Report” template.

Note that the Vulnerability Tracking Kanban is no longer being used, due to the high volume from the April Task Force.

Issues that were not initially reported on the cpan-security email list do not need to be forwarded to the list.

All discussion about the issue should be on the ticket.

Note that rare sensitive issues are handled outside the normal workflow by CNA group members in an encrypted manner. They are not discussed on the cpan-security mailing list or the ticket.

2. Triage

  1. Is the issue in scope of CPANSec or the Perl Security Team?

    CPAN modules (including those only available on BackPAN) and Perl or Perl ecosystem vulnerabilities are in scope.

    Vulnerabilities in libraries that are embedded in or used by Perl modules may be in scope, although issues should be forwarded upstream to library maintainers. The ticket should be labelled as “Upstream Vulnerability”.

    Issues that are not in scope should be forwarded to the appropriate library maintainer or CNA, and labelled as “OUT OF SCOPE”.

    CPANSec is the CNA for Perl itself, but does not necessarily handle triage for core perl vulnerabilities. This is done by the perl-security team, with assistance from the CPANSec CNA regading CVE assignment.

  2. Is this a security vulnerability?

    Security vulnerabilities are considered anything that allows users to execute unauthorised code, access unauthorised resources, or to have an adverse impact on accessibility, integrity or performance of a system.

    If not, label the ticket as “NOT A SECURITY ISSUE”. (Note that a bug should be forwarded to the module maintainers if they have not been notified.)

    If it is unclear, label the ticket as “TODO Does this merit a CVE?”

    If possible, assign the ticket to a member of the triage team who may be more familiar with the relevant framework.

    When there is disagreement among CPANSec members about whether an issue should be considered a vulnerability, then we consider it to be a vulnerability if at least two (2) members of the CNA believe it to be a vulnerability. (The rationale is partly to err on the assumption that it’s better to publish a minor vulnerability, but also out of expedience so that work on the issue is not delayed by disagreement.)

    When the vendor (the author or maintainer) believes it to be a vulnerabiltiy, then it is considered a vulnerability.

    However, the vendor does not need to agree that it is a vulnerability.

  3. What is the severity of this issue?

    Remote Code Execution (RCE), Privilege Escalation, and Authentication Bypass should be labelled as “HIGH PRIORITY”.

  4. What other projects are affected by this vulnerability? And what are the potential impacts?

    Discussion as comments on the ticket of the blast radius (affected downstream software and users)

    • Forks

    • Downstream projects

    • Other projects with similar vulnerabilities: these will require new tickets to be created.

  5. What mitigations or solutions are available?

    If this is an issue that was already fixed, the ticket should be labelled “RETROACTIVE”.

  6. Is this a dual-life module?

    Tickets should be labelled as “Dual Life”.

    • Modules that are released separately from Perl, whether they are in the cpan or dist directories, should get their own CVE, and Perl will get a separate CVE for containing vulnerable third-party code (CWE-1395: Dependency on Vulnerable Third-Party Component).

    • Modules in the dist directory that are not released separately, or for which no vulnerable version has been released separately, do not get their own CVE. The CVE will be assigned to Perl.

3. CNA

  1. Does this meet the preconditions of a CVE? https://www.cve.org/resourcessupport/allresources/cnarules

    • Is this a duplicate? Check the CPANSec cna-cve, and cvelistV5 repos.

  2. Reservation of CVE

    • Check the GitHub and RT issues for the module, in case this issue has been reported before. The year of an older report should be used instead of the current year. Links to these reports will be added as issue-tracking references to the CVE metadata.

      If an older public reference to the vulnerability is identified after a CVE number has been assigned, the CVE number does not change. The timeline should be updated to show the correct history.

    • Commit the confirmation text for the reserved CVE to the cna-cve repo, e.g. reserved/CVE-1900-1234 straight to main.

    • Copy the confirmation text as a comment in the github issue.

    • Add the “TODO Contact Maintainers” label to the ticket.

  3. Additional triage

    Links to relevant references should be gathered:

    • Discussion of the issue on other ticketing systems
    • Links to source code repositories and patches
    • Links to relevant RFCs and other documentation
    • Links to upstream vulnerabilities (e.g. from embedded/vendored-in libraries containing flaws)

    Does the reporter want to be credited? Note that in some cases the reporter may not wish to be identified in the CVE or to the maintainer.

  4. Contact the maintainer(s) of the module by email, copying the cpan-security mailing list.

    Ideally this should be done within seven (7) days of the initial report.

    In the message, the subject should include the CVE and the module/distribution name but not details of the actual vulnerability.

    The message body should include details of the issue and impacts. Suggestions on how to fix the issue or a proposed patch are also helpful.

    CPANSec is a resource to assist authors with security issues. Offer help from CPANSec with solving the issue or releasing a fix.

    Provide the disclosure date, but allow the maintainers to provide a reason to extend it.

    • The date should default to a fourteen (14) days “grace period” from the date an email was sent to the maintainer(s),

      We will publish the vulnerability no sooner than $DATE, unless you disclose this beforehand (by releasing a fix, publishing a commit in the software repo, or posting the issue in a public forum). If you believe there are good reasons to delay disclosure beyond this date, then contact us.

    Remove the “TODO Contact Maintainers” label from the ticket.

  • For abandoned modules where there is no known way to contact the maintainer, there is no grace period. Vulnerabilities can be published immediately, as long as they are published with a patch. A module is considered abandoned if, for the past five (5) years:

    • The module has not been updated;
    • The maintainers have not uploaded anything to CPAN;
    • The maintainers have no activity on Github or other software repositories;
    • The maintainers have not participated in any forums, social media or mailing lists;
    • Emails to the maintainers bounce, and alternative email addresses cannot be found;

    For modules that appear abandoned but emails receive no replies rather than bouncing, assume that the maintainer is unresponsive. The fourteen (14) day grace period is in effect, but the vulnerability must be published with a patch.

  • If the vulnerability is already public, because of an issue in the issue tracker, a blog or social media post, or a public commit in the software repository, then there is no hold, and it must be disclosed immediately.

  • If no fix is released by the end of the grace period, then before publishing the CVE, create an issue in the module’s bug tracker, and a pull request with a patch. This counts as public disclosure, and acts as an alternative notification for the maintainers and users. The CVE should include a link to the issue and pull request in the references, but can be published later.

In cases where multiple projects have the same vulnerability, a coordinated disclosure where all authors release fixes on the same day may be appropriate.

Consider whether to disclose to other affected parties, e.g. Linux distros, CPAN / MetaCPAN / PAUSE, Perl Security Team, downstream projects.

Pre-release disclosure to distributions should be to the distros mailing list.

A maintainer does not have to agree to a CVE assignment for the issue to be valid, as long as there is reasonable evidence that the vulnerability is legitimate.

In cases where the maintainer cannot be reached using contact information in the module, or on their PAUSE profile or linked websites/software repositories, we should not go through heroic measures to contact them unless this vulnerability is severe or has a large blast radius.

Re-add the “TODO Contact Maintainers” label to the ticket if there are no known ways to contact the maintainer.

In cases where the module appears abandoned, or the author is unwilling to maintain it, patches should be published unless we find someone who can adopt it and release a fix.

TODO A CPAN-like repository with patched modules or uploading unofficial patched versions of modules to CPAN under the CPANSEC ID may be an alternative.

  1. Creation of CVE YAML/JSON, announcement text and possible patch in PR for the CNA repository

    Use the cna-tool for creating the necessary files.

    When the files are ready, create a PR.

    TODO PR and CVE style guide

    Links to distributions in MetaCPAN should always include the specific version, e.g. https://metacpan.org/release/AUTHOR/Foo-Var-1.23/changes

    In general, a timeline is only necessary for older disclosed vulnerabilities, or vulnerabilities that have been actively exploted.

    The finder should only be publicly credited if they consent.

    Generally we do not credit individual CPANSec members as finders.

    If possible, use an LLM to review the CVE PR. This does not replace human review, but it can assist with fact-checking and identifying typos.

  2. If no disclosure with a fix has been coordinated, then we should consider developing patches to publish along with the CVE.

4. Publication

  1. Label the ticket as “Ready to Publish”

  2. Copy patch (if any) to security.metacpan.org and update CVE with link to patch, when disclosure is imminent.

    Share that link with any third parties that we have disclosed the vulnerability to.

  3. Merge CVE PR (main is supposed to reflect the public state)

  4. Publish CVE to MITRE and add details to the PR.

  5. Post announcement to cve-announce.

    • Optionally, copy or post separately to oss-security@lists.openwall.com. If there are multiple CVEs for a module, then it may make sense to write a short summary of all of them in one message rather than sending multiple messages to the list.

    • Forward the announcement to the module maintainers separately, with a note saying that “We are forwarding this to you because you are a maintainer of this module”.

      (Bcc’ing maintainers in the past has led some people to believe that they were subscribed to the notifications.)

    • Forward the announcement to the reporters with a similar note.

    • Annnouncements on CPANSec Discussion matrix channel, and CPANSec social media (Mastodon, Bsky).

5. Followup

  1. Followup with downstream projects that are not part of coordinated disclosure.

  2. Blog posts/articles about the issue on security.metacpan.org

    Add links from blogs.perl.org, www.perl.org, Reddit, Mastodon, other social media.

    This is optional, but recommended when the security issue is an example of a common pattern.

  3. Evaluation of the workflow for this issue.

6. Closed