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.

More from Application Security

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Detecting the Undetected: The Risk to Your Info

IBM’s Advanced Threat Detection and Response Team (ATDR) has seen an increase in the malware family known as information stealers in the wild over the past year. Info stealers are malware with the capability of scanning for and exfiltrating data and credentials from your device. When executed, they begin scanning for and copying various directories that usually contain some sort of sensitive information or credentials including web and login data from Chrome, Firefox, and Microsoft Edge. In other instances, they…