Freely subscribe to our NEWSLETTER

Now is an opportune time to address it in order to prevent further challenges as these roles increasingly become intertwined. Developers are hyper-focused on bringing new features and products to market as quickly as possible, while security teams are focused on ensuring the most secure environment. Both ultimately want what is best for the organization, but because of their differences, they are constantly hitting roadblocks that could slow down momentum. To address this conflict, a shared language between the two must be introduced in order to get both aligned and working towards the same goals. There are myriad ways organizations can create a common language to reduce conflict and become valuable partners.

A clash between two goals

Miscommunication between developer and security teams is a tricky challenge, usually only visible through non-tangible consequences such as frustrated, burnt-out teams and wasted time. However, it’s valid to assume that recent breaches which have materialized due to misconfigurations have started with a lack of communication and collaboration between these two teams. Cybercriminals are on a relentless hunt to exploit API vulnerabilities before organizations can spot them. Without proper communication between these two vital teams, it is far too easy for things to fall through the cracks, making it much easier for cybercriminals to exploit vulnerabilities.

A company’s ultimate goal is to create products that bring value to customers while meeting security standards. If each team pushes its own agenda without minding the other, an inevitable clash will occur, drastically impacting business outcomes. Both innovation and security goals must be met in tandem, not in siloed environments. Security team leadership often raises requirements to meet specific security standards without insight into the current development process. Without fully understanding the system and the solution, security unintentionally becomes a "regulator" (aka the "department of no") in the eyes of developers and an inhibitor of the progress they are trying to achieve. This can become incredibly negative.

But as with everything, there are two sides to every story. From the security team’s perspective, developers often dismiss security as a post-production activity. Developers should look at functionality, implementation, and security as a whole, implementing high-security standards in the early stage of the process, as that is what’s best for the organization in the long run. Unfortunately, however, developers are under immense pressure to deliver results quickly. For them, the best case scenario involves minimal security standards to ensure their code won’t break, without thinking about the issues those lack of standards will create down the line.

The role of security leadership

Let’s start with security leadership. What can leadership teams do to work towards building trust within these two groups? Everything begins with culture, so it needs to start there. Security and business leaders must relay the message to developers that security is a business enabler, not a development blocker. This is where you can frame success to developers in a way that aligns with business growth. For example, having a secure product in an age where everything is digital inherently adds value to the product. Also, upholding security standards is a crucial deciding factor for prospective clients that prioritize security, which today, all do.

Once this culture is established, security leaders can look at influencing processes and continuously build trust and improve communication. Security experts should request to be a part of the build and planning phases so that they better understand the functional requirements that need to be delivered to the customer. Developers will begin to understand the framework for secure code, and security teams will acknowledge the needs and limitations developers are faced with.

The role of engineering leadership

On the flip side, developers should feel empowered to explain the development process to security teams and IT leaders, working together to pinpoint the best time to incorporate security into their workflows. The development team’s insights are critical at this stage. Security should listen intently to what works best for them. Engineering leaders should also implement security as a top KPI for the success of a new feature or product rather than only focusing on how new and innovative a functionality is. Lastly, all developers should be given formal training on the basic tenets of API security; this is an investment that will keep paying off down the line.

It is important to emphasize how important it is for these teams to work toward a common goal to achieve long-term success. For this to happen, leadership on both sides must come together to decide what those goals are and be transparent in communicating them to avoid any vital element being lost in translation. This will be no easy feat and will take investment in training, education, and a rethinking of processes to break down dated ways of working. At the end of the day, both teams want to help their company succeed, but differing motivations, mindsets, and KPIs often lead to miscommunication and a lack of collaboration. Bringing together these two perspectives into one shared language will ease the conflict that stands in the way of cloud-native success and innovation. A united front will safeguard organizations from today’s most advanced threats.