Show Menu

Gartner Guide to Successful DevSecOps Cheat Sheet (DRAFT) by [deleted]

Gartner Guide to Successful DevSecOps

This is a draft cheat sheet. It is a work in progress and is not finished yet.


The analysts have taken lessons learned from the organi­zation and its clients, and released 10 steps they believes will set businesses on a successful DevSecOps path.

1. Adapt your security testing tools

“Adapt your security testing tools and processes to the develo­pers, not the other way around:”
According to the analysts, the Sec in DevSecOps should be silent. That means the security team needs to change their processes and tools to be integrated into DevOps, instead of trying to enforce their old processes be adopted.

2. Quit trying to eliminate all vulner­abi­lities

“Quit trying to eliminate all vulner­abi­lities during develo­pment.” “Perfect security is imposs­ible. Zero risk is imposs­ible. We must bring continuous risk- and trust-­based assessment and priori­tiz­ation of applic­ation vulner­abi­lities to DevSec­Ops,” Head and MacDonald wrote in their report. DevSecOps should be thought of as a continuous improv­ement process, meaning security can go beyond develo­pment and can be searching and protecting against vulner­abi­lities even after services are deployed into produc­tion.

3. Focus first on identi­fying and removing

“Focus first on identi­fying and removing the known critical vulner­abi­lit­ies.”
Instead of wasting time trying to break a system, find focus on known security issues from pre built compon­ents, libraries, containers and framew­orks; and protect against those before they are put into produc­tion.

4. Don’t expect to use tradit­ional DAST/SAST

“Don’t expect to use tradit­ional DAST/SAST without changes.”
Scan custom code for unknown vulner­abi­lities by integr­ating testing into the IDE, providing autonomous scans that don’t require a security expert, reducing false positives, and delivering results into a bug tracking system or develo­pment dashboard

5. Train all developers on the basics

“Train all developers on the basics of secure coding, but don’t expect them to become security experts.”
Training all developers on the basis of security issues will help prevent them from creating harmful scenarios. Developers should be expected to know simple threat modeling scenarios, how to think like a hacker, and know not to put secrets like crypto­graphic keys and passwords into the code, according to Head.

6. Adopt a security champion model

“Adopt a security champion model and implement a simple security requir­ements gathering tool.”
A security champion is someone who can effect­ively lead the security community of practice, stay up to date with maturity issues, and evange­lize, commun­icate and market what to do with security and how to adapt.

7. Eliminate using known vulnerable components

“Eliminate the use of known vulnerable components at the source.”
“As previously stated, most risk in modern applic­ation assembly comes from the use of known vulnerable compon­ents, libraries and framew­orks. Rather than wait until an applic­ation is assembled to scan and identify these known vulner­abi­lities, why not address this issue at its source by warning developers not to download and use these known vulnerable compon­ents,” Head and MacDonald wrote.

8. Secure and apply operat­ional discipline to

“Secure and apply operat­ional discipline to automation scripts.”
“Treat automation code, scripts, recipes, formation scripts and other such infras­tru­cture and platform artifacts as valuable source code with specific additional risk. Therefore, use source­-co­de-type controls including audit, protec­tion, digital signat­ures, change control and version control to protect all such infras­tru­cture and platform artifa­cts,” according to the report.

9. Implement strong version control

“Implement strong version control on all code and compon­ents.”
Be able to capture every change from what was changed, when the change happened and who made the change

10. Adopt an immutable infras­tru­cture

“Adopt an immutable infras­tru­cture mindset.“ **
Teams should work towards a place where all the infras­tru­cture is only updated by the tools. This is a sign that the team is maturing, and it provides a more secure way to maintain applic­ations, according to Head.