We talk a lot about building a culture in which every employee and department puts digital safety first. Everyone pitching in a little bit means the job gets done more thoroughly. Bringing developers, IT operations and security together in a DevSecOps format helps do that. It includes both processes and culture shifts, all of which add a stitch to a blanket over all three teams. Take a look at the challenges to creating a DevSecOps model and how to solve them.

Who Is in Charge?

Organizations that are still struggling with their efforts to transform from DevOps to DevSecOps won’t be doing so forever. Still, there’s work to be done.

One of the main issues that still stands in their way is a lack of clarity regarding who shoulders the burden of security in a DevSecOps model. For example, over a quarter of devs said in a 2020 survey that they felt security was firmly in their hands with the way their employers’ DevSecOps processes were set up. That’s slightly more than the proportion of testers and ops workers who felt the same way at 23% and 21%.

The situation is different for sec teams, however. Close to one-third (29%) of security workers said that no one team should own defense and that everyone should have a hand in it. Plenty of others said they weren’t happy with the timing of developers’ work to find and fix openings that could lead to risk. More than two-fifths (42%) of security experts said that testing still happens too late in the software development life cycle. A further 31% calling the timing of fixes an “uphill battle.”

The Importance of DevSecOps Training

Shortcomings, such as these, highlight the need to focus on helping to make security everyone’s wheelhouse. Employers can do this by taking another look at how developers learn about it. In the process, they need to realize that their devs require different training than their ops workers. Those teams should receive still different types of lessons than other departments. One security awareness training offering does not fit every department, after all.

This point is even more relevant when different employees are working together while still performing separate tasks. Why standardize the training for devs if the types of issues they’re facing are different? You can benefit (and thereby save time and money) by targeting this training based upon what your people need to do on a daily basis.

DevSecOps or good DevOps security in general starts with cohesion and accountability. Knowing that, you might begin by first focusing training on a select number of developers. Then, enlist those people as security mentors to guide and reinforce the training that all others receive, thereby laying the groundwork for a dev sub-culture of security.

Once security is expected, not a goal, the enterprise can begin taking steps to formalize this culture. For instance, they can begin including the need for security training and skills among their devs in their job descriptions or postings. In addition, they could begin using key performance indicators to create reward structures around secure behaviors. This will encourage devs to remember their training on an ongoing basis.

Getting Realistic With DevSecOps

DevSecOps is not a milestone, but an ongoing cultural process. It’s ever-changing. Adding security in development is key. But you can’t tell developers about what they need to do to secure their software once or twice and expect new behaviors to stick. It’s just not realistic. To solve this, reinforce those behaviors with ongoing training and other formal outgrowths of a positive DevSecOps culture.