Open bdellegrazie opened 5 months ago
Depending upon complexity we are happy to help implement this, but would require guidance on the best way forward. Thinking ahead there are similar requirements for GCP / Azure too.
We are currently investigating to leverage https://github.com/AppThreat/vulnerability-db which does include support for Amazon Linux: https://github.com/AppThreat/vulnerability-db?tab=readme-ov-file#linux-distros
@nscuro Please let us know if there's any way we can assist with development etc.
@bdellegrazie With quite a bit of delay, we finally got around to publishing an issue and accompanying Google Doc for our plans here: https://github.com/DependencyTrack/dependency-track/issues/4122. Pleas feel free to join the discussion on it. :)
It was also discussed in yesterday's community meeting. I'll link the recording in that issue once it's available.
Current Behavior
At present, when uploading SBOMs for an Amazon Linux 2023 based AMI, the AMI is reported as "not vulnerable" because the SBOM contains packages prefixed with
amzn
(or similar). The end result is that no security vulnerabilities are reported by Dependency Track on these AMIs - even though Amazon's own AWS Inspector or the Amazon Linux Security Center reports multiple issues.Proposed Behavior
Include Amazon Linux Security Center vulnerability feeds as another data source. They apply specifically for Amazon Linux packages so it should not interfere with other data source providers.
Example would be to incorporate the output of Amazon Linux Security Center via RSS feed or similar.
Checklist