Developers have always been overworked. They face a constant flow of feature-focused work from the business and need to balance that with work involving performance, quality and reliability, and technical debt. While DevOps and highly automated CI/CD pipelines have made developers more productive by removing low-value non-development tasks, it has actually made the pressure to deliver even greater. According to the 2018 DORA Accelerate: State of DevOps report, high-performing DevOps teams have 46X more frequent code deploys than low-performing teams. That’s a lot more work for developers — more high-impact work, happily, but more work nonetheless.
Now, along comes the security industry telling these organizations that they need to “shift security left” and embrace DevSecOps. This means moving responsibility for security earlier in the development process and building it into the DevOps approach to software development and delivery. It sounds great in principle, but DevSecOps conversations rarely start with a recommendation to hire additional software engineers. So how are already overworked developers meant to take on the burden of security in addition to features, quality, performance, and tech-debt? It’s not that they don’t care; it’s just a matter of time. In a recent Threat Stack report, 44% of DevOps professionals said they would have to rely on someone else for security-related issues. And even if they find some time to dedicate to security, many developers lack the expertise to know how to improve the security of their applications. A 2016 study found that out of the top 10 computer science programs in the U.S., not a single program requires a cybersecurity course to graduate.
For many developers, “shift left” sounds a lot like “dump more work on us.”
Security teams aren’t unsympathetic. They’ve felt the pinch of too much software with too little security coverage for years. Many organizations lack a dedicated application security team, and those that have one are stretched ridiculously thin. Companies with a formal software security team, according to the most recent BSIMM survey, need to get by with an average of only one security team member for every 75 developers! You can be sure that the single security pro doesn’t want to be the one standing in the way of 75 developers delivering the customer value that was promised to the business! At this year’s RSA conference, 40% of respondents surveyed said the most significant roadblock to implementing application security programs was their impact on agility and speed of application development or deployment.
So what’s the solution? Security can’t simply be shifted onto the backlog of unprepared and overworked development teams, yet AppSec teams lack the personpower and access to the SDLC to address application risk early in the process.
We recently introduced Threat Stack Application Security Monitoring (aka AppSec Monitoring) to our full-stack cloud security observability solution as part of the Threat Stack Cloud Security Platform® (at no additional cost). AppSec Monitoring was designed to address these DevSecOps challenges head-on. We believe that application security in a DevOps world is made possible when we meet three objectives:
Developers add AppSec Monitoring to their application when development first starts by adding it as a dependency, just like any other third-party component. A one-line initialization function is added to the application, and that’s all that’s required to get started. There is no need to install any servers or additional tools, or to write or manage tests. AppSec Monitoring works silently in the background every time the application runs, so the developer can go about the work of developing without slowing down. From that point on through the remainder of the SDLC, AppSec Monitoring continues to run inside the application to help the team protect and reduce risk.
(A single-line code addition adds Threat Stack AppSec Monitoring to any Node.js application.)
Each time the application runs — whether on a developer’s local machine, in the build environment, in test, or in production — Threat Stack analyses the application to identify potential risk. This could be risk from using weak cryptography, unsafe method invocations, improper database configurations, or even the use of known vulnerable third-party components. Security professionals on the team (or the developers themselves) can review the findings to decide which should be addressed first — and Threat Stack helps by categorizing them by risk level.
Risk can only be reduced when developers have the information they need to address it. AppSec Monitoring provides this in the form of e-Learning content that explains the risk to developers in their own language, with code samples and links to further external learning content. It also helps developers pinpoint the exact location of the risk in their application — highlighting the method and module name, file name, and even line number — whether the risk is in their own native code or in a third-party component. Developers gain an understanding of the issue and have the context to find and fix it in their code, all in the earliest stages of development when it’s easier and cheaper to fix.
With these three benefits — early risk identification, help with prioritization, and context and training to address the risks — application security isn’t shifted left: It’s stretched left. It’s embedded in the process and facilitates cooperation between Development and Security teams.
Even with the best development time security efforts, malicious actors may still try to attack an application in production. If they do, Threat Stack Application Security Monitoring can also detect and block those attacks in real time. We’ll cover exactly how that works in the next post.
To learn more about Threat Stack’s Application Security Monitoring, which is available as part of the Threat Stack Cloud Security Platform at no extra cost, sign up for a demo. Our Security experts will be pleased to discuss your specific security and compliance requirements.