Problem/Motivation

Organizations increasingly use tools like SBOMS, `osv-scanner`, and Dependency Track to track application packages (composer, node, server, and so on). When the Drupal Security Team releases a core security update, those get a Common Vulnerabilities and Exposures (CVE) identifier and are added to CVE databases like NIST (e.g. https://nvd.nist.gov/vuln/detail/CVE-2023-5256) and are added to packagist. Those then appear appropriately in DependencyTrack to let us know we have to update Drupal core. The request is to also create appropriate tooling/data to support contributed projects.

Perhaps contributed project security advisories could be provided in an OpenSSF Vulnerability format in addition to current formats? If that is setup then those could be added to the OSV database and make it to DependencyTrack through that process.

A set of code and example CVES that reformat Drupal's advisories from API into OpenSSF exists in the ackama drupal-advisory-database github repo. However, there are some items that need to be determined to make this more operational:

  1. getting an appropriate ecosystem into the spec
  2. confirming how tools can reliably determine that ecosystem from the composer.lock
  3. getting an id prefix for advisories into the spec

Confirm appropriate governance on the Drupal side.
Migrate the code / concepts to that governance.

Comments

dmundra created an issue. See original summary.

drumm’s picture

drumm
he/him
Location NY, US
commented

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.

dmundra’s picture

dmundra
he/him
Primary language English
commented

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"
  }
}
rosk0’s picture

rosk0
he/him
Primary language Russian
Location Wellington
commented
Related issues: +#2966246: API: Provide version number in the security advisory content type

Linking previous attempts to improve Drupal support in Dependency Track:

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

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 #3491985: Create CVEs for contributed projects in 2024.

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.

dmundra’s picture

dmundra
he/him
Primary language English
commented

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.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Closed (outdated)

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

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Issue summary: View changes
Status: Closed (outdated) » Active

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

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

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

dmundra’s picture

dmundra
he/him
Primary language English
commented

@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

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Issue summary: View changes

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.

dmundra’s picture

dmundra
he/him
Primary language English
commented

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

g-rath’s picture

g-rath commented

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.

tenguiz’s picture

tenguiz commented

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.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

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?

tenguiz’s picture

tenguiz commented

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

g-rath’s picture

g-rath commented

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:

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.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

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.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Title: Provide contrib security advisories in OpenSSF Vulnerability format for dependency tracking » Provide all security advisories in OpenSSF Vulnerability format for dependency tracking

Adjusting title since I think the goal is to provide all advisories in OpenSSF Vulnerability format.

Here's where I think this stands:

There's growing agreement that we would like the Drupal Security Team to officially provide OSV files.

We hope this would be beneficial for the Drupal project to support OSV and to promote site owners using osv-scanner to scan their sites. osv-scanner will alert about vulnerabilities in all kinds of code, while most tools are either focused on one technology (e.g. composer's focus on PHP) or are paid (e.g. snyk) or are platform dependent (e.g. Github alerts).

Some key points about moving forward:

  1. The code and the published osv files will be in a place managed by the Security Team with help from Gareth and Gold.
  2. Gareth and Gold have built out the automation in Github. We will move the code and automation to a space managed by the Drupal Security Team before it is added to the OSV aggregator. I propose DrupalSecurityTeamOps as a spot for this that is segmented from our other uses of Github.
  3. We can optimize the process and code in the future (e.g. moving to CVSS, having drupal.org generate the osv file directly and then the github repo would just pull that down, maybe moving some automation to Drupal.org owned Gitlab). But this is a good solution for now.
  4. There is limited capacity among the Drupal Security Team to support this. Luckily, Gareth and Gold from Ackama are willing to help. Given that, we'll consider this a pilot for now, and we are interested in improving the sustainability of the effort by getting more support. Once it's set up, Gareth and Gold believe the ongoing effort will be limited.
g-rath’s picture

g-rath commented

thanks @greggles - we have now got the repository transferred to https://github.com/DrupalSecurityTeam/drupal-advisory-database and I have updated the OSV schema PR to reflect how we're going to proceed: https://github.com/ossf/osv-schema/pull/372

Once that is landed, the next steps would be:
1. re-prefix all advisories in the database to use the (soon to be) official DRUPAL prefix
2. land https://github.com/google/osv.dev/pull/3743 to have the advisories ingested into the osv.dev staging environment

Also just noting that our automatic update workflow is probably broken pending some token updates, but that'll hopefully be resolved before next Thursday, and in the meantime we can still do the updates manually / locally

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Great news, thanks @g-rath!

g-rath’s picture

g-rath commented

The OSV schema change has been landed, meaning the Drupal advisory database is now officially part of the schema.

I've switched the database over to use the official "DRUPAL-" prefix and marked the osv.dev PR adding the database to be ingested into the test environment as ready for review

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Quick status update:

- g-rath and longwave (Dave) have been working to get this migrated into the DrupalSecurityTeam github space. This is getting close to being done.
- g-rath has also been working to get the codebases that rely on us publishing this information to pull it from the new location (that might be done, even, I'm not keeping close track).

I'm going to update the contribution record to reflect that work.

dmundra’s picture

dmundra
he/him
Primary language English
commented

Posting https://www.drupal.org/blog/drupal-security-advisories-are-now-available.... Thank you everyone for working on this!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Fixed

Yeah, I was just thinking we could probably consider this properly fixed now.

Thanks to everyone for their work on this!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.