Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

cross check with CISA known exploited vulnerabilities catalog #2558

Closed
telelvis opened this issue Jul 21, 2022 · 5 comments
Closed

cross check with CISA known exploited vulnerabilities catalog #2558

telelvis opened this issue Jul 21, 2022 · 5 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.

Comments

@telelvis
Copy link

Hello

CISA agency maintains catalog of vulnerabilities that are known to be confirmed exploited https://www.cisa.gov/known-exploited-vulnerabilities-catalog and constantly updates it. It may look like majority is for desktop software and alike, but there are some vulnerabilities for software/libraries often found in containers.
Suggestion is to include this information in the vulnerability report, so reader can prioritize remediation. Perhaps it can be additional field, e.g. known_exploited=true/false.

Thank you.

@telelvis telelvis added the kind/feature Categorizes issue or PR as related to a new feature. label Jul 21, 2022
@stone-z
Copy link
Contributor

stone-z commented Sep 7, 2022

👍 This would be a cool enrichment to have.

It could also potentially be done in a module. My modules knowledge is minimal so far but I think a module would be limited to just adjusting the severity and not adding a separate field, which isn't as ideal IMO

@itaysk
Copy link
Contributor

itaysk commented Oct 12, 2022

This is a nice idea. If someone is interested in working on it, we'd welcome the contribution. If not, we can consider it in a future planning cycle.
Note to implementer: If it's going to call out to CISA then it can't be part of Trivy core. Possible solutions:
1 ) Bake CISA into trivy-db and then it can be part of trivy, but this makes the contribution more complicated. 2 ) it could have been an extension as @stone-z suggested, but I don't think we can make network calls from wasm atm (@knqyf263 ?).
Another consideration is how to surface the result - adding another field to Trivy's vulnerability struct is possible but if using wasm extension it won't be the right place. I suppose we can use the custom field to hold a property bag of data from extensions (@knqyf263 ?)

@knqyf263
Copy link
Collaborator

We used to work on that, but it's suspended now because we were not sure how we should display it in the table format.
aquasecurity/trivy-db#217

@stone-z
Copy link
Contributor

stone-z commented Oct 19, 2022

Wow looks like you were way ahead of me 😄 Is there something that the community can help with there? Or is it just a matter of waiting for a design decision?

@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label May 16, 2023
@aquasecurity aquasecurity locked and limited conversation to collaborators May 16, 2023
@knqyf263 knqyf263 converted this issue into discussion #4401 May 16, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

4 participants