Empowering Developers in AppSec: Triage and Collaboration

Empowering Developers in AppSec - Triage and Collaboration

Historically, security programs have struggled when they fail to include developers and partner teams, often falling into the trap of focusing solely on the security team’s needs. This approach has led to a disconnect between security and development teams, resulting in ineffective vulnerability management and often strained relationships.

The following blog post is based on the one of our “AppSec Talk” YouTube videos, in which Kondukto Security Advisor Ben Strozykowski and Rami McCarthy, a veteran security engineer who held security roles at Figma and Cedar Cares, discuss the importance of involving developers in your security program and the application security lifecycle. 

We are going to touch on the need for collaboration between security teams and developers, highlighting the benefits of a developer-centric approach. We try to briefly cover various aspects of this approach, including bug triage, vulnerability management, and the role of developers in security processes. This is the first of a two-part blog post. Stay tuned for part two.

The Role of Developers in Security Programs

The conversation about the developer’s role in the hands-on portions of the application security pipeline, including static application security testing, is a very important one to have. As Rami McCarthy, a security engineer and advisor to Kondukto Inc., emphasizes, “When you stop to think about, like, what’s the role of the developer? One thing you’re really asking is what are we actually doing here for developers and by extension for our partners in security?”.

A developer-centric approach to application security is not just about assigning tasks to developers but about empowering them to be active participants in your security processes. It involves rethinking the entire lifecycle of a bug, from discovery to resolution, and how developers can be engaged in that vulnerability discovery process.

The Bug Lifecycle and Developer Engagement

Whether it comes from static analysis, vulnerability discovery programs, pen testers, or an engineer noticing something unusual, there are different ways a developer can be engaged with and experience that vulnerability discovery is really meaningful.

One can tell which security teams are effective because they have the owners of the code bases in the room and they are actively engaged. As Rami points out, “If your engineers are willing to challenge you due to their deeper insight and know that you’re able to have, like, a nuanced conversation, I think that’s where you really start to get this flywheel empowerment going.”

On the other end of the spectrum, there are also teams where you come back a year later, and nothing would be fixed. Someone files a PDF or Excel report and passes the entire report to a line-level developer who has to prioritize it against all their other work, never getting buy-in or help to understand the importance of the security issue.

It’s not just the developer doing the fixing, but also the security team member and the product managers or whoever’s managing the sprint cadence or release cycle. All of that plays into how quickly or efficiently a bug can be fixed in production.

Triage and Handoff Processes

The handoff is actually really important. It interacts with the bug triage process but it is usually not actually coupled. Some security teams will hand off bugs pre-triage, while others will entirely triage and only expose bugs of a certain priority to engineers, product managers, or engineering management.

Unfortunately, there doesn’t seem to be a strict standard for how these processes should work across the board. Each organization ends up having their own workflows. 

The common models are either security does the triage or developers do the triage. If you have an AppSec team that’s engineering-minded, they’ll take a pass and try to determine if it’s a P0 or P1, or high priority or medium priority. Otherwise, you might just have developers taking these in as bugs in your standard process.

When you shift that all the way to developers, you end up with this really high code context and priority context. A developer who does a good job looking at vulnerability can tell you, “Yes, this vulnerability is cross-site scripting. So if an attacker discovers it, they could attack our users one at a time through an unknown distribution path.”

The organizations who are on the right track are sharing the responsibility. They have someone on the security side who can be the point of contact, and they have a developer assigned to fix certain types of bugs, with an established workflow.

Collaborative Approach to Security

The focus should be on collaboration and integration between security and development teams. This involves adopting processes such as suggested versus accepted risk ratings, where security teams propose priorities and risk levels, and developer teams that are powered to challenge and discuss these assessments. When developers can bring their deeper insights into a nuanced conversation, a flywheel effect of productive empowerment can get really going.

The shift towards a more agile approach in development teams provides an opportunity for better integration of security practices. This involves having cross-functional teams that include security engineers, fostering a collaborative effort where both developers and security professionals share ownership and knowledge.

Implementing this developer-centric security approach requires careful consideration of communication strategies, scaling culture, and leveraging modern tools like Application Security Posture Management (ASPM). It’s crucial to move away from the negative reputation security programs have acquired by being poor partners in many cases. The goal should be to work towards a productive, healthy relationship with developers over time.

Wrap up

Ben and Rami emphasize the importance of integrating developers into the application security lifecycle to enhance vulnerability management and foster collaboration between security and development teams. By adopting a developer-centric approach, organizations can empower developers to actively participate in security processes, leading to more effective bug triage and resolution. 

In part two we will address implementation, metrics and scaling of developer-centric security.