Provide contrib security advisories in OpenSSF Vulnerability format for dependency tracking

A good place to start would be generating a couple samples of this data to show how data on Drupal.org maps to this format.

Thank you @drumm.

Below is an example where I tried to convert the latest security advisory https://www.drupal.org/sa-contrib-2023-055 → to the OSV format. I made some assumptions like the summary, description, affected values, references, and database specific. For severity and package I think there would need to be a PR submitted to add Drupal specific security risk and package manager to OSV schema (see https://ossf.github.io/osv-schema/#severity-field).

Another example is an analyst took the https://www.drupal.org/sa-core-2023-006 → entered in NIST and added it to the GitHub security advisory database here https://github.com/github/advisory-database/blob/main/advisories/github-.... That uses the same OSV format.

{
  "schema_version": "1.4.0",
  "id": "DRUPAL-SA-CONTRIB-2023-055",
  "modified": "2023-12-20T17:53:15Z",
  "published": "2023-12-20T17:02:51Z",
  "summary": "Cross Site Scripting in drupal/dvf",
  "details": "This module allows you to turn various data sources (Eg CSV or JSON file) into interactive visualisation. The DVF module provides a field (storage, widget & formatter) that can be added to any entity.\nThis module uses two third-party JS libraries having from low to medium vulnerabilities. One of the vulnerabilities is a Cross Site Scripting vulnerability that may affect Drupal sites as a Persistent Cross Site Scripting vulnerability (i.e. not reflected). This release updates the libraries.\nThe issue is mitigated by the fact an attacker needs the permission to create or edit content that is displayed using the Data Visualization Framework.\nSolution:\nInstall the latest version:\nIf you use the Data Visualisation Framework for Drupal module (DVF for short), upgrade to dvf 2.0.2",

  "severity": [

  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Drupal",
        "name": "drupal/dvf",
        "purl": "https://packages.drupal.org/8"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.2"
            }
          ]
        }
      ]
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.drupal.org/sa-contrib-2023-055"
    },
    {
      "type": "PACKAGE",
      "url": "https://www.drupal.org/project/dvf"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/project/dvf/releases/2.0.2"
    }
  ],
  "database_specific": {
    "sa_id": [
      "SA-CONTRIB-2023-055"
    ],
    "severity": "MODERATE"
  }
}

Linking previous attempts to improve Drupal support in Dependency Track:

• https://github.com/OSSIndex/vulns/issues/149
• #2966246: API: Provide version number in the security advisory content type →

I think we could consider providing OpenSSF format in addition to CVE. However, the CVE process has gotten a bit easier since the slack thread linked in 2022.

There are now CVEs for all of core issues for 2024.
I'm working through contrib for 2024 in 📌 Create CVEs for contributed projects in 2024 Active .

I'd love help on those to the extent folks can do it. Ping on slack or those issues if you're interested in helping.

Thank you @greggles for making CVE for contrib issues. I am already seeing those appear in NIST as well https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=ov... so I think we don't think we need to do this additional process.

OK. Thanks for that update. I'll close this, then.

@dmundra is Dependency Track picking up contribs and core CVEs? I believe that osvscanner isn't. So it seems we need to reopen this issue.

I added some changes to the issue summary based on a recent slack thread.

@greggles Dependency Track is showing both CVE now for both core and contrib but looks like the missing detail is which packages are affected. @grugnog pointed out these examples from the NIST database:

* https://nvd.nist.gov/vuln/detail/CVE-2020-13673 shows packages
* https://nvd.nist.gov/vuln/detail/CVE-2025-6676 currently does not show packages

For purposes of this discussion I suggest we focus on 2024 and newer CVEs. If folks want to fix up old CVEs we can certainly do that, but it would be solved in different ways. CVEs created for years prior to 2024 were created completely manually. Those for 2024 and later used a script and manual submission.

That's great news about Dependency Track! The expanded issue summary talks about the subject more generically, so I think we're good.

Sounds good and ya I agree about just newer CVEs. We were just referencing an example about packages.