Developers are driving security tech decisions: 10 things security professionals need to consider
By submitting this form, you agree to our privacy policy.
Over the past few years, I’ve seen a huge shift in how businesses make decisions about security tools and technologies. Traditionally, CISOs and security leaders have been the gatekeepers of security technology choices. But as we gain a better understanding of the security threats in the cloud, we see developers are often the ones who actually fix those security issues. For that reason, developers are taking on a much more central role in the selection of these tools.
According to the 2023 State Of Application Security report from Forrester, 53% of global security leaders said that application development teams make the final decision on which application security technologies to implement. Only 2% of those security leaders said that developers are not involved at all. This represents a clear change in cybersecurity decision-making — but there are a few things security teams need to understand in order to work with developers more effectively.
1. If we’re going to ask for help, we need to be ready to return the favor.
This shift in purchasing power presents an opportunity for developers, but it’s important for security leaders to acknowledge that you’re asking them to take on more (and new) responsibilities. Developers can take this opportunity to select tools that help them do their jobs better and faster and also integrate well with their existing workflows. But this means they’re also expected to have a deeper understanding of security principles and practices, something that was previously the domain of specialized security teams.
With that in mind, understand that the role of security practitioners is changing as well. Your job is no longer just to enforce security best practices, you need to guide developers in making informed choices. To be successful, you’ll need to take on more of an educational role, helping developers understand how to implement security effectively and make smart decisions when evaluating the various tools and technologies available.
2. Not all developers care about security — find your “security champions.”
One strategy that I’ve found to be effective is identifying “security champions” within development teams, or people who express a genuine interest in security. Security is a unique field where threats are always changing, which some developers find fascinating — figure out who those individuals are and provide security training to them first. At the same time, realize that not all developers are going to be excited about (or care at all) about security. For those less inclined, the role of the security champions becomes even more critical. They can help translate the complex language of cybersecurity into more relatable terms for their peers.
3. DevSecOps: Do it right, or don’t waste your time.
Since its inception, the concept of “DevSecOps” has sparked debate among security professionals. Even just defining the term isn’t straightforward.
While some question its necessity because they say that security has always been a part of DevOps, others argue that it’s a good way to explicitly call out the importance of security in DevOps. But for many developers, “DevSecOps” is just another buzzword that ends up adding more tasks to their to-do list.
Recently I discussed the concept with KellyAnn Fitzpatrick, Senior Industry Analyst at RedMonk, and I think she summed it up well: “DevSecOps aims to bring security practices into all parts of this software development lifecycle, especially the earlier ones, in hopes of finding or even preventing vulnerabilities earlier in the process, which theoretically can save a whole bunch of time and grief,” she said.
In my opinion, DevSecOps is a good thing. If you’re really doing it the right way, it brings teams together. But doing it the right way requires two things: first, you’ll need a transformational shift within the organization, where security measures are enforced and prioritized by executive leadership. Second, you need developer buy-in. Both security practitioners and engineers have jobs to do. So let’s find a way for developers to be able to code without getting delayed and a way for security teams to push a product with fewer security issues.
And remember that it doesn’t have to be an all-or-nothing approach. Not every team working on every single project has to buy in to DevSecOps in order for an organization to benefit from it. It doesn’t all need to be done at once.
4. Ask the right questions to help each other find the right tools.
Application security tools need to fit well into the development workflow and provide accurate results without disrupting the developers’ work. When evaluating different technologies, it’s important to ask developers the right questions to guide them in the right direction. What do they want and need out of a security tool? Do they need it to integrate with GitHub? Analysis capabilities for Java and Python? Notifications pushed to Slack or Jira? Understanding these needs help you find the right tools that align with developer workflows. As a security professional, you’re probably a lot more familiar with the types of tech available in the market.
5. Clearly communicate your priorities.
Developers don’t always grasp the nuances of security issues, just like you don’t always understand developer workflows. So be clear about the things you care about — for example, I’ve always prioritized gaining as much security coverage as possible. If we’re scanning code, we need access to different repositories to check those for vulnerabilities. We also care about what happens to code after it goes into production. When vulnerabilities are discovered, that’s not the end of the story for us. We need to find all the places we’re vulnerable.
Another thing we pay close attention to is trends, and whether we’re getting better. Are we seeing the same vulnerabilities over and over again? We want to make sure teams are learning from mistakes to avoid continuing to make the same ones.
6. Understand developer motivations: fixing things and solving problems.
It’s no secret that the goals of security and dev teams are vastly different. But the goals of individual developers and their engineering managers aren’t always the same either. While the goals for the team might be to ship things faster, that might not necessarily be why the developer shows up to work every day. Developers like to build things and solve problems. They don’t want to be judged on things like lines of code. Many times, developers are thinking about how they can build things and bring value to the business as well.
7. Find common goals and metrics.
Finding common ground in goals and metrics is crucial. It’s about syncing the rhythm of security and development, setting realistic, mutually beneficial targets that resonate with both teams.
For example, one thing that neither group likes is downtime. No one is happy when the system goes down. That is an agreed upon metric that everyone wants to measure but no one wants to see. The metrics need to be achievable too. You can’t expect code to have zero defects, so find out what the realistic number is, and set expectations that align with reality.
8. Learn how developers work.
As security teams, we need to make an effort to understand how developers work. This doesn’t mean getting overly technical but rather appreciating their build processes, and the challenges that come along with those. What do their processes look like? Where do they check their code in? Which tools do you use right now? When security teams make that small effort, it goes a long way. I’ve seen security teams help site reliability teams discover where and how a service broke. Being involved and listening to what they are going through can make a world of difference.
9. Meet developers where they are.
I love this advice from Kelly: “Make the easy thing to do, the right thing to do.”
Let’s make an effort to meet developers where they are. Work what we’re trying to accomplish into where and how developers are already working. At the end of the day, security does need a place earlier in the software development life cycle. That’s not going to happen if we dump a 100-page PDF of security issues on a developer team.
Let’s talk to developers about the security issues that really matter instead of just giving them a 5-hour training session to sit through.
10. Stop saying shift left so much.
We’ve overused the phrase “shift left.” I think that as the integration of security into every stage of the development process becomes more natural and less forced, we’ll stop telling developers to shift left at every chance we get (I hope).
What’s next?
The changing dynamics in cybersecurity require a collaborative approach between security teams and developers. By understanding each other’s perspectives and working together, we can ensure that security is a seamless, integral part of the software development lifecycle.
For more details on the current state of application security, I recommend reading the Forrester report here.
