![\"\"](\"https:\/\/www.davincivirus.com\/wp-content\/uploads\/2018\/12\/chart-defectFixingCosts.jpg\")
[Source: https:\/\/www.synopsys.com\/blogs\/software-security\/cost-to-fix-bugs-during-each-sdlc-phase\/]<\/strong>
<\/figcaption><\/figure><\/div>\n\n\n\n
If we all know early involvement is pivotal, then why do we keep making the same mistakes? Two factors fuel this repetitiously bad behavior. First – large scale development efforts often grow from of niche prototypes. Engineers can easily become laser focused on functionality in a controlled environment when creating these initial prototypes. The resulting failure to account for external influencing factors makes the system ripe for exploitation by hackers.
<\/p>\n\n\n\n
The second (arguably more common) distractor from early prioritization of security stems from expense. Businesses investing in software are taking a taking a hefty monetary risk; investing resources with the hope of ultimately yielding profit. Some of these ventures will inevitably fail. It therefore takes a lot of gravitas for a company to risk capital early in the SDLC on features that won’t payoff until the system is fully matured and deployed.
<\/p>\n\n\n\n
Remediation – How do we change the tide?<\/h3>\n\n\n\n
Companies are justified in their reluctance to focus on security; namely because the manpower needed to solidify sound security processes is expensive. The good news is that this initial expense does dwindle over time. To achieve executive level buy-in, these initial costs must be seen as only short term expenditures with long term positive fiscal impacts. <\/p>\n\n\n\n
![\"\"](\"https:\/\/www.davincivirus.com\/wp-content\/uploads\/2018\/12\/SDLC-LevelOfEffort.jpg\")
<\/figure><\/div>\n\n\n\nBenefits from these investments quickly radiate to other development efforts within an organization. For example, a developer deeply ingrained in an SDLC that prioritizes security will learn how to design countermeasures in response to real world adviseral techniquest\/tactics. These defensive coding tactics are solidified early within one development effort and then seamlessly shifted to the next coding effort with no added expenditure. It’s also feasible to assume that these skills can permeate to other business units in the organization via information sharing activities; lunch \u2018n learns and all-hands training.
<\/p>\n\n\n\n
These benefits can however easily be lost if management falls into one of the common pitfalls. Well intentioned managers will sometimes spend vast sums of money to purchase \u201cstate of the art\u201d tools that bolster security; static\/dynamic code analysis tools alone can have starting costs exceeding $100k. Some of these tools are truly very useful! However, they can also encapsulate fiscal benefits within only a single SDLC. Over reliance upon these automated tools will likely also stifle sincere technical growth and comprehension among development teams.
<\/p>\n\n\n\n
Training your development staff is therefore exponentially more beneficial than purchasing tools. Automated tools are great – but only in the hands of a development staff with the technical maturity needed to wield them.
<\/p>\n\n\n\n
Bottom line – Companies need to invest in training. Developers and systems engineers are smart people diligently striving to create the best possible solution. Increasing their technical prowess will therefore influence their design decisions and daily development efforts.
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"