Can you explain how Sarbanes-Oxley applies to the situation of an employee sabotaging a production line? Specifically how it would inherently imply wrongdoing on Tesla's part.

Basically, SOX would apply if the numbers Tesla announce in quarterly reports were derived from metrics taken from production-line systems. The wrongdoing is the same in every cause of SOX non-compliance: misleading investors to manipulate stock price.

So Sarbanes-Oxley came about because Enron were stating investor-facing metrics that didn't match reality. SOX compliance comes about if you:

  * are publicly-listed

  * announce numbers to investors

If those numbers are counted by a computer, you must show that you have procedures in place to prevent a single person from making a change to the code which would allow them to choose what number is produced.

So, if you were some web app that mentioned Monthly Active Users in your quarterly results: bam! Your release process now has to be SOX-compliant, since the MAU calculations come from analytics (from the frontend, or from access logs) which could be altered by some nefarious code.

Note that the intent of the act isn't to prevent such a thing from happening, but to make sure there is enough information for external auditors to detect it if it occurs.

I can confidently tell you that some of the largest companies in the world don't do this... Or at least don't do it to the level that an auditor could confidently say "nobody nefariously edited this code/data".

me too, friend, me too

Part of Sarbanes-Oxley is to make sure IT systems are not manipulated. This includes regulating access to systems and controlling software development. Mainly this means, people who write code can't push code into production systems on their own.

One person writes a requirement, this needs to be OKed by another person, then a third person writes this code and it's pushed to production. Controls are setup - e.g. checking JIRA tickets in git logs - that no code without proper authorization (corrrect JIRA status) is pushed and deployed.

People need to be able to trace every code change to the requirement and the OK.

In the core this only applies to systems that are in one way or the other relevant to financial data (like ordering), but auditors usually want to be better safe than sorry. But Tesla might have a SOX-IT and non-SOX-IT.

> Part of Sarbanes-Oxley is to make sure IT systems are not manipulated.

I would expect that there are limits to this. If a rogue employee engages in fraudulent behaviour against you, using "false usernames" to subvert your security as this employee reportedly did, then I don't see how the organisation could be considered responsible.

I'm gonna guess they use github and this guy just pinged an admin to have a few new github users called things like "Legolas66" added to the organisation.

Many orgs don't track github usernames to real human mappings well or at all, mostly because the single sign on version of github is 3x the price.

In the financial industry part of SOX is segregation of duty.

As a developer I'm not allowed to have write access to any production system, except in an emergency via a break-glass mechanism, which is audited to the hilt and back.

It also means we're not allowed to deploy software to production systems. This has to happen via a specific chain development > regression / user acceptance testing > production.

All those environments need to be physically seperated with very specific access requirements.

The deployment process needed to be signed off by outr auditors.

I can't speak for other banks, but they probably need to implement the same -, or a similar system.

Neither can I speak for SOX requirements regarding software fo car manufacturing.

Not only banks, every company listed in the US. It was the same where I've worked, and it wasn't a bank (Enron was no bank either).

> As a developer

What if the employee were a sysadmin-level person that sidestepped the normal process?

The you say in your compliance policy that you run regular audits for these kinds of actions and remediate them on a case-by-case basis.

E.g. run quarterly reports for changes to prod that didn't go through the regular release pipeline and note down which P0 they corresponded to.

Which would then be roughly why this happened and is coming out now.