An example of how security teams respond to CVEs

In his Upstream session, James Berthoty CEO of Latio Tech provides an overview of what the problem is with submitting CVEs to GitHub issues-why it's frustrating for compliance teams and maintainers both. In this clip, he show how security teams often respond to CVEs.
Watch the full talk here: explore.tidelift.com/upstream...
Transcript:
But just to give an example, in case you're unfamiliar with what security teams are seeing. First of all, a lot of tools don't even separate this base image from the rest of the things that are getting added from it. But this is showing fixable things on the base image. And obviously this is stuff that you don't have direct control over. This would be just running a regular update against the base images, which would show this, but this already shows a level of understanding of containers that frankly, some teams don't have. But then if you go into these, you would think there are vulnerabilities that you can actually fix. But you'll notice here the first three things that show up are different standard lives with critical vulnerabilities. So you're thinking, Oh, we got to freak out. We got to like-I would publish this CVE against the Argo page to say, you know, not all JavaScript characters are considered whitespaces and you start thinking do we use JavaScript or wait this is in go Lang and it's not properly sanitized. Like how does this impact anything? It gets very complicated very quickly, to try to figure out am I actually vulnerable to this vulnerability or not? And at the end of the day, if you look up this package in the package list, you'll see that it actually comes from customize. And so really, Argo CD isn't who you should be reporting the CVE against at all, it's customized. And within that there's its own level of complexity around figuring out the vulnerability or not.