Author

Robert Rothenberg

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

7 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, and added to the Vulnerability Tracking Project.

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

When triage starts, the ticket should be moved into the “Triage” status.

  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?

    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.

  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”.

3. CNA

The ticket is moved to the “CNA CVE Draft” status.

  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 fourteen (14) days from email 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.

  • 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.

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 and move the ticket to “CVE Review and Hold” status.

    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.

  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.

    Move the ticket state to “CVE Published”.

    Note that the actual ticket may be closed in GitHub issues, but this is separate from the “Closed” state in the project.

  5. Post announcement to cve-announce, and to oss-security@lists.openwall.com in the same message.

    • Bcc the announcement to the module maintainer(s).

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

5. Followup

Move the ticket to “Followup” status.

  1. Submit patches to affected modules in PR if a fix has not yet been released.

    This is optional.

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

  3. 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.

  4. Evaluation of the workflow for this issue.

6. Closed

Move the ticket to the “Closed” status.