Please don’t say the word “process” too loud, you might upset the Development team. This ever-present stigma still looms high, curbing the desire and ability of businesses to integrate siloed development, operations, and security processes. But there’s good news: it doesn’t have to be that way. In fact, the worst of it can be quelled by enabling one of the most challenging aspects of any DevSecOps transformation: the people.

Famous engineer and father of Quality control W. Edwards Deming once said: “A bad process will beat a good person every time.” DevSecOps strives to make sure that this doesn’t happen. Its goal is aligning common processes to facilitate collaboration between development, operations, and security to achieve a much more integrated and secure development process. There was a time when businesses would defer security issues to the end of development. This routinely resulted in responding too late and much too slowly to security issues, leading to non-compliance and/or significant reworks which, in hindsight, really shouldn’t be surprising. When processes are siloed within separate IT teams, the door is opened for miscommunication, bottlenecks, and, ultimately, delays that increase risk and inevitably manifest as inferior products and a lower bottom line.

According to GitLab’s Fourth Annual Global DevSecOps Survey, 42 percent of surveyed organizations said that code security testing happens “too late” in their software development process. There is clearly an industry desire for ‘shift-left’ practices among Development teams, guaranteeing application security at the earliest stages of app development, and DevSecOps does exactly that. Creating short, feedback-driven security loops that can quickly identify problems and respond to them rapidly allows organizations to tackle more complex and sophisticated security threats.

Now you might be asking yourself “how can I make this work for me?” Well, while each organization is different in certain key areas, there are some general measures you can take to support the DevSecOps transformation by streamlining and aligning your development, operations, and security processes.

Re-examine your development processes

W. Edwards Deming also said: “If you can’t describe what you are doing as a process, you don’t know what you are doing.” It’s prudent to take a good, hard look at your life cycle development processes and make sure you fully understand them. They might not be as they seem at first glance. Re-examining your processes can identify points earlier in the process at which testing can be introduced, target specific enabling tools that are appropriate for your codebase, and reveal any glaring gaps. This becomes especially important as your developers become more familiar with secure coding practices.

Establish guardrails that drive your development process

A 2020 global survey conducted by the Ponemon Institute showed that it takes merely $80 on average to fix defects and vulnerabilities discovered early during development versus an astonishing $7,600 for the same defects and vulnerabilities discovered during production. Obviously, security issues that go undetected until the end of development¾or after deployment¾are guaranteed to drive up your overall costs, but what can you do to stop this? Invariably, the answer is to establish a set of well-understood policies and protocols for ‘shift-left’ security. This not only establishes important boundaries before your team even starts the job, but also provides critical information that helps drive your development processes, including security.

Embrace automation as a rule of thumb, not an outlier

In the DevSecOps world, process automation is king, ruling over and impacting everything. It increases collaboration between colleagues, reduces time to market, and streamlines compliance with security mandates. Automation also clears the way for a more rapid response to incidents, and the quicker your teams embrace automation tools as the norm, the faster you can improve your processes and leave behind the cumbersome manual routines. Regardless of how skilled or seasoned your staff are, mistakes are inevitable, because, as we know, “to err is human.” Missteps, delays, and inefficiencies are all too common, and their impact shouldn’t be underestimated. Through automation you can help remove the risk of errors as much as possible, dramatically decreasing the likelihood of slip-ups and avoiding redundancies.

Another huge plus of process automation is its effect on team morale. While this is often overlooked as an advantage, its influence could be your best friend for a smoother end result. Automation can relieve a great deal of stress from your team and promote an environment where everyone on the “frontline” can feel like they’re making more of an impact. Additionally, automation can hold upper management more accountable to making decisions in a timely manner, while also relieving staff of the responsibility of reminding them. With a little less bureaucracy to be concerned with, teams will have more time to spend on the most rewarding aspects of their jobs, which has proven to exponentially boost morale and retention.

Learn equally from process failures and successes

Henry Ford once said: “Failure is simply the opportunity to begin again, this time more intelligently,” and DevSecOps implementations embody this sentiment well, learning with each failure and improving with each subsequent iteration. Honestly, any DevSecOps pipeline that doesn’t fail at some point isn’t really embracing the true meaning of DevSecOps. Crashing and burning is essential to helping your teams learn and improve so that better processes can rise from the ashes.

A proven approach for dealing with failure in this context is the “Three Ways” principle:

• 1st Way: Never pass a known failure or known critical security defect onto downstream work, thereby ensuring success of the end-to-end system.
• 2nd Way: Shorten feedback loops by reporting any failure (including security) as soon as it happens.
• 3rd Way: Build a more secure development culture by learning from past failures, iterating, and tackling new failures/defects just as outlined in the 1st and 2nd ways.

Adhering to DevSecOps practices also means measuring failure as well as success. Failure and success are two sides of the same coin when it comes to generating the metrics used to inform relevant process decisions. Process decisions based on data collected about the various attributes contributing to DevSecOps are much more valuable and go farther towards completing the overall puzzle. Creating a comprehensive metrics program that holistically includes people, process, and technology can provide valuable insight into failures as well as successes. For example, metrics you collect should not only shed light onto failures stemming from people not adopting well-defined processes, but also the inefficient use of tools due to lack of defined processes. Only by collecting this type of data at every stage of the pipeline, and applying a healthy dose of automation whenever possible, can you truly make real and measurable improvements to your processes.

Automation, policy, metrics, people… These elements of implementing successful DevSecOps processes are deep and varied, but simply stated. By examining your existing development processes and accounting for all these areas, the goal of establishing a foundation for effective and secure DevSecOps processes and enabling tools becomes noticeably more attainable. Learning is the key, with the understanding that it is just as important to learn from your failures as it is to learn from your successes.