From product teams to architects to developers, “shift left” security is becoming more an integral part of everyday vocabulary. It is generally understood across technology departments that the old way of doing things, where developer teams deployed code into production before security teams tested this code for vulnerabilities, was inefficient and brought about a number of costly security outcomes. Shifting left reduces risk, is cost efficient and strengthens security.
Many companies are still struggling to “shift left,” despite its known advantages. Some developers are still saying, “Security isn’t my job, that’s for the security team!” Security teams are still telling developers to go back and fix their security mistakes with little collaboration between the two teams.
Fortunately, there are actionable steps that companies can take to help facilitate this cultural shift and get all teams involved in software delivery, marching together to the left. Here are four action items intended for managers and security teams to help enable DevSecOps:
1. Setting realistic deadlines: Management often sets a deadline based on what the stakeholders tell them. Then, when something goes wrong, developers scramble to make up for lost time. Faced with pressures to deliver on time, security is generally the first thing developers let slip. Instead, IT managers should expect that incidents will happen and make allowances for these as part of the project delivery timeline. When a delay occurs, management should never punish developers. This may mean having that tough conversation with the project stakeholders where you say, “We will be late because security matters to us.” By providing developers with support to prioritize security, you are teaching them its importance and influencing a shift towards a security-minded culture.
2. Hiring and training security engineers who code: In order for the two teams to collaborate, security needs to be able to help developers solve their problems. By hiring security engineers who code (and training the ones you already have in coding), security can approach developers with the attitude of “We’re going to figure this out together.”
3. Internal rebranding for SecOps: It’s a good idea for security teams to come up with a new name to help reposition themselves in the minds of developers and shed pre-existing reputations. Consider a fun acronym like Development Operations Partners in Excellence, or “DOPE” team. The name should denote a partnership with developers.
4. Automation: Automate security best practices via API-based tools that inject security into the CI/CD pipeline every step of the way. By implementing tools that automate security you are giving developers the support they need to build in security without asking them for too much heavy lifting.
Beating the drum to march to the left
Some security managers make the mistake of bringing the hammer down on developers, thinking this will make them care more about security. But shifting left doesn’t require calling people out; it requires calling people in.
For a firsthand account of how DHI Group successfully shifted their security left, check out this blog, “From ‘DevOps vs. SecOps to DevSecOps.” Also, to learn about an API-based tool that can help your organization unite Dev and Sec teams, I encourage you to check out a Prisma Cloud daily demo.