Author

Robert Rothenberg

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

6 minute read

CNA Vulnerability to Fix and Disclosure Workflow

Status: ⚠️ DRAFT

1. Report

Once an issue with a project is reported to CPANSec, an initial ticket should be created in the CPANSec CNA issue tracker, using the “Vulnerability Report” template, and added in the “Reports” status of the Vulnerability Tracking Project.

The issue may initially be discussed and triaged on the cpan-security email list, copying the reporter and maintainers.

Issues that are initially reported in other forums (even closed CPANSec channels) should be forwarded to the cpan-security list.

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.

2. Triage

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

Triage and coordination will be in the cpan-security list, although there may be some discussion on the CPANSec TRIAGE matrix channel.

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

    Note that a vulnerability in a library that is used by CPAN modules or Perl tools may still be relevant.

    If not, should it be forwarded to another team? Otherwise the the ticket can be marked as “Closed”.

    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 yes, it will go to the CNA.

    Otherwise reject it as a security issue and mark it as “Closed”. (Note that a bug should be forwarded to the relevant team if they have not been notified.)

  3. What are the risks of this vulnerability?

    Discussion on the TRIAGE matrix channel, but important details should be added as comments to the github issue.

  4. What other projects are affected by this vulnerability?

    Discussion on the TRIAGE matrix channel, but important details should be added as comments to the github issue.

    • Forks

    • Downstream projects

    • Identify other projects with similar vulnerabilities.

      These may require new issues to be created.

  5. What mitigations or solutions are available?

    Discussion on the TRIAGE matrix channel, but important details should be added as comments to the github issue.

  6. Confirm with the reporter and contact the maintainers.

    This should be done within seven (7) days of the initial report to CPANSec.

3. CNA

Initially 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?

    • Is this in scope of CPANSec CNA?

  2. Reservation of CVE

    If the CNA decides this issue is in scope, reserve the CVE:

    • Check the GitHub and RT issues for the module, in case this issue has been reported before. The year of an existing report may 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 can 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.

  3. Additional triage

    Discussion on the TRIAGE matrix channel, but important details should be added as comments to the ticket.

    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)

  4. Coordinate with the reporter, and copy the maintainer(s) of the module by email if they are different.

    Include a description of how to fix the issue, or a proposed patch. CPANSec is a resource to assist authors with security issues. Offer help from CPANSec with solving the issue or releasing a fix.

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

    • The date should default to 14 days from email to the maintainer(s),

      We will publish the vulnerability no sooner than $DATE, unless you disclose this beforehand, or if you contact us before that date with reasons to delay this.

  • When contacting maintainers about multiple or complex issues, a deadline of 21 days is acceptable.

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

There may not be a specific date, but coordinated with a new release that fixes the issue.

There may be exceptions to deadlines when it has been determined that disclosure would have a major impact. These cases may require special coordination with maintainers and downstream distributions.

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.

-Feedback to the reporter and maintainters

- Does the reporter want to be credited?

- Are the maintainers aware of this issue? Do they agree that this is an issue?

  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, but if they do the decision to assign becomes easier.

- Notify the reporter and maintainer of the CVE.

  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.

    TODO discussion of the tools that we use.

  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. Copy patch (if any) to security.metacpan.org and update CVE with link to patch.

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

    Note: this should be done when the publication of the CVE is imminent, as this counts as disclosure.

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

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

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