Key Points

• Six Sigma enhances DevSecOps by reframing vulnerabilities as defects, allowing teams to track security debt with metrics and see the efficacy of remediation efforts.
• DMAIC complements DevSecOps’ focus on speed and iteration, enabling root-cause analysis, process standardization, and automation.
• Security should drive value in any hybridized approach, rather than serving as a bottleneck that wastes precious time to get deliverables up to spec.

DevSecOps is built around the principles of speed, automation, and iteration, resulting in a flexible security environment. You can take the standard operations done under DevSecOps and create a far more powerful and versatile hybridized approach by implementing tools, principles, and concepts from Six Sigma. While the industry is still focused on shifting left, taking a systematic, data-driven approach to reducing defects complements the speedy, iterative nature of DevSecOps.

We aren’t focusing on a shootout by any means. Instead, we’re taking a closer look at how you can utilize these methodologies to create a more resilient and efficient software development pipeline that prioritizes security and defect elimination.

The Intersection: A Real-World Example

The core of Six Sigma’s process improvement methodology is DMAIC. It makes for a perfect complement to the fast-paced, iterative nature of DevSecOps. While the processes are never truly the focus in any Agile-based methodology or approach, taking a few core principles and teachings from Six Sigma creates a powerful partner. Code quality will soar, and security will no longer become a bottleneck, but rather an asset and value driver for future deliverables.

With that in mind, I’ve taken the liberty of constructing an example scenario where DMAIC is used right alongside DevSecOps principles to show how to reframe Six Sigma. You’ll see that DMAIC, when utilized alongside DevSecOps, becomes a powerful tool that helps to unlock value and enact lasting changes in how you conduct daily operations.

Define

A team notices several critical vulnerabilities discovered late in the development cycle. The team lead drafts a problem statement with a defined goal: the reduction of all security defects by 75% over the next six months. In this case, it isn’t bugs that we’re terming as defects, but rather the vulnerabilities themselves.

Measure

The team establishes a baseline, making use of automated scanning tools in the CI/CD pipeline. Key metrics are tracked, with DPMO being repurposed for security issues. Further, the team will be logging the Mean Time to Remediate, or MTTR.

Analyze

Data from the scans is going to drive the rest of the improvement cycle, as you might imagine. The team discovers that over 2/3 of the vulnerabilities are caused by a handful of misconfigured libraries being used as dependencies. Root-cause analysis shows that developers didn’t have a standardized process in selecting and vetting dependencies.

Improve

As a result of the previous step, the team implements an automated dependency check in the pipeline to block insecure libraries. Work is then done to create a pre-vetted list of secure libraries, alongside additional, mandatory security training to make sure everyone is on the same page.

Control

Finally, as a result of the work done, a dashboard is created to continuously monitor DPMO and MTTR. This is intended to make sure that processes are working, preventing the recurrence of previous vulnerabilities. The team holds a stand-up to review security metrics and discuss any new issues.

Security Debt as a Defect

In our previous example, we made use of vulnerabilities as a defect. In DevSecOps, you typically treat vulnerabilities as a one-off event. They’re found, remediated, and documented, then you go about your day. However, by reframing them as defects, you can see a measurable impact on quality. As such, this introduces DPMO, or defects per million opportunities, to software development.

Sure, you aren’t running machines intended for fabricating automotive parts. However, an opportunity could be something as small as a line of code. Per our example, all it took for critical security vulnerabilities to be present in code was a single line calling on an unvetted library.

By tracking vulnerabilities through DPMO, teams can readily quantify security debt. This allows teams to set benchmarks and see the efficacy of any security improvements over time. It becomes less a game of bug hunting and fixing, and more about delivering clean, quality code. Quality output is at the core of any implementation of Six Sigma, and when combined with DevSecOps, you’ve got everything you need to keep code clean, secure, and within customer expectations.

Root-Cause Analysis on a Process Level

A DevSecOps team might find a critical vulnerability through the use of an automated tool. However, why this vulnerability was introduced in the first place is never addressed. Six Sigma allows the use of tools like the 5 Whys or Fishbone diagrams. These can be readily applied to DevSecOps processes. Analysis could reveal a lack of training, poor coding practices, or the use of unapproved third-party dependencies.

The goal of using root-cause analysis on the process level isn’t about fixing code, which is just a side benefit. Instead, it is about fixing the processes and mindsets that allow vulnerabilities to take root in the first place. Adjusting mindsets can be an eye-opening experience, especially if you’re fairly entrenched in a certain method of doing business.

Continuous Control and Process Standardization

DevSecOps flourishes with automation, which can be combined with the DMAIC’s Control phase to maintain gains from improvements. Statistical process controls can be created, establishing upper and lower control limits for security processes. A team can build the aforementioned dashboard, like in the Control phase of our example, monitoring key metrics like MTTR and DPMO. If things fall out of those predetermined limits, it triggers an alert.

This allows the team to ably respond to a process that is moving out of control. Creating a self-correcting system where security is front and center enables the creation of a mature, quality-driven workflow. Teams can systematically predict, prevent, and respond to issues as they arise.

Other Useful Tools and Concepts

Ready to keep going? You might want to take a closer look at how Kaizen enables more precise inventory management while increasing employee engagement. An efficient warehouse is a strong indicator of success for any business, and learning how to manage one through the use of continuous improvements under Kaizen is a fantastic way of building a resilient organization.

Additionally, you might want to take a closer look at how BPR can expedite the approval process. Often, with older businesses, approvals can take a considerable amount of time for something relatively banal. A radical shift and working from a clean slate is a way to take control of the approvals process and designate clear ownership of those processes.

Finally, you might want to look at the metrics you can use to measure success in Hoshin Kanri. Setting goals is a given for any organization, but learning how to quantify their impact can be a bit tough. We cover some of the core metrics that go into measuring ROI and success for any Hoshin Kanri implementation. With any luck, you’ll be well on your way to seeing how those goals have fared after 3 to 5 years.

Conclusion

Integrating Six Sigma principles, tools, and methodology into DevSecOps isn’t just about increasing overall security. You’re looking to drive quality outputs in your deliverables, which has a transformative effect on the code you’re writing. Security doesn’t have to be a bottleneck or pain point. By placing it front and center, integrating it into the development cycle, and making use of key metrics, you’re driving value and increasing customer satisfaction.