SoylentNews is people
SoylentNews
Submitted via IRC for TheMightyBuzzard
The financial benefits of finding and fixing defects throughout the software development life cycle (SDLC), starting at the very beginning, ought to make doing it a no-brainer. It is both easier and cheaper. One should build secure software from the ground up.
[...] The findings of a 2016 Forrester Research study call to mind an ancient proverb: A stitch in time saves nine. Or, in the case of software development, fixing defects early in the SDLC could reduce remediation costs by a factor of anywhere from 5 to 15.
The study set a baseline example of 5 hours of work to fix a defect in the coding/development stage. Finding and fixing that same defect in the final testing phase would take 5–7 times longer. And waiting until after the product was on the market to discover and fix the same defect would take even longer and cost 10–15 times more.
That doesn't include the potential cost of damages from a bad guy discovering the defect first and exploiting it to attack users.
And to the frequently stated worry that ongoing security testing creates intolerable delays in time to market, Forrester found the opposite: that it cuts time to market by 25%.
Hat tip to the old slashcode crew who left us some very good tools for doing exactly this.
Source: https://www.helpnetsecurity.com/2018/05/08/build-secure-software/
(Score: 4, Insightful) by bzipitidoo on Wednesday May 09 2018, @12:33AM (1 child)
And they were wrong then, and still wrong today.
The problem is the focus. They're raving about security, as if a major bug that doesn't impact security is not important, while a trivial bug that does impact security ever so slightly is a show stopper.
They even use a car analogy, and they're wrong about that too! They state that during manufacturing, if cars are coming off the line with dented doors, it is best to stop the line and fix the problem, rather than deal with the dented doors later. No, it is NOT best to stop the line! If you stop the line, you've got a factory full of workers who must still be paid even though they are all idle, and no product being made. The line is a high availability item, like a major website. Never, ever take down your company website by choice. Keep that line going while the problem is fixed, and fix the defective doors as they come off the line.
They're all disappointed that their fearmongering isn't selling businesses on their message. Remember how it used to be and still is with passwords? You know, supposed to memorize them and never write them down, change them every month, use one or more each of capitals, lower case, special characters, and numeric digits, make them at least 8 characters long, use a totally different password for each different account, etc. Took decades before they threw in the towel on their extreme password protocol recommendations and admitted they needed to be more practical.
(Score: 3, Interesting) by Anonymous Coward on Wednesday May 09 2018, @11:45AM
No, you're wrong. They're going to have to stop the line to fix the issue at some point, so the sooner you fix it the fewer repairs you'll need to make later. Paying 100 low wage factory workers 2 hours while the issue is being fixed after the first dent is discovered is far cheaper than paying 2000 more expensive repair men 3 hours to fix 2000 cars and the marketing to get people to bring in the cars, and developing the training on how to fix the doors, and the marketing that their products don't suck even though they shipped with defective products.
If you're writing software, it is far, far easier and cheaper to wrap your received input in a sanitize call as you're writing the input handler than it is to get a report that someone used an SQL injection attack to delete the database. Your business is down, you need to restore from backups, you have PR issues, IT is being paid overtime, you need to rummage through the logs and code to find the bug, then you need to figure out the fix, then test to make sure it doesn't break anything, then release the new software. If the bug was caught as it was being written, then only one person spends a small amount of time fixing it. If it's found during code review then only a few people have spent time on it. As a general rule, the longer it takes to discover the bug the more expensive it is to fix it. Anything found after testing causes the software to be retested. Anything after release or deployment will need another release. Etc... As a general rule it's completely correct.