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."
Liability is what's gonna kill the free software movement. Many reasons.
Even if I act as a true professional and do exactly what I'm expected to do to deliver secure code...ill get fired.
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.
It doesn't matter what the developer wants, ROI is king. Everything else is a firing offense.
Ha ha ha ha
Nada software, the only one without bugs or security holes. http://www.bernardbelanger.com... Just a kindly reminder: you get what you pay for.
Has it been theoretically shown, that real security is even possible in current commodity computer systems?
I recall such a proof to exist for capability based systems with hardware enforcement of the model.
So will we have to replace the entire stack of hard and software (yeah, right...) or do we have a chance at it with our current systems?
Just look at medical devices. They don't cost that much to make but have to go through a long certification process that needs to be paid back.
Same with software. Something like SOX, PCI or HIPAA will pop up to certify "secure software" and software that is patched on a regular basis and people will end up paying for it. And on top of that every piece of software will be "certified" on some platform, similar to a game console. If you run it outside of the certified hardware you lose the ability to sue.
You're all idiots if you think you will be able to run software on some of the ridiculous configurations I've seen in my time and expect vendors to pay for it when it breaks because of your stupidity.
If not already, there will be a clause added to the Terms and Conditions saying, "(a) We're not liable and (b) all disputes will be settled via arbitration."
It must have been something you assimilated. . . .
In NZ we have the consumer guarantees act.
In effect it says they must be fit for purpose, free of defect, and have a reasonable expectation of life.
This is in addition to warranties, so the warranty for a refrigerator may be 12 months, the CGA would say 10 years.
The CGA also says that the supplier is also liable for any additional harm, e.g. your phone catches fire and burns the house down, the supplier is able for all losses including the house, accommodation while it is rebuilt etc.
You can also NOT contract you way out of the CGA
So it would be an interesting "test" to see if a software product can be held liable under the CGA, e.g. a OS vulnerability that is used by hackers to encrypt your data, can the CGA be used to hold the supplier (e.g. to local shop where you bought it from) liable.
... 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.
What you are seeing is the maturing of software engineering as a profession. A few hundred years ago if you needed surgery you would go to your barber. The reason for this was that they were usually in possession of the right tools. The medical profession eventually matured to what we have today, where a surgeon is a specialized physician. But that didn't happen overnight and lots of people died in the process. In fact, we didn't even have a theory of infectious disease until the 1830s.
The point is that right now hardware, including its firmware components, is oftentimes made without the involvement of a software engineer. It wasn't that long ago that software engineers didn't even exist and in time as the profession matures we will get to the point where developing a piece of hardware without the participation of a software engineer will be unthinkable. But we are not there yet.
An important side note is that there is a difference between a coder, a developer, a programmer, a software engineer, and several other specialized disciplines in the software arena. I think that a precondition to solving the problem identified by the article has less to do with things like development methodology (that is not central the problem at hand) and more to do with establishing minimum standards for some who claims to be a software engineer. For instance, a surgeon in 2017 has to meet vastly different minimum qualifications than a surgeon did in 1917. We didn't even have software engineers a hundred years ago, so who knows what it will actually looks like by the time the field really starts to mature.
Sorry, I stopped there, at "Even with the move toward more agile development and DevOps". What's the link, supposed positive here, between the two ?
Both "old" and "new" method won't never mean better software than the people using them.
Bad engineers using old method (V cycle ? Tons of documents ?) or new methods (you said agile, as in "get as many things done as possible, as quickly as possible, using shiny web app like Trello or Kanban-something" ?) won't make secure software.
May be with good engineers, you can achieve good results, whatever the method is.
More or less related : ISO9001 doesn't mean that the certified company makes good products, it means that it produces always the same quality, good or bad.
This may sound a bit like a troll, but I'd like to add that, since young engineers favor more agile methods, and considering the lack of experience, combined to the messy sensations I sense in agile methods, I tend to think that agile methods would produce less secure software ...
Totof
It is hard enough to produce a finished (or, rather, deployable) software product without adding impossible constraints on it. Harder still to make a profit out of it if you are going to have to carry liability insurance assuming that would ever be available.
My current project is a web application with client-side javascript, running on top of an unknown operating system, connected via the Internet via unknown switches and routers, with the back end with two Linux Virtual machines provided by a vendor whose hardware and hypervisor I don't know. Those at least I know but one is running a Glassfish container running in a JVM and the other is a MySQL data base engine. I would say maybe 2% of the code running to make it all go is something that I wrote or had direct control over.
In that chain of software I can think of a dozen things that could break and spill (either accidentally or via malware) private customer information. I have defended against all of them I can think of, but if there are 12 I can think of there is probably another 12 I haven't thought of. If I had to accept liability for anything bad happening in any of those millions of lines of code I basically would be ill-advised to do the business. Or the insurance cost would just price me out of the market.
My simple little social application is in a different category than something life critical. It isn't responsible for air or ground traffic, monitoring someone's heart, controlling toxic materials, guarding against fire or explosion, or managing someone's money. It used to be that kind of software was always run in carefully controlled environments. There was at least a chance of managing the risk of product liability.
These days? I see avionics applications running on iPads. Sooner or later that fact will show up in court.
Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off. More than 10,000 issues will be reported to the Common Vulnerabilities and Exposures project this year.
How about you get what you pay for? Many management teams have decided that adding security costs money and it's more cost effective not to spend many cycles on it, but rather to just deal with problems as they pop up.
I don't think you can spin that as software engineers "failing." If the management wants security, they can pay for training, consultants, audits, bug bounties, etc. There are lots of ways to address this issue. Besides, perhaps the number of bugs is skyrocketing as a natural consequence of all of the new software projects and products.
The Daddy casts sleep on the Baby. The Baby resists!
Eventually responsibility will come looking for your ass.
If the engineers don't fix it, the lawyers will. You might not LIKE the fix. But lawyers will provide one. They always do.
Automated test should be including known attack vectors, if the build is vulnerable, the build fails.
The processes that created the problem will most definitely not be the processes which bring us closer to a resolution.
We'll essentially get shrink-wrap contracts that basically say "This software can't do shit, if you use it regardless, sucks to be you."
In other words, what we already have.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
They make software and maybe people buy it.
FFS
It's management that won't pay for properly written, properly tested software. That takes time (measured in metric shit-tons), and that makes it too expensive in every case I've ever seen.
Yes, I have never seen a piece of software that was 100% tested. Don't even know if it's possible? It would be interesting to to hear from anybody that works around code like that. I can't even guess where it would be. Nasa? Maybe some little bits here and there. Nuclear Plants? Doubt it. CERN? High end CNC machining? Old COBOL?
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.
I am not sure it is fair to say SW engineers don't care. I think it is better to acknowledge that securing millions of lines of code is a lot harder to do than finding a single chink in that same section of code. Especially if the code has to run on a bunch of dissimilar systems.
Even the most mundane application you can write will depend on many thousand lines of code you did not write yourself, i.e. compiler/interpreter. Lets all reflect on trusting trust for a bit.
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 it were literally only companies which were on the hook, you'd see a bloom (not a renaissance, because there has not been a dark age yet) of OSS. If companies are liable, but J. Random Coder on the street is not, then you're going to see FoSS take center stage simply due to lack of liability.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Not a security vulnerability - as in, no malicious actor exploiting a security flaw - but killing people? BT,DT. https://en.wikipedia.org/wiki/...
If (and that's a big "if") companies become liable for software failures then it will be most likely that there will be a guideline of standard programming practices. Likely it would restrict companies to using programming languages that have already been heavily analyzed and their security weaknesses identified. CMU has composed guidelines for multiple languages and platforms which could easily be identified programmatically. Such regulation would be a deathblow to companies using script kiddies to scrape together IoT devices in their favorite language du jour but I think we would be better for it. Also, it may also force companies to analyze open source software and (ultimately) submit patches which makes things better for everyone.
Anons need not reply. Questions end with a question mark.
You built a $19.99 wireless camera with no security that sells in 2 AM infomercials? Sue your ass out of existence. Sue your Cxx's into the food stamp range. Fuck you assholes.
Oh shit, now wireless cameras cost $49.99. But they're secure? Works for me.
if that ever happen, cost of software development would increase exponentially. I think focusing on what steps to take when someone exploited the vulnerability would be more useful + less costly. For this we can have new companies who's focus is to guide the stakeholder and mitigate the damages in case software have been hacked.
to empty out the storage closet and then he bills for miracle work?
Oracle was claiming their products were "unbreakable", "can't break in", that sounds like representation of unhackable to me.
People are used to new software coming out on a basis of at most a few years, often a few months. That will evaporate along with most free (as in beer, not as in speech, though it'll probably get both) software. Engineering teams will scrutinize everything, telemetry will skyrocket, and they may start removing large chunks of the code just to keep from being sued. Just about the only thing that will be good about it will be that outsourcing may dry up, but I'll bet you even domestic programmers aren't up to snuff.
A lot of people who are interested in computer science won't even bother - the typical "hacker mentality" would chafe against the sort of procedure that surrounds software for, say, the Space Shuttle, which is insanely more complicated, slower, and supposedly has binders documenting every last change to every last line of code.
If this ever happens for general-purpose software, then software as we know it is screwed beyond words.
Fully agree with your post. I was writing the below in a separate comment when I saw your reply and felt what I had to say supported your view, so here it is.
Because neither DevOps nor Agile are exclusively about security. What worries me is that someone actually believes Agile development and DevOps inherently mean better security!
Agile is a term used to describe a pure 100% cargo-cult thought process ("set of principles") that claim to make software development and testing processes less painful through things like minimal changes (i.e. small or incremental, rather than large sweeping commits), use of things like CD/CI (continuous deployment / continuous integration), and strong faiths in test-driven development. This is in contrast to what is labelled "waterfall", which are set dates (i.e. Q1 2018) where features X/Y/Z and bugs A/B/C must be implemented by -- and then said version released on/around said date. In short: Agile does not inherently mean better security -- incremental changes are not inherently insecure or secure, and the only good tests are unit tests (you cannot sanely do, say, penetration testing through a spec/test). You might be able to implement a "security test suite", but that isn't the same type of thing/test as a unit test.
DevOps (sometimes called TechOps) is just a term used to describe an organisational model (grouping) that combines (historically separate) job roles of software (and/or web) developer, systems administrator, systems engineer (and/or architect), network administrator, network architect, database administrator, and operations (i.e. deployments, service monitoring, NOCs) into a single role. In other words: each DevOps employee is essentially expected to be a master of all of the aforementioned subjects (rarely if ever the case). But by now, it's become almost a "way of life" rather than a company group or team; it's now a proliferated belief (especially in San Francisco, Silicon Valley, and New York City) that "being a jack of all trades, master of none" is better. I have no idea how this began.
Systems administration, network administration, and systems architecture *do* involve security in some form -- that is to say, systems and network administrators think about security, but *not* in the same way (or to the extreme) that an InfoSec group does. The latter includes public and private network scanning (open ports and service versions), vulnerability testing (internal and external), software version analysis (i.e. ensuring version X.Y.Z has no pending CVEs), malware and virus scanning, PCI compliance, DSS compliance, and god knows what else. Just ask someone in InfoSec, they can tell you; they do a LOT more than just this.
Subjective/opinion:
As a systems and network administrator for the past 25 years, and who does software programming (OSS) as a hobby (but not professionally), in my experience most "DevOps-centric people" **do not** think about security. These are more often than not software developers who have been handed keys to the kingdom because they know how to launch an Ubuntu Linux instance on AWS and know about "magical" commands like netstat and maybe lsof. Software developers rightfully think about very different things than we SA/NA folks do, and vice-versa. And as such, security is often neglected or thought of only *after* a security incident has occurred, not prior. Systems and network administrators -- and I don't mean BOFHs -- historically have been the ones to say "no" and to ask the questions "are we sure this is a good idea?" and "do we really need this?" (something that has often caused annoyance/grief in developers -- sorry, we care about the well-being of the system and network, including its resources); software developers tend to focus just on solving whatever problem or issue they're handed and not think about the bigger picture (i.e. how what they do or
The company I work for bought software from a relatively large vendor. We did some basic security testing on their software, and it had many many security flaws (best being RCE and ability to download any file from the filesystem). :facepalm:
We reported it to the vendor and they said we'll have to pay for these "feature requests" to be implemented. Asked if they followed OWASP top 10, they asked if that was a sofware library and why they should use it.
But not only for the reasons cited here. The main cost would be in retaining experienced programmers. Right now, many companies are getting rid of all their older, more experienced programmers so they can hire kids right out of college for a fraction of the price. Many of them have trouble spelling security let alone know how to implement it.
Safety and security are independent requirements. An expensive insurance bill or loss of operational trust is not a measure of safety.
In the real world of buildings and machinery security is only occasionally a factor and often clashes with safety. Safety is always number one at the expense of security.
Agile and devops have fuck all to do with security.
Bullshit like yours demonstrates that the mbas aren't the problem, developers are. It's pretty straightforward to write secure code. You just have to have the maturity to figure out what the modules are supposed to do before you write them. You know, what is an acceptable input, what is an acceptable state, what to do when those don't occur, and write the software to do that. Not rocket science, though applied to rocket science.
...that's about *profitability*.
You're either ignorant or full of shit. There are several industries that have coding practices which make inherently secure code. Nuke, for example, code has software engineering done before coding, instead of being a napkin and bullshit. Consequently, the nuke industry has much, much more robust software. In fact, it wasn't the industry's software that got compromised, it was the Plc firmware.
Even with the move toward more agile development and DevOps, vulnerabilities continue to take off
Last time I checked, both of those fads tend to harm security, not help it.
Whether liability is accepted by the software company or not, the crown goes to the one that can take liability for the same price as the others.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Look what happened to general aviation when cessna, piper, et al got the pants sued off them. A small 4 place plane used to cost about as much as a mid range Cadillac, after the lawyers got through with them they cost $200k.
lose != loose
Well doctors really fail at immortality, so blame them for that as well. You can't fine a doctor every time a patient dies. It's not always the doctor's fault. People die. We don't understand human body enough to prevent that.
Software engineers (usually) do the best we can. Software systems are some of the most complex systems humans have created. We go into software development knowing we will never fully understand how the software works. But we can still create something that is useful, even with that limitation. It will not be completely bulletproof, but it will improve the quality of human life. Either we accept that limitation, or stop using software at all.
If you disagree, please do show me a practical way how to write completely secure code.
"Even with the move toward more agile development and DevOps, vulnerabilities continue to take off..."
Should read as follows:
"Because of the move toward more agile, less detail-oriented, lower quality development and DevOps, vulnerabilities continue to take off..."
"Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off."
The root cause of the vast majority of security failures is Microsoft Windows running on Intel hardware.
This is a business problem, not a software problem.
Company analytics show the cost of handling issues after they happen is lower than the cost of avoiding them in the first place, so that's what they do.
Why? The lawyers have not yet been loosed.
That being said, I doubt prices would rise too much. Largely because they would destroy their perceived markets.
... in response to litigation.
I predict the EULA inclusion of waiver of liability is going to be removed.
It's similar to signs in the parking lots of Walmart saying, "Not responsible for damage from shopping carts."
While that sign may discourage some shoppers from filing damage claims, it certainly does not protect Walmart from liability in all cart-related matters.
As TFS suggests, computing devices are becoming more critical and damages more damaging.
It little behooves the best of us to comment on the rest of us.
Not surprising since most coders are Programmers and NOT Engineers.
We simply developed our own Logging framework tools over Log4J,
similar syntax to SLF4J, but proper,
like so many common examples on StackOverflow.
Unfortunately, Log4J / SLF4J did not patch for this yet... to my knowledge.
They log as is, which is what you want in dev mode,
but not in production mode and there is no security flag to go around it.
There are so many rules when you do web apps
and if you think that just adding Spring Security
and similar framework will make you pass HPFOD
then you are very far from it.
Anyone care to explain how agile is supposed to improve security?
It will be the hardware companies who buy the cheapest IoT hardware they can find and slap the manufacturer's sample code on top of it, display their logo wherever they can, then ship.
To which I say, good fucking riddance.
Couldn't agree more. The notion that the road to computing security runs through agile and Devops seems to me to be as unlikely as the notion that the way to get you and your bicycle from New York to Bermuda is to head off on said bike for the Bering Strait (in Winter) so you can get to Singapore then think out your next step.
FWIW, I think the road to computing security probably is ill paved, difficult, unpleasant and involves shrinking attack surfaces by eliminating unneeded capabilities (e.g. #@$%^ Javascript) . It probably also requires shrinking the toolset to a bare minimum of proven libraries and protocols. That's not much fun, so it probably won't happen until we've exhausted the long list of entertaining but ineffective alternatives.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
"You nerds need to do security better or there's going to be hell to pay! No you can't have more time! No you can't change our processes! No we won't stop buying expensive, vulnerable software from Large Company X; do you have any idea what that contract is worth?! Fucking programmers, always complaining and never doing anything... when I was a developer on the mainframe we got stuff done, we didn't make all these excuses! By the way that software engineer position from that other nerd leaving will be given to another department."
... to define a "state of the art" regarding security. It should contain things like not mixing user input with SQL-queries, unless it goes through a whitelist of characters or is escaped by a proven to work function.
Essentially that "state of the art" should always be a bit above what idiots do in order to weed out idiots. Ideally it's defined in a way that that compilers can prove it working. (in the above case, user input strings and SQL-queries could have different types)
Slowly, but surely you'd raise the standards. This is essentially what happens with electronic safety. You have rules that are evidence based and, at least in part, blatantly obvious. Obviously those rules must be freely published.
Large corporations have armies of attorneys to cover their asses. Liability for software faults would benefit them because they have the resources to kill most any lawsuit against them. The opensource world, however, would whither and die because no weekend coder is going to risk everything because of a mistake. Expect large corporations to fully endorse software liability laws since it will remove the one kind of competition that they can't compete against on cost or functionality.
-- Will program for bandwidth
> did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress..."
Even the person writing this article defined "working software" as "doesn't matter how many security holes it has, how many bugs it has, how often it crashes as long as it kind of does".
The standards are so low, most developers think "working software" is the equivalent to a car that can safely roll downhill in a straight line on a smooth road but explodes if you touch the steering wheel or hit a bump.
Nobody would call something a "working car" just because it doesn't randomly explode on its own, but that's exactly how whoever wrote that quote defined "working software".
"Even with the move toward more agile development and DevOps, vulnerabilities continue to take off..."
Agile (and possibly to a much lesser extent DevOps) are a part of the problem, much more than a part of the solution, even when they are implemented properly. The key problem with Agile in security terms is that the concept is entirely based around the lack of up-front design. While we have to accept that up-front design isn't always possible (how many clients today are capable of formulating exactly what they want their software to do?), the lack of up front design does away with the ideal stage of the development process at which to anticipate, highlight and design around the most obvious of security vulnerabilities.
While sticking to good coding practices is necessary condition to achieve reasonably exploit-free software, it is not a sufficient condition, and without up-front understanding of the big picture, it is impossible to have good awareness of where integration weakness might lead to an exploitable flaw.
There is a very good reason why industries in which reliability is paramount (aerospace, automotive, medical) do not (and never will) use agile software development methodologies. Sole purpose of agile is to facilitate delivering a lot of features based on unknowable requirements quickly. For some environments, this is exactly what you need; for others it is suicidal.
As long as you have a time and cost driven development cycle with humans in the mix, there will be design flaws and problems. End of story.
Could have been the entry point for an insightful analysis. You didn't comment (or notice) that it's not a spurious correlation. The EULA was perfected by Microsoft so that liability was eliminated as a real concern for the developers.
I think the other major wrinkle perfected by MS was selling to the makers, not the actual users.
There are other possibilities, but because the rules of the game are biased for YUGE companies, not increasing consumer choice and freedom, we're screwed. I suppose Trump's voters hoped that he'll screw it up so hard that we'll get unscrewed, but that's not how entropy works.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Wait, you have requirements up front, you need to code to?
Any push to hold software engineers liable for security breaches will be by law makers in support of their lawyer friends. 80% of the world's lawyers are here in America and they are constantly salivating all over themselves like rabid dogs to find ways to sue people.
They take security more seriously
...in the herstory of Lifekind. Hold them liable will bankuprt them. And I believe Gates and his henceman belong in prison. That is a huge step toward justice.
If the brakes go out on your car and you crash into a tree, is person who made the brakes liable?
If the software 'goes out' on your car and you crash into a tree, is the person who made the software liable?
If you build a car with an easily hackable lock, and someone breaks in, are you liable for theft? (tennis ball trick)
if you build a car with an easily hackable electronic lock, and someone breaks in, are you liable for theft?
Do you see the parallels here? Just because someone can do something bad to your software doesn't mean it's always your fault. Even bridges (made by 'real' engineers) can be blown up. However, if your software malfunctions, then it's a different story. Also, some times if your software it 'too' soft, it's not really a liability issue, but it's a 'goodwill' and 'perceived quality' issue, and the financial damages won't be direct and punitive, but they'll still show up, so you'll want to fix it.
--Welcome to the Realm of the Hawke--
That is the way it works in all other areas. I would think it would have the same affect on software.
"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..."
I'm an Agile Coach at a Fortune 500. I've worked with dozens of coaches over my career. I have never met one who would tolerate a security vulnerability being in production any longer than absolutely necessary to fix it. "Working" includes utility (features, etc) and warranty (works as expected).
Agile and Devops won't do anything on their own to improve your security. I'd have a really hard time taking seriously anyone who thought they did. Also, the current state of the industry is not likely to change as long as there are intelligence agencies that feel that it's beneficial for software to not be secure. If you OS were truly secure, you could be that there'd be a constant push by those guys to introduce backdoors they could exploit.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
*needs citation Seriously, I'm a software developer and often have to be involved in a variety of security-related aspects of development and I've been doing it for twenty years. My anecdotal evidence is that security exploits are way *way* down in terms of risk and severity compared to when I entered the industry... I could be wrong (the plural of anecdote is not data) but it feels the opposite for me.
Security is a hardware problem. The general-purpose computers that host our software are inherently flawed (from a security standpoint) because they are general-purpose. Using software to fill the holes in the dike has never really been a solution to the problem; financial exigencies have led the current myth to propagate to the point that it is now considered fact.
I think the point was that there will be less security because Agile leads to software built in small pieces with no overarching holistic design, and DevOps leads to pushing insufficiently tested software straight to production.
> Even with the move toward more agile development and DevOps, vulnerabilities continue to take off. Why do people think Agile and DevOps is going to fix poor security implementation in software? This statement makes no sense.
"Good. Cheap. Fast. Pick any two."
Budget is visible. Conspicuous, even. Schedule, perhaps even more so. Quality -- especially in the parts that aren't visible, like maintainability and security -- often gets little attention.
Well, one aspect of security gets attention: when the access is too restrictive, and the software is unusable. Someone should be able to do something, but can't. The other aspect -- someone shouldn't be able to do something, but can -- isn't obvious. It may not get addressed by the time of the first demo. It may not get addressed by the time of initial delivery. It may not get addressed before the team is moved to a new project.
And who will know and care, and be in a position to do something about it?
There's no time like the present. Well, the past used to be.
Even with the move toward more agile development and DevOps, vulnerabilities continue to take off...
I am shocked that the latest industry buzzwords have failed to deliver improved security and reliability. Clearly we need more buzzwords to solve this problem.
Software engineers have largely failed at security
No, not really.
In the US, there are about 1.5 burglaries reported each year. Does this mean that builders have "largely failed at security"? No.
There is always a cost/benefit analysis when it comes to security. Sure, you can fortify your home with bullet-proof glass and unbreakable doors. But who can afford that? Instead, we make a calculated gamble and fortify our homes to a level of security that makes sense considering our budget, what we have to protect, and the crime rate. And no matter what you do, if somebody wants in badly enough, they will find a way.
Businesses make exactly the same calculated gamble with their electronic security. This is quite reasonable and appropriate. Sure, they get it wrong sometimes, but so do people who live in those less-than-fortress homes.
Instead of spending money making the software more secure, the liable companies spend money on insurance policies that reimburse them when they have to make a payment.
Never underestimate the power of stupid and the laws of unintended consequences.
I disagree !!!