Collect CVE related details as part of Security Issue

Created on 9 October 2024, 2 months ago

Problem/Motivation

@greggles recently posted on Slack that the security team is looking for assistance in creating CVE's for publication.

I had made the following suggestion on slack in Feb of 2022 which is again relevant:

Instead of attempting to create a CVE from the public disclosure, I would suggest the data for this should be collected as part of the existing stages (issue creation and SA creation) this allows the security reporter and the maintainer to reduce the workload of the DST while also allowing them to provide input.

Steps to reproduce

N/A

Proposed resolution

Add fields necessary to create a CVE should be present in the Security Advisory. These need not be in the format that the CVE Program uses, just in a format that can be programmatically converted to the correct CVE values.

Remaining tasks

Add fields in appropriate locations to the S.D.O UI.

User interface changes

Additional fields present to be filled in by reporter/maintainer/security team prior to public disclosure.

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States cmlara

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cmlara
  • πŸ‡ΊπŸ‡ΈUnited States yesct
  • πŸ‡ΊπŸ‡ΈUnited States yesct
  • πŸ‡ΊπŸ‡ΈUnited States greggles Denver, Colorado, USA

    I think this is not a reasonable, practical, or helpful idea. Maintainers and reporters are generally overwhelmed with the information and process required in creating a security fix. We should seek to strip away parts of that process rather than adding more.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    The big question is what is our Time To Publish SLA going to be? Can we meet that SLA with accurate information without collecting this as part of the Draft SA process?

    Remembering that until we publish a CVE 3rd party tools are not going to be able to detect the vulnerabilities, the shorter the better.

    My personal goal: Within minutes after the Drupal SA is published the CVE record is also published to allow for 3rd party security tools to detect the vulnerabilities. This goal does not allow time for generating the data after Drupal SA publication. Is this goal reachable today, no, in the future, hopefully.

    Yes when we get a combination of an inexperienced dev, and an inexperienced security reporter the DST will have to help fill in the values, however the flip side of that is when we get experienced reporters or experienced developers (such as the Drupal Core Team and the security focused contrib developers) they will be able to fill in this information. This also goes to another point I've made previously, CWE are both about classifying the vulnerability, and training developers to not make the same mistakes twice, It is in the DST and D.O. ecosystem best interest to help maintainers understand the root behavior faults so they can avoid it being repeated in their projects, Working with them as part of the process may mean a reduction in future vulnerabilities.

    I went through https://www.cvedetails.com/vulnerability-search.php?f=1&publishdatestart... yesterday (at the time it was "new CVE's since yesterday" and had 110 entries, additional CVE's have been added since I started the list below)' yesterday, chose the first CVE I saw from each CNA and plotted them down the basics attempting to gather "When a CNA publishes an advisory how long after they publish is a a CVE published"

    The following timelines are 'high level', no timezone conversion or comparison done. CVE Publication times are UTC, CNA publication times are undefined and may be in UTC or CNA Local Time.

    CVE-2024-54679 - Mitre -No publication of advisory just a link to a commit 3 weeks prior.
    CVE-2024-54140 - GitHub - Same Day
    CVE-2024-54127 - Cert In - Same Day
    CVE-2024-54014 - JP/Cert - Next day
    CVE-2024-53703 - SonicWall - 2 days after publication
    CVE-2024-52271 - VulSec Labs - Same Day
    CVE-2024-51555 - Asea Brown Boveri Ltd. (ABB) - Same Day
    CVE-2024-42195 - HCL Software - Same Day
    CVE-2024-12247 - MatterMost - >30 days or Same day. Vendor/CNA publishes an internal ID number of a vulnerability with no details, 30 days later they post public details and apply for a CVE on same day.
    CVE-2024-11942 - Drupal.org - Skipped as we don't want to reference ourselves.
    CVE-2024-12130 - Rockwell Automation - Next day site lists two dates in publication, assuming worst case of the oldest date.
    CVE-2024-11779 - Wordfence - Next Day
    CVE-2024-11149 - CISA - No CNA publication, just links to previously announced (but no CVE) security fixes in Freebsd.
    CVE-2024-10716 - PegaSystems Inc - Same Day
    CVE-2024-6219 - Canonical - 3 Days
    CVE-2022-41137 - CVE-2022-41137 - Next day
    CVE-2018-9391 - Android - No CNA publication, appears to be a bulk load of vulnerabilities from 2018 and before, unknown why not published when already publicly available.

    Same Day encompass where the CNA publication date shows the same calendar day as the CVE.
    Next day encompass where the CNA publication day shows the day prior to CVE publication.
    Next day could be 'within hours'. Example Wordpress published on the 4th (no timezone specified) and the CVE was issued 09:23:07 UTC on the 5th, this could have been a 'same day' and within hours for the organization, or it could have been at the far end of ~33 hours.

    Most of these sites only list a day not an exact time on their publication limiting the precision level to 'days'.

    17 CNA's
    1 is Drupal.org
    3 did not publish their own advisory.
    6 (or 8 depending how you classify MatterMost and Rockwell Automation) published same day, often within hours.
    4 (Or 3 depending upon Rockwell's dates) published "next day"
    2 published in the 2-3 day range.
    1(or 0 depending on MatterMost classification) published at >30 days)

    Back to the root question: What will SLA on publication?

Production build 0.71.5 2024