alt Hacker News> 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.
The gold standard deep and certain vulnerability remediation requires A/B test exploit sample code.
You're really going off into the weeds about other concerns rather than covering and ensuring known flaws don't exist than can be checked automatically and mechanically given proper infrastructure that don't need significant or constant human attention. There is a place for human attention, but it isn't going to scale to check 10 million machines.