[Feature Request] Allow official CVEs to be shown on Security Advisory page

[msavy]

As of today, only security advisories created explicitly/directly by a repo admin [1] are shown in the advisories tab. You do not get to include 'official' CVEs that have been ingested from the wider CVE ecosystem. This requires copy-paste duplication.

I would like to suggest the following:

• Allow inclusion of official CVEs by repo admins using existing data.

• Instead of requiring copy-paste, as today, provide a pathway to include/transclude the CVE into the advisories tab. For example, a drop-down with "Include in Security Advisories".

• It would be good to distinguish visually between official CVEs and GH security advisories. Not sure if a separate list is appropriate or just tags. Worth experimenting.

• Should the CVEs appear automatically on the page without repo admin intervention? Or should it require action/approval? Configurable? Likely requires a bit of thought about risk management.

More broadly, I think the Security Advisory page could act as a 'hub' for security-related topics that consumers should be aware of.

[1] Not sure what the correct role name is here, so s/repo admin/other/ to whatever is appropriate :-).

/cc @ronwoch

[msavy]

Some relevant content/comments here on thread with @ronwoch — #1388 (comment)

[KateCatlin]

Hi @msavy, thanks so much for reaching out with this idea. I'll go ahead and spin up an internal issue to address it.

Can you tell me more about where these "official" CVEs you want to include are coming from? Are you working with another CNA to create them? Or are these being reported/alerted on without your involvement as the maintainer?

[msavy]

Hi @KateCatlin,

Yes, when I say official CVE, I'm referring to CVEs that are coming from CNAs and hence issued their own unique CVE identifier rather than just a GitHub Security Advisory or some other mechanism.

(So far I've worked with the MITRE CNA, but if better options exist, then I'm open to that.)

All security issues so far in Apiman have been reported via me and/or the Apiman team so far, rather than directly with a CNA — I then took it to MITRE. That only works for first party vulnerabilities though, and I've used security advisories for important transitive vulnerability alerts that affect Apiman, but do not qualify to be issued their own unique CVE identifier.

Eventually, those filter through into GitHub, and it would be good to be able to have a low-friction way of displaying that in the advisories page (with maintainer curation).

Sorry if I was unclear.

[KateCatlin]

Hey @msavy, thanks for the quick response!

First of all, would love to jump on a call and talk through your use case here. Happy to send you a gift card as a thank-you for your time: https://calendly.com/security-advisories-ux-calls/30min?month=2023-01

I have great news though, which is that GitHub is also a CNA. 85% of the GHSAs published via GitHub repo apply for and receive an official CVE through our CNA program. So then they have both a GHSA identifier and a CVE identifier!

[msavy]

No problem, I can make time for that.

[ronwoch]

@KateCatlin to clarify a bit - @msavy originally authored a CC on a global advisory for Apiman that we ingested from NVD when they published the CVE, but that global advisory is not displayed on the security tab of the Apiman repository, which I think sparked the initial request, but it sounds like the idea may have grown!

[msavy]

Thanks @ronwoch — I was just trying to say what you are describing, but evidently much more verbosely. Probably because I'm not familiar with some of the domain-specific terminology.

The only addenda are really that, (1) perhaps a maintainer should to be able to control whether the global advisory/CVE from the NVD is displayed, (2) some kind of visual cue as to the advisory's origin/type.

[ronwoch]

No problem! The differences between the repository advisories created by maintainers and the global advisories that we curate on are subtle, and sometimes confusing. Improving our documentation is also an ongoing task. Glad you were able to connect with @KateCatlin and schedule some feedback!

[KateCatlin]

Thanks all. Going to leave this issue open for others to comment on if this is also relevant to them!

[ravage84]

Hello everybody

The CakePHP framework team recently published its first security advisory of a community reported security issue through the GitHub repo security advisory page because the initial reporter did not create a CVE for it.
There are a few security advisories of the past for the framework, too.

While these past security advisories in the GSHA database are linked correctly to the relevant Composer package [1] and even linked to the source repo, [2] they are not shown in the security advisory page of the repo.

For example, GHSA-9pgx-pf36-w46r:

It would be great to have these past securtiy advisories listed under the secutrity page of repo.
I made a quick mock up:

This would not account well for advisories reported through the repo which get a CVE and then are imported to the GSHA database, as it would show them twice.

[msavy]

Hey @msavy, thanks for the quick response!

First of all, would love to jump on a call and talk through your use case here. Happy to send you a gift card as a thank-you for your time: )

I have great news though, which is that GitHub is also a CNA. 85% of the GHSAs published via GitHub repo apply for and receive an official CVE through our CNA program. So then they have both a GHSA identifier and a CVE identifier!

Thanks @KateCatlin, it was a pleasure to meet you. I think it was a fruitful session. Happy to follow up again if you like, and will gladly accept the card offered 😅.