Gartner’s 12 Things to Get Right for Successful DevSecOps
By 2023, more than 70% of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages, which is a significant increase from fewer than 30% in 2019.
Automated security vulnerability and configuration scanning are amongst the DevSecOps best practices that Gartner addresses in their 12 Things to Get Right for Successful DevSecOps with insightful analysis.
This Gartner Report is a veritable DevSecOps guide that addresses the following topics:
- Adapt your security testing tools and processes to the developers
- Quit trying to eliminate every vulnerability during development
- Focus first on identifying and removing known open-source vulnerabilities
- Don’t expect to use traditional DAST/SAST without having to make changes
- Train developers on secure coding, but don’t expect them to be security experts
- Adopt a security champion model and implement a simple security requirements gathering tool
- Secure and apply operational discipline to automation scripts and infrastructure security posture
- Implement stronger version control on all code and components
- Apply secrets management
- Adopt an immutable infrastructure mindset
- Rethink how service delivery incidents are handled
- Use dynamic access provisioning for developers in DevSecOps
Here are some notable highlights from the report:
Focus First on Identifying and Removing Known Open Source Vulnerabilities
Modern software is often assembled, not developed. Developers make heavy use of prebuilt components, libraries, containers and frameworks (such as Apache Struts and Swing) from publicly available sources and repositories (such as GitHub, SourceForge, Maven and Docker Hub). Custom code often represents a minority percentage of the code in a modern application.
The increasing reliance on open source software (OSS) is driving changes to security scanning and large enterprises implementing pre-approved component libraries for reuse by DevOps teams across their organization. Gartner’s analysis cites that the actual code a developer writes is less than 10% of the final application.
When you make such a shift to security scanning of component libraries for vulnerabilities known configuration issues you save time and preserve team productivity.
Implement Strong Version Control on All Code and Components
Being able to tell the difference between what code was used (versus what code is actually exercised in production) is essential. It becomes a way to harden the application in future iterations by removing unused components, or to lower the risk if these components are later found to be vulnerable, but aren’t actually used.
Having mature source code version control throughout your DevSecOps lifecycle is a necessity as you work to increase your delivery velocity. Your enterprise needs to support version control using distributed version control systems (DVCS) and application lifecycle management (ALM) tools.
Use Dynamic Access Provisioning for Developers in DevSecOps
Although most DevOps infrastructure tools provide at least basic role-based access control (RBAC) — which should be leveraged as a minimum baseline control — the rapidly changing DevOps environment and blurring of functional borders can challenge static access controls. Because of this, consider the use of dynamic access provisioning, such as zero trust network access (ZTNA) control for developers.
The recent Cybersecurity Executive Order and fallout from the SolarWinds and Codecov hacks are going to fundamentally change how enterprises secure their development tools and infrastructure. Chief Information Security Officers (CISOs) and security teams will be looking to zero trust to shore up their security of their software supply chains, DevSecOps tool chains, and other development infrastructure.
Adopt an Immutable Infrastructure Mindset
For modern, microservices-based applications that are updated frequently, there is an operationally more secure way to maintain these applications. Where possible, no person should be allowed to make changes directly on production systems. The infrastructure is considered “immutable.”
Using containers and microservices to improve software delivery velocity means you need to take extra steps to protect your production environment. When you make changes and updates to software, that work should now take place in your development environment, not in production. You can then deploy changes and updates from a secure repository into your development environment via automated tools in your DevOps toolchain.
