You may have seen, especially on social media, many “expert” opinions on cybersecurity that freely mix and match seemingly unrelated terms. In the field of application security specifically, you will see people asking about things like the difference between AppSec and DevSecOps—a really strange thing to ask until you realize that in some contexts, people can (and do) use the two interchangeably. The recent wave of AI-generated content only adds to the confusion and noise. So, at the risk of stating the obvious in places, let’s clear up the similarities, differences, and overlaps between AppSec and DevSecOps and end this silliness once and for all.
Two terms, two clear meanings… Right?
At first glance, the two terms are pretty clear and distinct. AppSec is just shorthand for application security—the area of cybersecurity concerned with building secure software, running it without introducing vulnerabilities, and protecting it from attacks. There’s a lot to unpack in this definition. For a start, “software” is a very wide term, and securing that software can mean analyzing code, testing running applications, protecting deployments, and more, all with a bewildering array of methodologies and tools available. In the tech industry, AppSec is often used in the narrower sense of finding and eliminating vulnerabilities in web applications.
DevSecOps is a buzzy term used to describe the workflow and culture of incorporating security into DevOps, which is a popular methodology that combines application development and operations into one integrated, highly automated, and continuous process. DevSecOps (or SecDevOps, depending on who you ask) came about because DevOps teams were far outpacing traditional security testing and remediation methods. To minimize security risks without holding back rapid software development and delivery, automated security tools and workflows had to be added to the pipeline—and “Sec” added to “DevOps.”
With those working definitions in place, let’s see how the two overlap and why they can get confusing.
Different approaches to security practices
You could say that DevSecOps is a systematic way of adding application security to the software development lifecycle, suggesting the suspiciously neat statement that DevOps + AppSec = DevSecOps. So does this mean that when DevOps teams are told to shift left and generally start doing security in their development cycle, they are on their way to becoming DevSecOps teams? Looking only at the development process, are AppSec and DevSecOps basically equivalent? In fact, does this formula even make sense? Or are we comparing apples to oranges?
More than anything else, DevSecOps is a culture rather than any specific methodology, with a focus on embedding a security mindset into the DevOps process. It’s really about making security a routine and non-negotiable aspect of software quality alongside functionality, performance, maintainability, etc. However, because DevOps pipelines are highly automated, the cultural shift to DevSecOps needs to be backed by equally automated (yet still accurate) security tooling. This is where discussions about AppSec tools and DevSecOps tools start overlapping.
The many ways of putting the “AppSec” into “DevSecOps”
The idea of making security a part of software quality looks great on paper, but development teams have traditionally had a thorny relationship with security. Especially after the widespread move to agile DevOps with its relentless sprint-based cycles of frequent smaller releases, having the security team (or external penetration test) come back to you weeks later with a security issue to fix is frustrating and inefficient, putting a metaphorical stick in their continuous integration and delivery wheels. So when people talk about DevSecOps tools, they usually mean security tools that can operate in the DevOps automation machinery without breaking everyone’s flow.
There are really three main ways to do automated and continuous application security testing in the DevOps process: two static (SAST and SCA) and one dynamic (DAST). Each comes with its own advantages and limitations, so the application security best practice is to use all three at different stages of the process that play to their strengths. We’ve covered the different types of AST many times on the blog, so here’s just a quick refresher.
Software composition analysis (SCA): Know your bricks
SCA addresses the problem of widespread reliance on open-source software components. With the breakneck pace of development, having this scaffolding and these prefabricated parts is a practical necessity, helping developers to standardize and also focus on custom business logic rather than recreating common routines.
Embedding SCA checks into the pipeline is a common practice that helps to identify and update (or avoid) known vulnerable components. Some SCA tools can also check license compliance and scan code bases for open-source code snippets. The downside is that SCA can be noisy, generating many warnings that don’t apply in a specific context and need to be filtered out or simply ignored by developers.
Static application security testing (SAST): Is that code safe?
The most common method of adding security checks to development is to scan the code for vulnerabilities as soon as it is written, in the same way as linters and other dev tools are run to find coding errors. SAST tools can run directly in the IDE or as a separate analysis process, with the advantage that they integrate readily into the SDLC and can be used at any stage of development, even on code that is not yet runnable or won’t be accessed by the running application.
As with SCA, the biggest downside of SAST is the high level of noise in the form of false positives or correct but irrelevant warnings. SAST tools are also programming language-specific and limited in scope to code you actually have in active development. And because this is static analysis, it cannot confirm if a reported issue will end up being exploitable and won’t find runtime vulnerabilities resulting from misconfigurations or external dependencies.
Dynamic application security testing (DAST): From the outside looking in
DAST tools are a must-have for DevSecOps, having expanded from their traditional role as external vulnerability scanners to also provide dynamic testing during QA and even at earlier build stages. DAST can scan any runnable web app and API (even a prototype) for exploitable vulnerabilities, regardless of the underlying technologies and components. Good quality tools have very low false positive rates and require far less tweaking and tuning than SAST to get usable results. They also integrate directly with popular issue trackers and collaboration tools to send security issues directly to developers, along with remediation guidance.
The flip side of dynamically testing entire running applications from the outside is that any code that isn’t loaded won’t be tested. DAST also cannot test purely static code, like an isolated snippet or module, and often provides slightly less accurate issue locations than the specific line of code that SAST can indicate. And perhaps more than with any other tool type, the quality and usability of DAST results can vary greatly depending on the specific tool and its technical maturity—a good quality DAST can become the cornerstone of your DevSecOps process, while a subpar DAST will quickly fall into disuse for creating more problems than it solves.
A continuous security process by any other name smells just as sweet
AppSec and DevSecOps are closely related terms that overlap in many places. One crucial difference is that every organization that runs applications needs to have and enforce an AppSec program, even if it’s not building its own software. Being a software development process, DevSecOps is only relevant when you’re building and running your own applications. Then again, any sizable modern organization builds at least some of its software in-house… And there goes another overlap.
The main point is that application security needs to be an embedded and shared responsibility in any organization that builds software, and all the different buzzwords you will see boil down to having a routine and continuous software security process. This starts with secure coding and design, continues with automated testing for security vulnerabilities, and ends with the operational side of maintaining a good security posture in production. The name doesn’t matter—as long as you’re using effective tools and processes to keep your security risk in check.
