Blinded by the Tooling
The success of DevSecOps is not measured by the lines of code you can scan.
DevSecOps (also referred to as shifting-left) is the practice of training and empowering the engineering team to identify and fix security defects earlier in the development process. Typically security assessments (penetration tests) are performed just before a code release is due to be deployed into production. This is not very agile and any serious issues found can disrupt delivery roadmaps. By adopting DevSecOps fewer issues are expected to be found during regular security assessments, meaning any remedial work should be easier and cheaper to implement. If your organisation is pursuing DevSecOps, great stuff.
But it’s so much more than just finding and fixing issues early on. DevSecOps is an attitude, it’s about being proactive and passionate about not introducing security issues in the first place. It’s about engineering teams taking ownership and responsibility for the security of their products and services. Security is a Non-Functional Requirement (NFR) but it’s also an engineering quality. A secure product, engineered well will be much easier to maintain and add new functionality but it will also be robust so it doesn’t become a liability to your organisation or customers. DevSecOps is about changing the culture.
DevSecOps is not a replacement for regular penetration testing which will enable security professionals to identify security issues that may not be picked up by the engineering team.
I’ve been working with a large financial organisation but they have become so focused on providing automated security testing tooling to the developers, that they seem to have missed the most important point: actually fixing the issues.
Unless you are fixing your security issues you aren’t doing DevSecOps properly.
Automated security testing tools are great at helping to find and triage the problems, but the culture needs transformation in order to treat them like any regular NFR defect and resolve them. Otherwise you may end up in a situation where you have a pile of defects that nobody is actually fixing.
Worse still is measuring the success of the programme by the number of lines of code the security tools can scan per minute. This is not a good indicator of performance when the tools see the same code base and its issues over and over again, build after build.
Whatever you do, don’t lose sight of the goal: reduce the defects and don’t let them re-surface by empowering your engineering teams.
One way to achieve this is by creating security regression test suites like you would for any defect. These are tests that assert security defects that have been previously found do not re-appear, or they will quite rightly cause the build to break. This will then force the issue to be fixed by the engineer. Automated security regression tests can be shared between teams to ensure commonly occurring defects are stamped out across the product line.
Thanks for getting in touch.
Anthony should reply within 24 hours.
Oops, there has been a problem.
We couldn't process that request. Please try again.