Over the last couple of years, DevSecOps has become the latest buzzword. The idea behind the concept is that it makes everyone accountable for security, and to implement security decisions and actions at the same scale and speed as DevOps.
Organizations with a DevOps framework should be looking at how they can shift towards a DevSecOps mindset, bringing individuals across all technology disciplines to a higher level of security proficiency. The goal is to ensure security is built-in to application development rather than bolted on afterward. However, there is often a perception that adding security testing into the mix will negatively impact DevOps speed. But by deploying AppSec tools that integrate security with every stage of the SDLC, businesses can reduce the cost of compliance and deliver secure software faster.
So how can organizations go about making this shift and identifying the technical tools to support it? The first step is to determine where they sit on the DevSecOps maturity scale because despite the generally accepted definition of DevSecOps, in practice, it is a concept that means different things to different organizations based on their software development and security maturity. We typically see four levels:
Level One: Checking the Box
Organizations often have the mindset to focus mainly on meeting compliance requirements. However, simply answering yes or no questions in a security audit doesn’t necessarily make the business any more secure. Therefore, organizations should aim to mature onto other levels.
This level of DevSecOps maturity is typical of companies that wait to perform security assessments until just before deployment when there’s often no time or budget remaining at this point to address high-risk vulnerabilities adequately. These tests may or may not include automated vulnerability scanning. The high-risk vulnerabilities will often be documented in the development’s team issue tracker, which may not allow for complete organizational visibility. As a result, vulnerabilities may be silently available for exploitation with no clear plan for remediation.
Level Two: Situational Security Awareness
The next level of maturity sees organizations start to gain more situational awareness. They begin to identify the risks living inside their applications, not about fixing code but understanding the risks. So, rather than scanning for compliance, they know that there are risks worth addressing within applications.
Teams may identify vulnerabilities through manual testing, code reviews, or even automated vulnerability scanning and then deep dive into to assess risk with greater accuracy based on proven or perceived exploitability. The organization will typically document these high-risk issues and implement a compensating control as a permitted policy exception with a future deadline for proper remediation.
These quasi-effective compensating controls may help organizations make software changes, but those changes would properly remediate the discovered risks. Instead, the stakeholders and development team involved in the original release may be completely different as future deadlines approach. As a result, historical vulnerability documentation sits there without a clear path for resolution.
Level Three: Remediate Everything
If organizations tried to remediate every vulnerability, they would experience a massive slowdown in DevOps. This slowdown results from the heavy lift of combing through historical code and perhaps not using AppSec solutions that help developers prioritize fixes.
Instead, organizations typically develop an understanding of how to manage that risk by designing processes to support policies that match their compliance requirements and risk appetite. F For example, many organizations have the approach to remediate high-severity and OWASP Top 10 vulnerabilities within a specified timeframe.
A higher security posture or fallout from a recently exploited vulnerability may lead to procuring new automated vulnerability scanning tools. Lack of engineering in integrating these tools into developers’ existing tools leads to a complete re-tooling of the organization’s software development practices. Along with the new tools, a higher level of scrutiny on detected results may lead non-technical managers to impose strict policies for deploying detected vulnerabilities that may be incompatible with business goals and, at times, technically infeasible to enforce.
Managers may incorrectly interpret the slowdown as developers being unwilling to adopt new tools and practices. The reality is that slowness may be due to a combination of several factors:
- A subset of the organization’s developers may need the training to understand secure coding concepts, including how vulnerabilities manifest and are exploited.
- Developers are having difficulty in locating and consuming vulnerability results out-of-band of their existing development tools and workflows.
- Developers being overwhelmed with the frequency of reviewing vulnerability data produced from automated scanning tools when scans frequency is not tied appropriately to the development process.
Level Four: The Holy Grail of AppSec
At the highest level of code security maturity, organizations focus on preventing the introduction of new vulnerabilities and effectively managing technical debt by integrating continuous AppSec testing without stopping or slowing new development. Training developers to write secure code and remediate vulnerabilities and procuring developer-centric solutions helps further accelerate DevSecOps. Plus, if solutions support the developer with fine-tuned results and features like best-fix-location, remediation suggestions, and multi-scan engine results correlation, they’re further supported in making fixes faster.
A higher security posture or fallout from a recently exploited vulnerability may lead to procuring new automated vulnerability scanning tools. Management understands that any attempt to “boil the ocean” by stopping all work while identifying, accurately assessing, and fixing all high-priority vulnerabilities is not infeasible. Instead, they:
- Identify the highest-profile applications and focus on identifying high-risk vulnerabilities in those applications.
- Focus application security training on teams that maintain these high-profile applications.
- Scale the training effectiveness by involving AppSec experts in the development teams’ vulnerability triage and remediation efforts.
- Engineer the integration of vulnerability result consumption into the developers’ tools and workflows.
How to Develop Your Organization’s AppSec Maturity
While seemingly simple in principle, how do teams move through the various maturity levels without being overwhelmed by thousands of new alerts while optimizing their AppSec program and tools? There is no one-size-fits-all approach, but here are some practical best practices our Professional Services teams have seen or put into practice.
Some organizations run baseline scans on their existing applications and put findings into technical debt backlogs, which they gradually reduce over time. Other organizations set a policy that any new releases won’t introduce new vulnerabilities, ensuring compliance with automated AppSec testing kicking off directly from their DevOps environments. Checkmarx’s Application Security Platform and AppSec Maturity Services help both DevOps and AppSec teams understand and assess where they are today and what they need to do to mature their environment.
Adoption Requires Top-Down Support and Bottom-Up Enablement
Most importantly, DevSecOps needs top-down executive directives, otherwise prioritizing AppSec won’t get buy-in from the wider team. Senior management support and exemplary technical leadership are critical because changing an existing DevOps approach to integrate security includes a degree of disruption as teams adjust to the new process. Managers might purchase AppSec tools, but individuals will have differing levels of experience in implementing and using them. While developers interested in security may embrace the new process, others will be reticent about what they see as an unhelpful change in their preferred methodology. Consequently, adoption is patchy, and the tools don’t deliver ROI. Even though developers want to write secure code, their priority is to ship feature sets and functionality quickly. Hence, leadership needs to support the technical adoption of tools through procuring developer-centric products and proper training.
Where does your organization land? In level one, two, three, or four?
Download Our Ultimate Guide to SCA Here
