Home / DSO / Gartner’s 12 Things for DevSecOps

Gartner’s 12 Things to Get Right for Successful DevSecOps

Updated on February 12, 2024
By: Anchore
Anchore Graphics
Navigate To
Close Table of Contents
Table of Contents

    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:

    1. Adapt your security testing tools and processes to the developers
    2. Quit trying to eliminate every vulnerability during development
    3. Focus first on identifying and removing known open-source vulnerabilities
    4. Don’t expect to use traditional DAST/SAST without having to make changes
    5. Train developers on secure coding, but don’t expect them to be security experts
    6. Adopt a security champion model and implement a simple security requirements gathering tool
    7. Secure and apply operational discipline to automation scripts and infrastructure security posture
    8. Implement stronger version control on all code and components
    9. Apply secrets management
    10. Adopt an immutable infrastructure mindset
    11. Rethink how service delivery incidents are handled
    12. 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.

    Speak with our security experts

    Learn how Anchore’s SBOM-powered platform can help secure your software supply chain.