We deal with this by having multiple vulnerability scanners. Product A and Product B both scan your active environment. Product A scans Product B. Product B scans Product A. Additionally, make the vendors of those products sign NDAs so your threat actors, other than insiders, don't necessarily even know who they are. An attacker then needs to not only compromise both, but figure out who they are in the first place.

To this I'd add what is colloquialy referred to as a "Chinese wall", so that even insiders aren't aware of the full picture.

For anyone who hasn't read it:

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Are there any people working seriously on this? I'm aware of efforts for OCaml (http://gallium.inria.fr/~scherer/drafts/camlboot.pdf), but that's it.

The Bootstrappable Builds community (which camlboot is part of) are working on a lot of different efforts in this area. The main one is going from a small amount of machine code to an entire Linux distro, which is in-progress.

https://bootstrappable.org/ https://bootstrapping.miraheze.org/

Here's the original resource on Diverse Double Compilation to counter Trusting Trust Attacks: https://dwheeler.com/trusting-trust/

Notably I know the Rust compiler has been verified in this way (or at least certain versions of it have been verified), but it shouldn't be hard to do the same for any language with multiple independent implementations.

If your threat profile says you need to audit your vulnerability scanners, you audit your vulnerability scanners. There's not really a problem there right?

NIST also says: if your scanner finds a vulnerability, it's up to you to VALIDATE that it's not a false-positive.

False-positives abound on these scanners.

I've never had to. I wanted feedback from people who have.

that was the issue in the solar winds hack: https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-c...