Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track and handle changes in which versions are affected by a given vulnerability #1815

Closed
nscuro opened this issue Jul 24, 2022 · 3 comments · Fixed by #2098
Closed

Track and handle changes in which versions are affected by a given vulnerability #1815

nscuro opened this issue Jul 24, 2022 · 3 comments · Fixed by #2098
Labels
enhancement New feature or request p2 Non-critical bugs, and features that help organizations to identify and reduce risk
Milestone

Comments

@nscuro
Copy link
Member

nscuro commented Jul 24, 2022

Current Behavior:

When mirroring vulnerability databases, we map them to the following internal models:

  • Vulnerability: The vulnerability itself, including ID, source, references, severity, CVSS, etc.
  • VulnerableSoftware: Describes which components and component versions are affected by a given vulnerability

As it is now, VulnerableSoftware are treated as "append-only" (edit: by the OSV mirroring task, but not by NVD or GHSA tasks), meaning entries are never removed, even though the relationship they describe may not be reported by any source anymore (e.g. when the related advisory was corrected).

Proposed Behavior:

Track what sources reported a given VulnerableSoftware, and track when it isn't reported anymore. Consider a VulnerableSoftware entry to be outdated / removed once no source reports it anymore.

Additionally, expose this "reported by" information to the API and UI, similar to the existing FindingAttribution. Remember to consider that VulnerableSoftware can stem from manual creation as well since we introduced support for internal vulnerabilities.

@nscuro nscuro added enhancement New feature or request p2 Non-critical bugs, and features that help organizations to identify and reduce risk labels Jul 24, 2022
@sahibamittal
Copy link
Contributor

Scenario A:
on date 1: vulnerable ranges are [0,1], [2,3]
on date 2: vulnerable ranges are [2,3] ---> then [0,1] should be 'no longer reported as of date 2' ?

Points of discussion:

How to track data which is no longer reported by a datasource? Compare the latest incoming with last fetched data in DB?
Cleanup during scheduled analysis? or set up separate scheduled cleanup?

@nscuro
Copy link
Member Author

nscuro commented Nov 3, 2022

Update: As of now, it's only OSV that does not "cleanup after itself". It just appends new VulnerableSoftware entries to whatever is there already. Both the NVD and GHSA mirroring only persist the affected version ranges that are reported during their current task execution, everything else will be dropped implicitly. They do not keep historic data, and even override what's reported by OSV right now.

if (existing != null) {
vsList.addAll(existing.getVulnerableSoftware());
}
synchronizedVulnerability.setVulnerableSoftware(new ArrayList<> (vsList));
qm.persist(synchronizedVulnerability);

@nscuro nscuro linked a pull request Nov 4, 2022 that will close this issue
@nscuro nscuro added this to the 4.7 milestone Dec 13, 2022
@github-actions
Copy link
Contributor

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request p2 Non-critical bugs, and features that help organizations to identify and reduce risk
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants