alt Hacker NewsNot necessarily. The problem with clipboard audits using version number matching alone is they don't account for patching. The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it. For example, RHEL would be a Swiss cheese exploit magnet if they didn't regularly patch the heck out of every CVE for every component that came down the feed.
> The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it.
that doesn't work if there isn't an exploit
the other problem with both "clipboard audits" and your suggestion is that neither take into account the full context of the system. in general, a potential vulnerability might be significant, but in the context of your system, or tesla's, it might often be completely irrelevant. the converse is also true, and more problematic. it is very common for a potential vulnerability to be masked by other system characteristics.
the only way to do an audit is to do a comprehensive review of known potential vulnerabilities in the full context of your entire system stack and a well defined threat model requirement. otherwise, you will both underestimate some and overestimate many others. and you can't assume this is static; it must be repeated continuously because inputs and assumptions are constantly changing.
patch-and-pray is worse than a waste of time.