For the second year in a row, insecure software applications have been the main culprit of breaches, according to Verizon's 2019 Data Breach Investigations Report. But applying methods for shoring up your applications by stage and role will help.
Nearly every day a major security oversight by a large-scale consumer brand or critical enterprise comes to light. And thankfully, over time more and more executives are having to answer tough security questions from investors, investigators, reporters, customers, and regulators for security missteps.
While businesses are making progress in security, you have to take a hard look in the mirror to avoid falling victim to hackers. Security is complicated, and reasons for consumer privacy data breaches vary.
The truth is that organizations knowingly release insecure code all the time. It's time to stop blaming hackers and start focusing on companies that release insecure software.
But rethink the long game first. Properly secured applications may slow short-term gain, but they're a win in the long term, both for companies and society.
The problem at hand
In the technology world, speed to market is everything, and in the software development world, delivering the next release is everything. Developers are paid to deliver software on deadline and under budget.
In most cases, developers aren't rewarded for releasing secure software, and most don't understand security. Security is often applied to software at the end of the development lifecycle, after the app has been developed. Teams may detect a vulnerability, but then learn that it could take three or four months to create a fix. At that stage, companies are ready to release the software into the world and don’t want to delay. So they release it anyway, with fingers crossed, hoping that hackers won't find it.
A better approach is to apply security throughout the entire software development lifecycle. Companies must ensure that after dev teams implement the smallest piece of code, they test it for security, not just function.
And once it's integrated into a bigger build, they'll need to test it again—and each of their peers on the team should do the same thing. Then, when the app is ready to run, they need to test it again for security, not just ability. There should be hundreds of tests and fixes to vulnerabilities.
With this approach, teams go to deployment with a high assurance that each piece has been tested hundreds of times, so there should be very few vulnerabilities. That's how you ensure the security of the DevOps cycle.
Security by flavor and persona
Application security built into DevOps, or DevSecOps, is popular in theory, but overall it has been poorly adopted. There is a natural tendency for developers to resist security and let someone else handle it, since they are not security experts.
Poor adoption of DevSecOps often stems from the fact that software testing technologies are not designed well or customized for each software development and operations role. There are nuances in the skill sets required for each persona within every stage of the software development lifecycle. Personas include programmers, build engineers, and pre- and post-deployment specialists.
And because of the persona and related issues, security testing cannot be a one-size-fits-all approach.
There are three main components to ensuring comprehensive security testing:
Static application security testing (SAST), which analyzes application code and detects vulnerabilities.
Dynamic application security testing (DAST), which analyzes applications and detects vulnerabilities at run time. It launches simulated attacks and analyzes the reaction to determine if there is a vulnerability.
Software composition analysis (SCA), which analyzes applications for third parties for open-source software. It detects illegal, dangerous, or outdated code.
Testing with the above measures is comprehensive and ensures secure software. But to gain better adoption, you must offer testing technologies in flavors that are tailored to specific developer and operations personas at different points in the application development lifecycle. That will allow methodologies and tools to be easily adopted and integrated into various parts of the environment.
These flavors and variations of the SAST, DAST, and SCA technologies should each be customized specifically to the abilities of each of the professionals who touch the code at some point along the pipeline.
Security: Just do it
By offering more options and catering security technologies to each part of the software development lifecycle and the individual roles involved, you can make it easier to secure software.
You can also decrease the number of software vulnerabilities and data breaches we see in the world today. And by shoring up security measures within software development, executives can gain peace of mind that they will be much less likely to have to answer to investigators, upset customers, and irate shareholders.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
