Common DevSecOps Myths

We Cannot Introduce DevSecOps Because…

We need a special team dedicated to DevSecOps

“DevSecOps is all about creating empowered engineering teams taking ownership of how their product performs all the way to production, including security.”

We Cannot Introduce DevSecOps Because…

The security team still needs to do all security checks for us

By handing over security checks to other teams we introduce delays and time lag into our agile process, instead, we should ask the security team to codify their checks so we can build them into our development process automatically.

We Cannot Introduce DevSecOps Because…

We don’t have enough resources to do DevSecOps, just buy a tool that does it for us

DevSecOps is not about a capability, it is about a culture, buying a tool is not culture changing. Whilst tools are required to make DevSecOps possible these tools supplement the existing development process and help you deliver DevSecOps, if you have the correct culture in place.

We Cannot Introduce DevSecOps Because…

DevSecOps will just slow down our developers

DevSecOps is about empowering developers to ensure their product gets to production with appropriate security built-in. Traditional approaches to the security required testing after developers complete coding and before deployment to production.

Because this is so late in the lifecycle it takes longer to fix and retest software compared to identifying the issue at an earlier stage in the lifecycle, so DevSecOps can save time and increase developer speed.

We Cannot Introduce DevSecOps Because…

DevSecOps will result in our developers giving up control and won’t be able to plan

With DevSecOps developers gain control by running security checks at the best possible opportunity to help developers fix the issues quickly and easily. No longer are developers dependent on external teams, and gain control of the work and schedule.