Sertaç Özercan
Sertaç Özercan
@reetasingh sure. let's start with a design doc on how this would work especially if it can work across multiple scanners. feel free to use google docs or whatever you...
@reetasingh thanks for the investigation! I think we would need that information and package names/versions so this might be a blocker for adapting sarif as input in the short term.
thanks @reetasingh for the investigation and the doc! 🙏 Copying the blocker from your doc here: ``` The biggest blocker is that the Sarif output report generated by Trivy tool...
@craigbox same applies to grype too unfortunately. example: https://snips.sh/f/2C3_JBXLeC?r=1
that's correct. This comment in the code is old and should be removed.
@anubhav06 in the ideal world, copa would just parse SARIF files for vuln results without the need for logic for each individual scanners. However, as you and @reetasingh pointed out,...
Just for comparison, this is what Trivy's own JSON output provides today: https://snips.sh/f/BSl2OG1udf ```json ... "Metadata": { "OS": { "Family": "debian", }, ... "Results": [ { "PkgName": "curl", "InstalledVersion": "7.74.0-1.3+deb11u3",...
@dependabot recreate
@duffney can you tell a bit more about this? any distinctions or advantages over using trivy report?
> it would make scanning unnecessary wouldn't you still need to scan it (what `trivy sbom` does)? it just scans the sbom, rather than the image itself