The Rise of Developer-First Security Tooling
Engineers seldom embrace security in the software development process for one reason: They don’t think it’s their job. Neither the tangible benefits of addressing security concerns nor the consequences of ignoring them are typically apparent to engineers unless they are working for a financial institution or health care organization. Additionally, the process of addressing these concerns can be tedious and demotivating.
Despite often being an engineering afterthought, application security (AppSec) is absolutely critical to the success of software companies—particularly in a world with no shortage of ransomware attacks and a growing base of open source code.
This article aims to contextualize AppSec’s place within engineering organizations and provide guidance on how developers might embrace this growing discipline.
What is Application Security?
Before we delve into history, let’s define what it means and what it encompasses. VMware defines AppSec as:
“The process of developing, adding, and testing security features within applications to prevent security vulnerabilities against threats such as unauthorized access and modification.”
Security teams are typically tasked with answering questions about GDPR compliance, third-party vulnerabilities, penetration testing and more. While there are important nuances to be found in the definition of AppSec, the focus of this piece will remain on how security is surfaced and addressed organizationally.
A Brief History
Historically, AppSec concerns at software companies were addressed by teams other than those responsible for actually writing the code itself. In other words, it was common to see a developer ship code to a security team that would then review that code, identify problems and request that the developer make changes.
Unfortunately, this siloed feedback loop was problematic; it incentivized a culture where the engineer didn’t internalize AppSec concerns as a priority during the development process. Instead, it created a culture where AppSec was an outsourced, post-development problem that hindered velocity and innovation.
As GitLab puts it,
“Security was not just an afterthought; it was a top-down experience delivered by people who were far removed from the challenges of development.”
The Rise of DevSecOps
Over the past few years, the DevSecOps approach has gained momentum to solve this very problem. At the intersection of development, security and operations, the DevSecOps model is a profoundly collaborative one that most notably shifts security to the left so that concerns are tested, prioritized and addressed by developers during the code commit and deployment phase as opposed to the post-commit monitoring phase on the right. This breaks the silos described above and makes it more likely that bugs and vulnerabilities will be surfaced much earlier.
This shift challenges AppSec teams to better support developers and simultaneously challenges security tools to more natively integrate into developer coding environments. The idea is that if you surface security issues in an automated way in the same place developers write code, they’ll be more inclined to know about them and fix the issues.
How to Encourage Security-Driven Development
How, then, might teams encourage engineers to value security and incorporate it into their day-to-day responsibilities? There are dozens of solutions to implement, and it’s important to remember that the underlying principle behind each of them should be what Guy Podjarny articulated well:
“To get developers to embrace a security solution, it must look like a developer tool, not a security one.”
Some ways to achieve this goal can include:
- Setting up automated vulnerability scanning for all of your GitHub repositories and Docker images. Develop a policy for how you prioritize vulnerabilities.
- Assign the owner of each microservice to be responsible for addressing security vulnerabilities within it.
- Set up a security@ email address that allows your customers to raise concerns. Create a process to make sure these concerns are responded to.
- Align your development team more closely to your security team so that they are responsible for making security an efficient and streamlined process.
- Stay up-to-date on the latest stable versions of third-party software.
Beyond Tooling
It’s hard for anyone to argue that security is not essential. There’s typically alignment across teams on that principle, and the crux of the work becomes more about bringing security-adjacent tooling and processes closer to developers, SREs and DevSecOps teams. Your business will need it sooner or later, but if you’re not ready for investment in tooling and process, just focusing on instilling the value of the security framework to your developers is an excellent place to start.
Paola Peraza is a lead technical writer at Cortex and co-authored this article.
