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."
It has to be like a legal obligation in large software or certain domains to pass like either:
- HP Fortify (HPFOD)
- IBM AppScan
- Coverity
or similar security scans
Open Source does not need to pass this, but users* of those libraries / programs
should pass this and then pass the scan.
Some of these companies provide "free scan" for Open Source / public GitHub projects.
It happened to us, that HPFOD would find bugs in some Maven Java Libraries JAR file
that we had to patch ourselves, in order to be put that JAR in production.
The other problem is that you can pass this year,
but then next year, the software will fail as new security issues are discovered
and newer best practice must be followed.
Example from 2014: /* Log4J */ /* SLF4J */
LOG.error("Order name: " + orderName);
LOG.error("Ordername: ", orderName);
Those passed before, now you would get a "Log Forging" security issue.
LOG.error("Order name: " /* Correct Log4J */
+ (orderName == null ? null : orderName.replaceAll("[\x1B\0\r\n\t\f]+", "_")) );
Control characters, new line, line feed must be stripped
from any @Tainted String / Object... from the logs in production.
Otherwise, someone could do this:
orderName = "my order\n\n[INFO] The user logged in successfully.\n\n";
or attacks like you open the server logs in VIM or shell and then
"ASCII ESC sequence" do things to your terminal...
https://www.owasp.org/index.php/Log_Injection
And yet, ironically, that certification process does not cover security. The software on medical devices is well known for being almost ludicrously insecure.
This doesn't align with the business interest. If it costs money and doesn't save money or make money you're wasting your time.
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.
Good, inexpensive web hosting
Liability is what's gonna kill the free software movement. Many reasons.
Liability for general purpose computing is not going to happen. It would make software way more expensive, and mean locked down desktops and laptops that prevent users from downloading, connecting, and configuring. People are not going to accept that.
For safety critical software, such as automotive control (not infotainment), elevator systems, etc. we already have liability regulations.
Liability for a insulin dispenser makes sense. Liability for a free webapp does not.
So very much this. Given the notion that out of fast, cheap, and $x, you can have any two; it's practically a truism that PHB/MBA types will always choose fast and cheap, no matter the value of $x. The only exceptions are when you're contractually or legally obligated to have $x, such as in PCI or HIPAA environments. And even then, fast or cheap is only given up for $x very begrudgingly, and sometimes only on paper but not in reality.
Imagine all the people...
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.
Liability for "free" software rests with the people who use it to make money. They are the ones on the hook to ensure that the "free" software is suitable for the purpose for which they are selling it.
Organizations which use "free" software directly are themselves responsible for whatever happens as a result of using that "free" software.
GPL is rather long-winded - take a look at the MIT license for a notion of where liability for "free" software lies.
Before you say "that's gonna change when liability comes into the picture" - no, not at all - people writing software who don't know how it is going to be used cannot conceivably be held liable and more than Sir Issac Newton's estate could be held liable for a mishap on the space shuttle.
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.