Include #security issues from non-covered projects in audit endpoint

We’ll actually have to re-evaluate how the project page will change as issues move to GitLab. Most likely, issues with the tag will be pulled in with front-end JS, so we don’t have to keep a copy of those issues. Maybe could do a link field to list URLs of issues tagged “security”, but anything synced will have times when it gets out of sync in the long run.

For the version constraints on any use tagged “security”, there isn’t structured data in issues, so it would just be *. So as soon as someone files a potential security issue, that would go straight to composer audit as if it were a real, reviewed vulnerability. To me, that seems like it will be a lot of noise for site owners. While they should be prepared to triage these security issues themselves, I’m not sure composer audit is the place to do it.

Is there any precedent for this sort of use of Composer’s APIs?

but anything synced will have times when it gets out of sync in the long run

A daily/weekly job that updates the composer advisories is likely still better than what we have now, delays are not ideal, but are better than not publishing the data.

Composer 2.6 has the ability to ignore specific audit entries so a false positive is a minor concern as it can be ignored.

Is there any precedent for this sort of use of Composer’s APIs?

The Friends of PHP list is a similar analog, where any vulnerability with or without a CVE, may be reported and is included in the feed, even if the maintainer has not acknowledged the issue a public report is sufficient. To my knowledge the Friends Of PHP list does not vet the vulnerabilities they just include them on the list(which Packagist uses as part of its audit endpoint), if a false-positive to them it is removed, and D.O. can do similar by any user removing the tag.

Using a #security tagged issue is similar to a GHSA in that the vulnerability is not vetted by a CNA, and only differs in that it is not maintainer created.

Under CNA rules EVERY project is covered, a CNA (such as the D.A.) should not consider voluntary opt-in by the maintainer, or project stability before publishing an advisory.

With the current D.O. Security Policy both are taken into account and the official policy is that a Security vulnerabilities should be Publicly Disclosed by reporters as soon as they are discovered.

Addtionaly the Audit endpoints in composer are also being expected to carry more data each day, https://packagist.org/packages/mxr576/ddqg-composer-audit as an example of a community project that uses the D.O. API's to report on modules that are 'no longer supported' as security concerns.

Website owners are currently expected (for non-covered) modules to monitor the Issue queue constantly, this is more resource intenstive (for site owners) as it requires either developing custom tooling to monitor the issue queues, or to manually review the issue queues, adding the data into the composer endpoint allows site owners to take advantage of existing tooling reducing total TCO of a Drupal deployment.

D.O. already has a risk of false-positive reports in the issue queue so adding it to the composer endpoint would not increase that risk.

I also suspect that (composer) pulling the package _name.json (which is cached and does not require dynamic generation) is also less resource intensive when compared to querying the D.O. (or eventually Gitlab) REST-API at the same frequency.

there isn’t structured data in issues, so it would just be *

This is the biggest issue I was thinking of related to this, and indeed * seems to be the best choice for 'wide distribution' the alternative could be based off the the issue is filed against if we wanted to try and make the range smaller. Though seeing as reporters may not see the entire scope of the issue, marking it for wider distribution would probably be the better choice.

There have been discussions in the past when Composer first announced its audit feature that this feature could be provided by 3rd parties not affiliated with the D.O. (and work has been done with the Composer dev team to make it easier to do so) however in my opinion it would be better for the community if this service was provided by D.O.

I'm not sure how to feel about this proposal.

Currently composer audit sounds an alarm for modules opted in to the security advisory process and have a patch posted.

This would make composer audit sound an alarm for modules NOT opted in to security advisory process and without a patch.

What new incentives would that create? Do those incentives align with the goals of the Drupal project?

Currently composer audit sounds an alarm for modules opted in to the security advisory process and have a patch posted.

We also include vulnerabilities without a fix when publishing unsupported modules SA’s
A random example https://packages.drupal.org/files/packages/8/p2/drupal/expire_reset_pass...

"security-advisories":[{"advisoryId":"SA-CONTRIB-2022-009","packageName":"drupal\/expire_reset_pass_link","title":"Expire reset password link - Critical - Unsupported - SA-CONTRIB-2022-009","link":"https:\/\/www.drupal.org\/sa-contrib-2022-009","cve":null,"affectedVersions":"*","reportedAt":"2022-01-25 18:36:37","composerRepository":"http:\/\/packages.drupal.org\/8\/","sources":[{"name":"Expire reset password link - Critical - Unsupported - SA-CONTRIB-2022-009","remoteId":"SA-CONTRIB-2022-009"}]}]

I will note that this alert does not create any additional vulnerability for site owners, as the information is already publicly published and searchable by attackers.

What new incentives would that create?

I would suggest that incentives should not be the biggest goal of this change, rather it’s the impact on protecting the community. D.O. doesn't need to directly benefit from this change, the site owners need to benefit.

This change would make it easier for site owners to know that there are nown vulnerabilities that they need to investigate and reduce the need for community built custom tooling. Will there be false-positives, likely yes, but overall as a community we can self clear those by removing the tag just as we do any other metadata issue.

As for incentives I could argue this could:

• Increase community activity in assisting to maintain modules, if an alert is displayed customers are more likely to push their vendors who profit off open source to resolve the issues.
• Possibly increase the number of modules enrolled in the Drupal Security Policy opt-in, reducing the number of public first disclosures. This would result from either increased community activity in the module or community pressure for maintainers to opt-in.

We frequently see security covered modules receive support once an unsupported advisory is published, the same could work for these issues since they will be more prominently displayed via the composer audit tool.

When we look at it I would hope "making it easier for site owners to determine they may be running vulnerable code" a worthy cause.

Certainly helping modules to be well maintained and site owners to be informed is a worthy goal.

In #2 drumm asked

Is there any precedent for this sort of use of Composer’s APIs?

I wasn't sure, so I read some articles about composer audit like here and here and composer docs which points to the api docs which says "List security advisories" as the title. The examples note things like CVE identifier, which wouldn't happen for a contributed project that opts out of coverage.

I think Drupal's audit endpoint should behave the same as is expected in other usages of the audit command and should only include advisories.

IMO this could be "won't fix" or "works as designed".

Giving everyone the ability to make something that looks like a security advisory would be a serious security issue in itself. The issue could not just contain misleading or inaccurate information, it could be malicious and direct site owners to “fix” the issue doing something crafted to attack the site.

I think Drupal's audit endpoint should behave the same as is expected in other usages of the audit command and should only include advisories.

I will note that the D.O policy is that for modules not covered by the security opt in that the public post in the issue queue is the security advisory. The module does have an advisory it just hasn't been curated by the Drupal Security Team.

The issue could not just contain misleading or inaccurate information, it could be malicious and direct site owners to “fix” the issue doing something crafted to attack the site.

That is a valid point, and its hard to see a way around this other than we start expecting the DST be willing to curate SA's for all modules.