What I take away from this is that one malicious actor was able to single handedly deploy malicious code and that there were no processes in place to stop this. That is a far more worrying issue
on my Haas mill, the code is directly editable by the operator. On my robots, the code is 'taught' by moving the arm and telling the machine that the new location is the updated. It is routine to have to adjust minor things in the robots, the operator would have to have access to do their job.
I had a welder put a washer under a sensor on my robot one time, making every weld 1 mm in the wrong spot. We couldn't figure it out and ended up reprogramming the entire setup, 8 hours, to fix it. A week later I noticed the washer, put there by a guy who I fired for bad attitude a week before. Once I had found the washer, I had the choice of going back to the old code, or leaving it with the new code.
I left it with the new code. I didn't have another 8 hours to waste to fix the fix.
Even tiny companies like mine can have sabotage. Why not Tesla?
I suspect they aren't. They're trying to hit a number. Elon is on site personally stepping on anything that might impede that goal. They're in desperation mode, running a car company like a startup, erecting tents to house parts of the plant, firing contractors left and right. Are some of their coders banging in changes with little to no review and pushing to "production" -- such as it is -- right off master? Would not surprise me at all.
I don't know what to believe. On one hand Elon claims they've got some sort of admission from someone. On the other I remember the theories he entertained when a Falcon 9 blew up on the pad; “We literally thought someone had shot the rocket.” I tried to explain how infeasible that would be but people don't want to hear it; lots irrational thinking around all things Musk/Telsa.
Anyhow, sabotage isn't uncommon in big plants. Grievances emerge and people sometimes pull some Bolt Weevil stunts to hit back. Usually manufacturers deal with the problem as quietly as possible. Elon, knowing perfectly well his email would leak, decided to make a splash instead. Maybe looking to line up some excuses if they miss the number. Who knows...
"That is a far more worrying issue"
Not for me. We have filled the world with safety; everyone playing by Marquess of Queensberry rules. Nice to see an exception. Yes, even if it costs a few lives.
It seems like if an organization is allowing randos to push changes, they would also allow randos with valid pgp to push changes as well. So the investigation would change to “Who the fudge is B8956DBFEE7C105C?” instead of “Who the fudge is Bob Goodguy?”
You couldn’t merge changes from multiple people otherwise.
Signed commits do fix this although you have to be careful about your threat model. Lots of software (e.g. gitlab) will prevent alice from pretending to be bob but will not protect you against server compromise (because public key directory and signing enforcement are done on the server).
Working at an org which does signed commits, it doesn’t buy us quite as much as we would like.
Also, if you enforce signing you can’t mash a server-side “merge” button anymore because that commit would need to be signed...
This complicates the pr/mr workflow for teams and increases resistance from those who don’t see the value in signing.
Maybe my org is just simple but if “John Doe” started submitting pull requests and prepend merged them, it’s me on the hook and there are people interested in who John Doe is. And in my org, even John Doe needs a network credential so even their local git instance (which I’ve never seen anyone use) would need a credential.
Which is why it's important for the security team to directly manage and be responsible for the code repository server. Usually the server also stores all the git repositories in some filesystem directory, meaning that server compromise would allow an attacker to remove all the company's code, regardless of permissions set for those repositories, and potentially leak it.