feat: add support for extracting Drupal packages from composer.lock files

[G-Rath]

Drupal packages are those that have been sourced from the Drupal composer repositories (https://packages.drupal.org/8 and https://packages.drupal.org/7), though since Composer does not actually include that information in its lockfile we instead look for extra.drupal which should always be present - this also has the advantage of being compatible with proxies since they should preserve the extra data

[G-Rath]

It should be fine to start reviewing this, though I'll keep it as a draft until I've gotten the other OSV related PRs up

(this is related to ossf/osv-schema#372)

[drumm]

Composer actually is somewhat of a free-for-all for security advisories. For example, Drupal core is provided by Packagist.org: https://packagist.org/packages/drupal/core along with other projects which we do not need our custom Composer repository: https://packagist.org/packages/drupal/cms

However, we do include advisories for these at Packages.Drupal.org: https://packages.drupal.org/8/security-advisories?packages[]=drupal/core and that is the best source for Drupal security advisories.

https://packages.drupal.org/8/packages.json has available-package-patterns containing drupal/* signaling that our composer repository should be searched for packages in the drupal/ namespace. Composer will get the package from the first repository that has the package, falling to Packagist.org as the default. https://getcomposer.org/doc/articles/repository-priorities.md has some documentation.

Composer will show security advisories from any repository for any package. That allows https://packages.drupal.org/8/security-advisories?packages[]=drupal/core to be used by composer audit despite not being same composer repository that the package is actually provided by.

For this, maybe it's best to say the drupal/ should use packages.drupal.org advisories. I believe extra is not present for https://packagist.org/packages/drupal/core. And while there are no changes for extra on the horizon, API changes can happen there.

[G-Rath]

For this, maybe it's best to say the drupal/ should use packages.drupal.org advisories. I believe extra is not present for https://packagist.org/packages/drupal/core. And while there are no changes for extra on the horizon, API changes can happen there.

That wouldn't be correct since (as far as I can tell) not all drupal/* packages are on the Drupal repository, including drupal/core and drupal/core-recommended, and that's why those packages lack extra.

By extension, advisories for those packages will have affected entries for the Packagist ecosystem in addition to ones for the Drupal ecosystem included for completeness.

[drumm]

That wouldn't be correct since (as far as I can tell) not all drupal/* packages are on the Drupal repository, including drupal/core and drupal/core-recommended

That's true, but the authoritative source for security advisories for all Packagist.org projects in the drupal/* is [https://packages.drupal.org/8/security-advisories](https://packages.drupal.org/8/security-advisories

Packagist.org’s advisories for the drupal/* namespace will be duplicates of Drupal.org's advisories, and published less-promptly, but do still apply.

The drupal/* namespace on Packagist.org is controlled by the Drupal project, so no new packages will be sent directly there from GitHub or elsewhere outside of projects on Drupal.org.

[G-Rath]

This is no longer needed as we're not going to use a dedicated ecosystem for Drupal