This is the second instalment of a two-part blog post. The blogs are based on one of our “AppSec Talk” YouTube videos, featuring Kondukto Security Advisor Ben Strozykowski and Rami McCarthy, a seasoned security engineer with experience at Figma and Cedar Cares. In that video, Ben and Rami delved into the critical role developers play in the security program and the application security lifecycle.
In this second part, we will explore the challenges of implementing and scaling developer-centric AppSec programs, and are discussing the importance of metrics to enable a data-driven approach.
Part one, which covered the topics of bug triage, vulnerability management, and the role of developers in security processes, can be found on our Blog.
In many companies there are more than 100 developers for every security engineer. So as a security engineer your role is to integrate security into the agile development process, often without a clear mandate.
The key is to foster open communication and collaboration with lead developers. Start by understanding the current processes and identifying pain points. Engage in conversations to tweak existing practices for better security, rather than imposing strict mandates. This approach helps in setting realistic goals, like fixing critical bugs within a specific timeframe, and shifts the perception of security from being the “Department of No” to the “Department of Possibility.”
Effective communication is key to your success. Begin with one-on-one discussions with the teams that handle high risk areas of the application stack, such as those managing authentication and authorization logic. Gradually scale up to group meetings and broader broadcasts. This pyramid approach ensures that security becomes a collaborative effort, making it easier to integrate into the agile workflow.
Given the typical security-to-engineer ratios, it's impractical to meet every engineer personally. Therefore, scaling culture becomes as crucial as scaling technical processes. This involves standardizing interfaces and automating the collection of additional signals and context for bug triage. The aim is to create a handoff process with rich technical context that's easy to acquire, alongside fostering strong relationships where everyone feels part of the same team.
To move away from the negative reputation security programs have acquired, it's important to work towards a productive, healthy relationship with developers. As Rami is reflecting on past experiences, many developers have felt disconnected from security processes, often receiving minimal information through impersonal channels. Security teams should focus on bringing solutions, not just identifying problems, by developing "paved roads" and eliminating entire classes of bugs rather than addressing individual issues.
Security programs risk becoming "hamster wheels" if they don't focus on scalable solutions. The goal should be to implement solutions that scale and eliminate bug classes, rather than simply shifting toil from developers to security teams. Modern tooling, such as application security posture management (ASPM), can help bridge these gaps by providing a comprehensive view of vulnerabilities across the entire ecosystem, allowing for prioritization based on business risks and enhancing decision-making with additional context.
Describing a program’s security posture, especially in vulnerability management, requires focusing on outcome metrics rather than just operational metrics like "number of bugs fixed". Outcome metrics demonstrate the real-world impact of security efforts. Using a single source of truth for vulnerability management is essential, even if it occasionally results in multiple “single panes of glass”. This approach allows for effective upward communication of core metrics, such as “bugs out of SLA” (Service Level Agreement), which implies effective triage, centralized data, established SLAs, and accountability.
When communicating with management, it’s important to clearly understand and articulate what is being asked: resources (money, people), time and attention on priorities, and support in emphasizing the importance to other teams. The “bugs out of SLA” metric is particularly useful for upward communication because it enables management to take actionable steps, such as dedicating more time to reducing technical debt, emphasizing the importance of SLAs, and fixing incentives if SLAs are consistently missed. You can read more about getting Management Buy-in with AppSec Metrics in our related blog post.
Security is increasingly data-driven, necessitating clean and rich data. Integrating data sources like EPSS and CISA KEV (Known Exploited Vulnerabilities) and having a central place to correlate this information is extremely valuable. Application Security Posture Management (ASPM) can address this need by providing a comprehensive view of vulnerabilities across the ecosystem.
Security engineers often spend excessive time on project management aspects of vulnerability handling rather than taking action. Take advantage of automation capabilities wherever it makes sense to do so. The focus should shift towards empowering developers to be more secure through measurement, incentives, and providing the right tools.
In conclusion, integrating security into the agile development process requires effective communication and collaboration between security engineers and developers. By creating a culture of openness and by standardizing processes, security can become a collaborative effort rather than a hindrance. Metrics and modern tooling play an important role, not just in enabling such a relationship, but also in scaling security programs. A data-driven approach, that prioritizes business risks and enhances decision-making, requires metrics and a central plane of glass that functions. Ultimately, the goal is to empower developers with the right tools and incentives to create a secure and efficient development environment that fosters secure coding practices.