It’s no secret that security and dev teams have a rocky relationship. Improving communication between security and dev teams has been an ongoing challenge, and is not easy to navigate.
A lot of the time, this happens because each team has a unique set of goals and motivations, but there’s also a cultural divide. Where developers want to go fast and get things to market quickly, security is more risk aware, wanting to take the necessary steps to make sure the code is as secure as it can be. These traits inform how each team does things, and how they show up to the table when it’s time to collaborate. But the question remains, how can security and dev teams collaborate effectively if they speak different languages?
In this blog post, we’ll be digging a little deeper into the challenges that stand in the way of aligning these teams, and share recommendations for how to get it right.
Security has become more important than ever when it comes to building software products and releasing them to market. With security breaches and ransomware attacks on the rise, it’s no surprise. Despite this, security teams have had a hard time finding a cohesive relationship with the teams responsible for building those products — primarily, developers. So, where are the barriers?
At a high level, the differences are quite easy to identify. Developers want to move quickly, shipping out products and features fast for their customers, and using automation and continuous improvement to do it. This is less of a priority for security. Rather than move fast, security teams are there to ensure that code goes out safely, without introducing any unexpected vulnerabilities to their systems. This contrast is at the source of many of the issues that lie between these teams — especially since they have often worked in siloes to create processes, goals, and performance indicators that align with their worldviews.
This is reflected in the model developers and security professionals typically use to work together. Under the so-called waterfall methodology, engineers have built the code and handed it over to security when it was ready for approval. Security would then review the code for any potential vulnerabilities — but wouldn’t always have time to do a thorough review. The time for developers to make fixes was even shorter, and any big security concerns risked slowing down the project altogether.
There has been a concerted effort across tech companies to fix this rift, with the emergence of DevSecOps teams, which embed security into DevOps frameworks, and the notion of shifting security left so that it’s a key consideration throughout the development lifecycle. This push for collaboration is vital if teams want to find an effective balance between speed and security.
Security and developer teams that work well together operate in the spirit of compromise and collaboration. On the one hand, developers take the time to understand security needs so that they can use a security lens as they build code. On the other hand, security professionals have to find a way to mitigate risk in a way that doesn’t impede progress. This balance can lead to a number of benefits. Improving communication between security and dev teams leaves you with a security culture, where everyone wins.
Customers are always looking for faster software, but a security incident can immediately compromise the relationship they have with a software brand. As such, security is a key component of quality software, and it needs to be a priority for all the teams involved in getting the product out the door.
Crafting a culture of security in the organization helps extend accountability beyond the security team, and gets everyone else onboard with making security happen. It also helps to embed security throughout the product development lifecycle, leaving fewer gaps to be identified closer to the launch date. It also goes a long way to facilitating compliance with key security standards such as SOC2.
As Karen Worstell, the former CISO for Microsoft and AT&T Wireless, said in a recent Forbes article, “developers should be security people in developer clothing.” And security teams have a responsibility to empower developers with the right knowledge. Then, with security embedded at every stage of development — and developers equipped with the knowledge they need to identify and solve security bugs — the products they work on are inherently bound to become more secure.
Teams that are on the same page and working towards the same goal are far more likely to have positive relationships — but this is rarely the case with dev and sec teams. Developers will submit code only to have the security team stonewall them without thinking about the business requirements. Meanwhile, developers will also spend their time figuring out the quickest way to defeat the security team’s tool so that they can still function the way they’re used to.
Improving how these teams see each other and work together can lead to improvements in three key areas:
So, we’ve talked about the benefits of getting your dev and sec teams aligned — but how do you get there? Here are five recommendations (plus a bonus tip) that have helped teams in the past.
We’ve talked about the need for a culture of security. In practice, this means teams have to take on a shared responsibility for this function, as well as a shared understanding of what it means.
For starters, equipping developers with cybersecurity knowledge can go a long way to fostering alignment. Some companies offer security bootcamp and learning sessions that developers can partake in for this purpose.
There’s also a conversation to be had around accountability. Developers are accountable for the code they produce and how it functions, and many believe that security should be part of that purview. At the end of the day, the owner of the code is the best positioned to ensure its security. To help action this, we’re seeing the emergence of security champions on the dev team who keep the team accountable for integrating security into product decisions. Where the security team can help here is by ensuring that the developers have tools and any automations they need to write secure code easily and fast.
The security team also has the important role of assessing risk and communicating what developers need to do to mitigate that risk. This shared responsibility can help drive balance between both teams, setting them both up for success as they work towards the same goals.
Help build your developers’ security awareness with our recent blog
Beyond improving the culture and communication between security and dev teams, there’s also a need for tools and data that equip them to work well together. This is where observability comes into play.
Dev and sec teams with robust observability platforms can view system health and security from anywhere. This gives them the ability to access context and analysis in real time so that they can act quickly and with precision when an issue arises. For example, when a security breach happens, both dev and security teams are alerted with the appropriate data, allowing them to collaborate on a solution. And in the event of a system outage, devs can focus on bringing things back online while the security team reinforces policies and covers any potential vulnerabilities enhanced by the outage.
Security standards have become a big part of how we view and treat security, but they only gain real traction once security teams turn them into actionable policies that can be incorporated into workflows. This is where it can be useful to extend the spirit of collaboration and invite developers to the table. This way, they can contribute insights into what will be easy to adopt, where automation could help, and what information might be lacking for the dev team to make the policy fully actionable.
In addition, this approach can make it easier to set expectations around a given security process and clearly identify what team is responsible for each step.
As a bonus, bringing the dev team to the table can also remove the need for security team members to be enforcers, a role that sometimes leads to antagonistic conversations with devs.
This one feels like common sense, but it’s still worth talking about. Security professionals and devs have arrived at their roles through different paths, prioritizing different results, so there’s often a need for sharing these perspectives and experiences.
One way to facilitate communication between security and dev teams is in a social setting with roundtable events where individuals can share their security or development challenges. Casual gatherings, both virtual and in real life, can also help team members to see each other as human beings with relatable experiences.
A buddy system, or pair programming, can also help here. This is particularly useful as you make the cultural shift towards embedding security across the board, as it allows for rapid knowledge sharing. It’s also helpful in getting code out the door faster.
Lastly, putting both teams physically near each other — as in on the same floor in the office — is a simple and helpful tactic. Informal communication is important in building understanding, and having your devs and security share the same space and coffee machine can help facilitate that.
Communication between security and dev teams should be transparent and abundant — one team should rarely (if ever) be surprised by the other. Beyond consistent messages, which can be automated where possible, this can also look like hosting sprint planning meetings together, and gathering to review security reports once they’re delivered to come to a consensus on how to move forward.
As a result, you’ll be able to:
There’s a lot to be said about creating policies, structures, and processes that encourage alignment between these two teams. That said, there’s also value in taking a different tack — one that engages people in a different way.
At some organizations, security teams have opted for gamification. For instance, at a large fintech company in the Bay Area, the security team challenged developers with a series of coding puzzles that related to security. They had a landing page that linked out to each challenge, and if you hovered over the hyperlink you got a breakdown of who had managed to complete it so far.
This accomplished two things. First, it created an atmosphere of fun around the concept of security and showed developers that the security team understands how they think and how they tackle problems. It fostered community and trust. Second, it gave developers a clearer picture of what security is without feeling like they were being lectured.
As the tech landscape keeps evolving, the reality is that the successful companies are the ones that have built a strong culture of security and have managed to align their security and dev teams. Getting along — and finding ways to collaborate and communicate effectively — is no longer a choice. Organizations that follow the five steps above will be one step closer to finding that balance of communication between security and dev teams, and that will help them solidify their place in the market and the trust from their customers.
Want to do more to enhance your developer team’s security awareness? Learn more on the blog.
301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4