What's worse, in several jurisdictions (some places in the US included, IIRC), if a company is found to have caused damages based on this sort of "negligence", the developers are legally to blame - not management.
Real engineers don't sign off on a project if they think the building is going to fall apart. If a company starts ignoring security for the sake of profit, developers should react by literally walking out and refusing to have anything to do with the project. Anything else means they share the blame.
A building engineer could probably drop a hint somewhere and have all kinds of inspectors come knocking, but there's no "building code" for software except in very specific cases; it's perfectly legal to develop insecure software otherwise, and to keep that insecurity a secret from users.
One power we all have is how valuable we are in the jobs market. If you’re a decent engineer in today’s climate, you could get a new software job in days. And it’ll take your company weeks to replace you if they’re lucky, and months to bring your replacement up to speed on what you were working on.
The idea that you’re stuck simply working at the whims of management is a self defeating illusion. It is only as true as you believe it to be.
And your manager can't afford to fire everyone who pushes back on shipping insecure code. And its not a black and white thing. There's almost always paths which work for everyone. Actively looking for those paths isn't the sign of a bad employee. Its the sign of leadership.
In my experience people who step into that sort of responsibility don't get fired. They get promoted.
I feel like they actually can, since:
- most people want to get paid and to have a job, not get fired over principles
- therefore, they will bend to the whims of management and release whatever they're told to release
- they don't actually have any sort of leverage, as most developers, and are easily replaceable
Here's a similar post from today: https://news.ycombinator.com/item?id=27629543
It's an indication that engineers know in some cases they are releasing broken software, and management may not be aware. Just look at this page and it's article, developers know about this, because they congregate to discuss how they release broken software, know they should do better, yet don't always tell management about faults in the product. A business shield only protects people when they are conducting business.
I think under those conditions most firms would prefer to own the risk themselves.
The point that you missed, however, is that an employee should not accept the risk but should transfer the risk by notifying the employer. Otherwise, articles such as this are fodder for putting the blame of exploited vulnerabilities squarely on employees who knew of the risk and, according to some of the comments here, plotted not to tell their employers.
It absolutely does. If you hold any legal power to reject a deployment (like a true engineer), then you can sue the company when they hold it against you, so they won’t.
If you do it in any other situation you are just being difficult.
If software developers do that they are just being difficult.
I mean let's be real, in the US you definitely could. Pretty much anyone can sue anyone for anything.
But between suing McDonalds, and suing the close-to-minimum-wage-employee working at McDonalds, which group do you think you would be most likely to collect from in the event you won? Not to mention the public perception of suing an individual McDonalds employee.
No, for this particular example, it would almost certainly not be possible. In the US, employees are shielded from personal liability under the doctrine of respondeat superior.
[citation needed]
Company employees in the US (including software developers) are shielded from personal liability by their companies, unless that liability was created by breaking the law or gross negligence (with the latter being extremely difficult to prove). The company can fire the developer for being incompetent or negligent, but the company would still be on the hook for any damages.
The same is true when outsourcing development to a third-party development house. The client company may be able to sue the development company, but the individual developers would be shielded from personal liability by whoever they worked for.
The only situation I can think of where a developer would be personally liable for buggy or insecure software is if they signed and sealed source code as a professional engineer (this is practically non-existent), or if they were freelancing and contracting with companies directly. In both cases, they would be eligible--and often required by their clients--to purchase insurance against errors and omissions.