[Feature Request] Better transitive security disclosure and alerting

[msavy]

Background

I co-create and maintain a fairly large open source project (Apiman). It's an API Management platform, and one of its niches is integration and extensibility/pluggability. One of the consequences of this is frequently running into transitive security vulnerabilities from the various libraries that we depend upon.

As the GH Security team will undoubtedly know, a wide range of alerts are issued by Dependabot to inform maintainers about CVEs affecting transitive dependencies. Maintainers can then triage and assess these by dismissing, patching, etc.

The following are (broadly) areas are not currently well-covered, in my view. I'd like to kick off a conversation and/or provide some inspiration for folk to run with!

Better informing users about relevant transitive CVEs

As with many open source projects, we don't track our users and don't have their contact details.

One of the key ways that software manifests vulnerabilities is via transitive dependencies. At present, CVEs from the official process are generally only issued for direct vulnerabilities in the product, not in transitives.

As the GH Sec team undoubtedly know, the actual risk posed to the end-user is not necessarily any lower with a transitive dependency; it is a "it depends/it's complicated" situation.

My experience is that monitoring CVEs tend to be the main way that companies watch for issues in their deployments.

Hence, a key issue is there is currently no good way for an open source product maintainer to communicate with users about transitive CVEs which may be equally as important, but fly under the radar because no CVE is ever issued.

As far as I'm aware, you could theoretically ask the CVE folk to add a reference manually (at their discretion), but I don't think there's any official "we're affected by this vulnerability, you really need to upgrade" mechanism.

A few ideas come to mind:

Improving automation

In the Dependabot tab/overview, allow maintainers to issue a security advisory using the existing data Dependabot has gathered. This would be much less labour intensive than today. The maintainer can then augment this with their domain-specific knowledge about their project (e.g. downgrade severity, add context, etc) before publishing.

I suspect this could produce useful metadata that could be consumed by existing downstream third party tooling to issue alerts to users.

For example, the fact a maintainer has confirmed they are affected by transitive dependency vulnerability X and have assigned their own score of Y is likely very valuable information — as would be a confirmation that a vulnerability is irrelevant.

Increasing reach (convenient ways of informing users)

I think we need to provide maintainers with a better way of notifying users about this class of security issues. I know GitHub has the existing security notifications category, but a lot of users never actually reach GitHub repository UI, they just are on a GitHub Pages project website or similar.

For example:

Could GitHub:

1. Offer an email subscription service that maintainers can put on the project website to lets users subscribe to security advisory notifications without having to visit the GitHub repository (perhaps also allow some simple filtering?).

2. Offer a web API maintainers could (optionally) call from the product itself to alert users — for example in an app's administration console — of the security issues affecting that version.

3. Show vulnerabilities associated with a particular GitHub Release in the UI, so that users are aware when they download it (at the moment it's mostly associated via package managers like Maven). Perhaps this could also be an option in the "affected products" section of the advisories tool.

Basically, some way say to users "you need to upgrade". At the moment way too many users are unknowingly sitting on ancient.

---

So, those are my thoughts that have been floating around in my head for the last few weeks and I thought it worth writing.

/cc @ronwoch

[msavy]

See also #1388 (comment)

[msavy]

Just an additional thought.

NIST has a "Known Affected Software Configurations" programme, but it seems to be email-based and some kind of manual process — https://nvd.nist.gov/vuln/vulnerability-detail-pages. It seems to be via email judging by the last point on the page?

Not sure how scalable that solution is, tbh — but perhaps this is another point of integration/automation that could be possible?

[KateCatlin]

Hey thanks @msavy for all the feedback here. Posting a response for posterity, though hope to connect via Zoom call from our other thread.

Clarification

Am I correct in my understanding that your user story is:

As a project maintainer, I want to tell my users that one of my direct dependencies (their transitive dependencies) is vulnerable more directly so that they understand it's not actually my package that is vulnerable.

Is that right?

Further context, if interested

We are currently engaged in work to (1) have reliable transitive dependency paths in the dependency graph, and (2) show these paths on Dependabot alerts so people know what to upgrade.

So the way this works today (which it sounds like you actually already know but just to over-communicate): When someone uses your project that has a vulnerability on a transitive dependency, and those users are using lockfiles that explicitly list the transitive dependency (or are running something to get them at build time), then those users should get a Dependabot alert for the vulnerability on the transitive dependency. Right now it's simply not marked as transitive.

After our upcoming work on transitive dependencies is shipped, the Dependabot alert will call out that it’s a transitive dependency and will show the path between the transitive dependency and the direct dependency.

[msavy]

Mine is similar but not identical. I'm going to use my project name to make life simpler.

Binary/containers use-case

As the Apiman project maintainer who ships executables[1], I want to tell my users that one of Apiman's dependencies[2] has reported a CVE which can be exploited in Apiman, so that they are alerted to the Apiman-specific implications and take action[3].

[Noting the situation mentioned in my original post that we don't have good tools to communicate with 'drive-by' users , as we just have a GitHub Pages website; it would be good to figure out a way to communicate with that class of user.]

Dependencies use-case

As the maintainer of a project that can be embedded/used as a library[4], I want to tell my users that one of Apiman's dependencies[2] has reported a CVE which can be exploited in Apiman, so that they understand what the implications are and take action[3].

Distinction with automatic CVE reporting

For the second use-case, it's relatively easy to get automatic reports from scanning tools of — for example — Maven pom analysis. However, any known dependency exploit/risk needs to be contextualised/quantified in the project to understand the risk and any project-specific mitigations.

As a concrete example, see: GHSA-q95j-488q-5q3p

In Jackson databind (library is ultimately dependency of Apiman) a vulnerability with a specific type of deserialisation class and data structure can cause a stack overflow, which is a severe vuln. In Apiman, the vulnerable usage pattern is only present in a select few locations; you'd have to be logged in with the correct permissions; and it's a component that some users keep for trusted users only.

---

I'm wondering if it may be better to retitle the thread as "[Feature Request] Better project dependency graph security disclosure and alerting", rather than transitive, as that might imply I mean only "dependency of dependency" rather than "all direct and indirect dependencies".

---

Hope that's helpful. I look forward to discussing more soon.

[1] Zips with compiled Java executables, containers such as Docker, etc. — see: https://www.apiman.io/download.html
[2] Direct dependency or transitive dependency.
[3] Upgrade to latest version, speak to support, apply mitigations, etc.
[4] In various different contexts such as embedding, implementing plugins which use our BOM, etc.

[KateCatlin]

Awesome thank you for all the context @msavy. Looking forward to our call about this.

Leaving this issue open on the repo in case others want to comment.