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.

As mentioned in the description, we (Ackama) have created an advisory database that provides Drupal SAs in OSV format, which is working well but we're currently co-opting two aspects of the spec to have the OSVs technically valid for tools to start using them, which will need to be resolved for the database to be ingested by osv.dev.

1. for the ecosystem (https://ossf.github.io/osv-schema/#affectedpackage-field) we're using Packagist, which is only meant for packages that are sourced from the packagist.org repository

To address this we propose adding a new ecosystem named Drupal (which would map to https://packages.drupal.org/8), and using an optional 7 suffix to indicate packages that belong to the https://packages.drupal.org/7 repository to allow Drupal 7 advisories i.e.

- { "name": "drupal/tfa", "ecosystem": "Drupal" } would map to https://packages.drupal.org/files/packages/8/p2/drupal/tfa.json
- { "name": "drupal/tfa", "ecosystem": "Drupal:7" } would map to https://packages.drupal.org/files/packages/7/p2/drupal/tfa.json

This is based on Drupal having dropped the convention of prefixing major versions per https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... → meaning there shouldn't be a new repository introduced in future

2. for the id (https://ossf.github.io/osv-schema/#id-modified-fields) we're using the DSA as the database prefix, which belongs to the Debian Security Advisory Database

The crux of this is that the current SA prefix used by Drupal is too generic - we might be able to get away with SA-CORE and SA-CONTRIB, but I think there's still a preference to having a less generic prefix before the first -.

We've put together a small list of suggestions, but very happy to take alternatives:

- DVA (Drupal Vulnerability Advisory)
- DAD (Drupal Advisory Database)
- DSEC (Drupal Security)
- DRUPAL

There is also the question of how much of the existing prefix we retain, as we could do e.g. DSEC-SA-CONTRIB-2000-00, DESC-CONTRIB-2000-00, or DESC-2000-00.

Note that this prefix is only required for the OSV versions of the advisory to help keep them unique within osv.dev, so the advisories as published on drupal.org would not have to change though in my opinion it is nice if they are aligned especially if Drupal start to publish their advisories in OSV format directly (this could be a good reason to retain the current prefix after the OSV specific one, as it would make the rule of thumb "just drop the DESC- to get the drupal.org ID").

These is also the question of how tools should decide if a package belongs to the Drupal ecosystem when reading a composer.lock since the repository URL is not tracked there, but this is more of an implementation detail and can evolve over time (+ with prototyping) - our current proposal is to use the extra.drupal.version property that gets included by the Drupal repositories since that should be present on existing lockfiles.

Ackama has a healthy relationship with Google, helping to build and maintain osv-scanner and its related projects, which we've been leveraging here; we're happy to handle the actual implementation work on the OSV side once we (the community) have agreed on a direction for the above.

I just want to point out this PR within DependencyTrack. https://github.com/DependencyTrack/dependency-track/pull/4515
They are working on obtaining security advisories directly from composer repositories, which is already planned for the next minor release 4.14.0.
In this context, the Drupal security advisories are namespaced within DRUPAL. This is done by checking if the prefix is either SA-CORE or SA-CONTRIB.

Thanks for this research, @g-rath and @tenguiz.

Abbreviations can be handy sometimes, but it feels like DRUPAL is a fine value to use for the id (that's what you meant, I think tnenguiz?).

And the proposal for the ecosystem to be Drupal or Drupal:7 feels very straightforward and short enough.

I don't see any drawbacks to these. Anyone else?

Exactly @greggles, I would choose DRUPAL as id because it corresponds to the KISS principle and is already used by DependencyTrack.

Since it sounds like folks are happy with the above, I've gone ahead with creating draft PRs to the relevant parts of the OSV ecosystem:

• https://github.com/ossf/osv-schema/pull/372 | adds the Drupal ecosystem and database prefix to the schema
• https://github.com/ossf/osv-schema/pull/378 | adds support for the Drupal ecosystem to the osv-linter
• https://github.com/ackama/drupal-advisory-database/pull/114 | updates the database to use the proposed Drupal ecosystem and database prefix
• https://github.com/google/osv.dev/pull/3723 | adds support to osv.dev for the Drupal ecosystem
• https://github.com/google/osv.dev/pull/3743 | adds the Drupal advisory database as an advisory source to osv.dev
• https://github.com/google/osv-scalibr/pull/950 | modifies the `composer.lock` extractor to support differentiating between "Packagist" and "Drupal" packages, based on the presence of `extra.drupal`
• https://github.com/google/osv-scanner/pull/2122 | adds support for the Drupal ecosystem to osv-scanner

I think that's the lot, but will update if I end up doing more - the pull requests are pretty much in order of highest to lower priority, with the scanner one at this point just being a hacky throw together for now (it should technically be correct but its very dependent on all the other PRs, and I think its also revealed a bug in our logic).

If folks could look over the first PR for the schema and leave comments, questions, and approvals if folks are happy that'd be appreciated, and then I'll mark the schema PR as "ready for review" - feel free to do so over the others, but they're less important for now and most involve implementation stuff in Go.

This is all amazing, thanks so much for your help!

I think the governance topic might best be resolved as a conversation where we can have high-bandwidth explanations/questions/answers. I'll reach out on that now.