hainenber commented on PR #32288: URL: https://github.com/apache/superset/pull/32288#issuecomment-2667347195
> First, let's note that vulns can be discovered at any time in the lifecycle of a package, essentially guaranteeing non-deterministic results, meaning a SHA that passes the test today may not pass the test tomorrow. This also means that this new check could start failing all open PRs (including those that don't touch packages) when some package gets marked as vulnerable. I don't think it's productive to hold all PRs for unrelated issues. Unless you set the exit code to be 1 when vulns are detected, [Trivy won't break the CI by default](https://trivy.dev/v0.15.0/examples/others/#:~:text=Others-,Exit%20Code,a%20non%2Dzero%20exit%20code.&text=This%20option%20is%20useful%20for%20CI%2FCD.) > Vulns include lots of false negative, as often we may use packages that have vulns, but not in ways that trigger the particular issue. That's often the case with devDeps and other edge case vulnerabilities. We need a clear way to mark for issues that are known to us and aren't real issues given the context of how we use the given package. I should have made the PR clearer in description as this PR would scan for container image vulnerabilities, namely the OS type. We already have GH security alerts for package-type vulnerabilities. > One more point, is depending on how your envrionment is set up, the level of criticality may or may not be a concern. For instance at Preset we run Superset on the open internet and take every security issue very seriously, but in other envrionments (behind VPN, local set up, specific set of configuration or feature flags, ...) the issue may or may not be a concern. Sorting that out is subtle/complicated. For that reason, different organizations have their own package/vulnerability scanning mechanisms - say at Preset we use Snyk on top of the particular set of dependencies we pin for ourselves. This PR is more of "establishing visibility in container image-kind vulnerabilities" which is lacking currently in GH (great hearing you guys having Snyk at Preset, no shilling but it's nice!) than "adding a security blocker for all changes". Some sort of inventory auditing so Security task force can work on with > Oh, one more thing, which tool/tech should we use here? Is Trivy the best choice these days? What are all the options? I picked Trivy because it's lightweight, GitHub Action integration from the get go, open source and does not have account requirement. - [Snyk](https://github.com/snyk/actions/tree/master/docker) has nice UX and large coverage in this area but it requires signup/signin. - [Anchore](https://github.com/anchore/scan-action) is feature parity with Trivy so it's swappable between these two. I don't mind at all - [Tenable](https://github.com/tenable/container-security-action) doesn't get active contribution within last 4 year. - [SonarQube](https://github.com/SonarSource/sonarqube-scan-action) is bulky and has all the features that I don't need just for a mere container security scan. I haven't checked the remaining players so there could be a hidden gem somewhere that I missed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
