Slashdot Mirror
What Happens When Software Companies Are Liable For Security Vulnerabilities? (techbeacon.com)
mikeatTB shares an article from TechRepublic:
Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off... Things have been this way for decades, but the status quo might soon be rocked as software takes an increasingly starring role in an expanding range of products whose failure could result in bodily harm and even death. Anything less than such a threat might not be able to budge software engineers into taking greater security precautions. While agile and DevOps are belatedly taking on the problems of creating secure software, the original Agile Manifesto did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress..."
"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.
The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."
"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.
The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."
And yet, ironically, that certification process does not cover security. The software on medical devices is well known for being almost ludicrously insecure.
In spite of people confusing inflight entertainment systems with avionics, yes is is done all the time j. The aviation industry. Every piece of software that controls the airplane must be built to RTCA DO-178B/C design processes. Among other things, every input and output to every module is specified in the design process, and out of bound input responses are chosen. Then in writing the software, the inputs are checked, and then validated against random and maliciously crafted input. Bogus states are injected to ensure that each module identifies and recovers from an invalid state.
It's not really that much more expensive, as mature engineers aren't really more expensive than programmers, are a lot more effective, and the debug cycle is a lot faster when it's designed in at the front.
Reading the article, it's all people with an interest in peddling solutions to the problem, naturally. This is a marketing paper.
Claiming that Software Engineers have "failed" at security is akin to claiming that police have "failed" at crime stopping crime. And the courts aren't going to suddenly start blaming companies for the actions of threat actors unless there is some representation that the products they're creating are unhackable.
If your company were going to be held liable for security vulnerabilities, finding and plugging these holes during development would be part of your job. As things are, there's no reason to look for or deal with them unless there's a way to make your customers pay for it. This holds true for all custom software, either open or closed source.
It really depends on how big the company is, how often they get busted, and what exactly they are liable for. As it stands now, the average small company can go 20 years without an incident. The small company that skips on security can likely outcompete and outlast the small company that doesn't. Sure if they get unlucky and have a security incident, it could bankrupt them but the odds are in their favor that skipping security gives them a competitive advantage to the company that doesn't.
LOL, HP Fortify, the tool that marks almost every line as a vulnerability to cover its own ass. It generates so many false positives that it is beyond useless. We'll just keep doing our own reviews. ...and if junk in your log manages to cause a hack, then it is not your software at fault. It is the log viewer software that is at fault. If that happens to be VIM or your shell, then yes, I boldly claim that is a bug in those pieces of software.