mistercrunch commented on PR #32288: URL: https://github.com/apache/superset/pull/32288#issuecomment-2666347786
I like the idea of having a vulnerability/package scanner in the open. A few things about it. 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. For release management, it's likely that older releases, say 3.x.+1, would have numerous vulns, making it hard/harder to provide LTS if/when that's a goal. 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. 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. In any case, there's value in knowing this, at certain points in time, mainly around release time. Given all this, seems a daily/nightly job testing a list of "supported" releases (latest, LTS, master) would make most sense. -- 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]
