> In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor.
Like how that amateurish but high profile Wannacry attack revealed a much more lucrative Monero mining botnet that was running with the same exploit for weeks longer, but some script kiddie ruined it
It wasn't one of those "healing viruses" either; it was exploiting a weakness and preventing others from doing the same.
This is also a solution (albeit with a race condition) to one bug that the Morris worm had: the same worm infecting a host multiple times and the multiple instances drawing more attention / stepping on its own feet. Other worms likely have had similar flaws.
(Any suggestions to eloquently un-mix the worm/feet metaphors?)
Deterministic builds cannot come soon enough. And really, builds are not enough, we need to be able to extend confidence in the execution of the programs we write much deeper than just builds.
This doesn't do anything for people who buy SolarWinds Orion, which is a closed-source off-the-shelf tool that gets picked up everywhere because of a combination of good sales tactics, compliance checkboxes, and ability to remove work from all involved.
Going back up the chain, a technical solution probably won't solve the issues inside SolarWinds either. Systemic organizational issues lead to RCE backdoors and implants distributed on official update servers, signed with authentic keys.
Of course, if following best practices, all build machines should be equally compromised. ;p
Still doesn’t help you if the attack is sufficiently upstream..