What the DevSecOps 2018 Survey Results Really Mean for Developers and Security
The 2018 DevSecOps Community Report is out and for those following the growth of DevOps and its subsequent drive into the security community, under the moniker of DevSecOps, the results won’t be surprising. In fact, I set out to write some hot-takes from the report that would really dig into an existential evaluation of security in a DevOps world, but in the end, the takeaways from the report are far more pedestrian. Don’t read that as not meaningful — in fact I think the survey results are very meaningful and informative for our path forward.
Signal Sciences was excited to partner with Sonatype, Carnegie Mellon’s Software Engineering Institute, Contino, DZone, Ranger4, and SJ Technologies on this year’s report. DevOps and DevSecOps are near and dear to us, as our product grew out of Etsy’s adoption of DevOps practices and the need to security to keep up. Our unique hybrid of next-gen WAF and RASP is purposefully built by practitioners to handle the challenges from DevOps and cloud. Along with all the fine companies previously listed, we have a free PDF version of the report and we also recently did a Modern Security Series Episode with Derek Weeks talking about the survey. If you find the rest of this article interesting, you definitely want to check out both of those resources.
Now on to two not-so-hot-takes from the report!
#1: Developers are Human
We are human. As developers, we deal with large amounts of complexity. Most of the work of crafting software deals with abstracting this complexity so problems can be dealt with rationally and discretely. When we remember developers are humans dealing with complex systems, it should be no surprise that errors will be introduced — we often refer to these as bugs. From these bugs, a certain percentage are going to be security-related, and of those a portion will be exploitable. Because of code and library reuse — which are important to abstract the system complexity — these bugs can sometimes lead to very serious and very widespread problems.
Is this the fault of developers? No, this is an artifact of being human. To err is human.
The last decade of application security programs treated “developer security training” with high priority but this has proven to not work. Security assumed that developers could be fixed and trained to write secure code. You can’t train away our humanity.
As an industry, we have done this due to security’s disconnect with developers. This is an intractable problem that can’t be overcome with simply teaching someone how to write more secure code. Sure, you can bring awareness to common problems and you can lower the error rate, but they can’t be overcome solely with this method.
Security has failed the development teams in most organizations, not the other way around.
Most developers want to ‘do’ security. The 2018 DevSecOps Community Report was targeted mostly to developers and they reported they know security is important, however about half work in an organization where we don’t have enough time to spend on it.
Security is an organizational problem and developers need time to work on security issues. This means treating security just like any other bugs in the system. Spending time in design, committing to sprints where you focus on writing security tests, or adding in security instrumentation to provide visibility in production.
#2: The Application is the New Target
Remember when you could just isolate a network segment and go about your day with happiness? The good ole’ ‘DMZ all the things’ approach was great. However, in today’s world it isn’t a suitable defense because the perimeter is gone and has been replaced with software.
Justin Garrison, Sr. Systems Engineer at Disney Animation, nailed this poignantly in his tweet on the new Open Systems Interconnection (OSI) model. More understandable and also way easier to remember! Jokes aside, the way we do computing from cloud to microservices to serverless, has completely shifted the roots of software engineering.
The network we knew, no longer exists.
Even though this is true, in many organizations, network security solutions still account for the bulk of the the spending. This is a good example of the security industry not keeping up with the evolving attack surface. In the report, a pretty revealing statistic was found:
Since the application is the new entry point for attackers it must be considered in the way we approach defense. If you are not instrumenting your application with security in mind then you are missing visibility into understanding what attacks are actually happening and whether or not they are having success. At Signal Sciences, instrumenting the runtime of web applications for detection of security events is exactly what we do. We looked around and saw legacy web application firewalls (WAF) lacking in providing meaningful feedback to developers.
In fact, at Signal Sciences we see providing protection and feedback at runtime in the web application so critical that we built our company to focus on it. We built a product to protect against the full spectrum of threats your web applications and APIs actually face. We instrument for and defend against:
- Account Takeover
- Business Logic Attacks
- Application Abuse and Misuse
- Bots
- Application DoS
- OWASP Top 10 (XSS, SQLi, Command Exec, …)
We knew security had to change to provide feedback in terms that were meaningful to developers.
Thanks for reading. For more details, download the full 2018 DevSecOps Community report, and for an in-depth analysis of the data, watch our on-demand Modern Security Series webinar with Sonatype’s Derek Weeks.
