More thoughts on #xz: it seems that the bootstrap code for the backdoor was hiding in difficult-to-understand code. I hope this prompts people to start taking code readability seriously as a security factor.
It's much harder to hide malicious code in code that's easy to understand.
@joepie91 Difficult to understand is a nice wording for basically hard obfuscated.
Noone reviewed this and said "i understand all of this".
@mcfly I was thinking through whether this code would have made it through the dependency auditing process at $customer, and my conclusion was "no, it would not" - they have a policy that code that we cannot understand will never be approved, and this is basically why that policy exists...
@joepie91 Yeah, we'd also have policies that *should* prevent something like this.
I am not sure though we would have catched that. Its in a testcase and also compressed so some "weird binary for testing, right?"
It is a good use case for the biweekly tech meetup with the devs though.
And a good reason for money for trainings for the developers to learn to do security reviews.
Knowledge gives confidence to reject something.
@mcfly $customer auditing involves everything that is part of the release, so also test files - an eval on anything related to a binary file would definitely be considered something that warrants suspicion and probably rejection.
Like, it's just a general rule of "if it's in the release, it must be explainable and possible to reason about". Google dependencies frequently get rejected because they do not meet this standard...
I think that that one rule alone - "anything that cannot be explained, cannot be accepted" - would prevent most attempts at backdoors, to be honest. At the cost of not tolerating needlessly bad code.
@joepie91 I agree in theory but i see it too often different.
Code reviewing is often something that is done in an improvable way.
I will try to use this to get money and ressources for some training there.