Subscribe
The way security and development teams think about and implement application security testing (AST) is changing. Historically, AST:
- Was owned by a dedicated application security team
- Had to be performed manually in a mid-to-late phase of the SDLC
- Required special tools that weren’t integrated into the development toolchain
- Reported long lists of vulnerabilities that required significant human triage
- Resulted in a “security gate” between development and production distribution
But today, AppSec is evolving into DevSecOps, where AST:
- Is owned jointly by development and security teams
- Happens incrementally with continuously testing throughout the SDLC
- Uses tools that are tightly integrated within the development toolchain
- Includes automated policy enforcement to focus human interventions on the highest-risk issues
- Provides “security guardrails” that help teams maximize BOTH security and velocity
Sounds great, right? Unfortunately, because AppSec is evolving, many teams quickly realize that it’s not as simple as integrating their existing tools into their CI/CD pipelines and DevOps workflows. The Modern Application Development Security survey and report published by Enterprise Strategy Group (ESG) highlights several challenges that can cause a DevSecOps program to stall. Here are three of the most common DevSecOps challenges teams face, and steps your team can take to mitigate them.
Three common DevSecOps challenges
1. The developer knowledge gap
With all the emphasis on cyber security and data protection over last decade, it might be reasonable to assume that secure code practices would be part of the standard computer science program curriculum. Unfortunately, that’s not the case. Forrester research has shown that even the top college computer science programs provide little, if any, application security instruction. Beyond that, many of your developers probably don’t have computer science degrees, making it even less likely that they have any formal security training.
This knowledge gap is a barrier to any attempt to shift security left, so your DevSecOps strategy needs to address it using a combination of:
Formal AppSec training
In-person or virtual classes are a good way to quickly raise overall security awareness and skills on your team.
Security champions
A select group of security-trained developers sit within a development team to mentor, advocate, and assist with secure development and mitigation activities.
eLearning
Self-paced and just-in-time training, often with microcourses, provide developers with the guidance they need to address a particular issue.
By combining these approaches, teams can effectively build security into their processes at the same time they are building it into their toolchains.
2. Lack of AppSec tool integration
Most DevOps toolchains are assembled of tools from multiple vendors. Teams pick the source code management (SCM), continuous integration (CI), build tools, binary repositories, test automation, and trouble ticketing systems that best suit their needs. Off-the-shelf integrations as well as APIs make it reasonably easy to combine everything into a well-oiled DevOps machine.
But teams often find that this mix-and-match approach is more difficult when they try to fold multiple AppSec tools into the mix. Security analysis generally requires a combination of static application security testing (SAST), software composition analysis (SCA), and some form of dynamic testing (dynamic application security testing, interactive application security testing, fuzzing, etc.) tools. Developers need a consolidated view of issues, but combining and reconciling findings from multiple vendors’ tools can be difficult. This challenge is the motivation behind the design of Code Sight™, an IDE plugin that brings results from SAST and SCA together directly at the developer desktop.
3. Pipeline friction and developer overload
Perhaps the biggest challenge developers face is the competing priorities of traditional AppSec tools and modern DevOps velocity. Many AppSec tools were designed around a model in which a member of the security team ran the tests, reviewed the often voluminous list of findings, and forwarded the list back to the development team for remediation. At best, this process might take several hours, but more often than not it would take days.
This lengthy, human-intensive model is incompatible with the high-velocity, integrated, and automated model of DevOps. And it makes clear that it’s not enough to build security into DevOps. You need to leverage AppSec tools that have DevOps built into them.
That means to be truly DevOps compatible, tests must be triggered by events in the SDLC (e.g., pull requests, commits, builds, etc.), run in the background without human intervention, and automatically apply security policies so developers can focus on the highest risk. An example of this type of solution is Black Duck Intelligent Security Scan GitHub Action. This integration allows teams to easily automate SAST and SCA within their GitHub workflows. Leveraging the Coverity® and Black Duck® scan engines and the intelligent test execution and reporting capabilities within the Black Duck Polaris™ Platform, Intelligent Security Scan addresses both the execution delays that can be caused by security testing and the vulnerabilities overload teams face with legacy tools.
Get started today
To learn more about how security and development teams are addressing these and other challenges on the path to DevSecOps, download the full ESG Modern Application Development Security report.