Security vs. Development: A game of priorities

Written by:
Andrew MacKenzie
Andrew MacKenzie

November 6, 2023

0 mins read

In today's dynamic tech ecosystem, the need to manage AppSec programs at scale is paramount. As codebases expand and threats become more sophisticated, the emphasis is transitioning from addressing singular vulnerabilities to building cohesive security postures throughout all development teams. Emerging approaches, such as application security posture management (ASPM), empower organizations to move beyond individual vulnerabilities, orchestrating comprehensive programs that focus on managing critical business risk instead. These tools streamline the process by automating security controls, enhancing risk analysis, and prioritizing vulnerabilities.

It's worth noting that while ASPM might appear to be a fresh approach to some, at Snyk, it's a direction in which we've been moving for the past 8 years. From day one, Snyk was a pioneer of “developer-first” AppSec tooling. Our goal has always been to take AppSec programs beyond merely “shifting left” with traditional AppSec tools and introduce teams to the idea that for AppSec to really be effective, companies needed to hand over more responsibility for security to developers. That required an entirely different category of security tools built for developers.

While security responsibilities may be handed over to developers, the security team is still accountable for the company’s application risk posture. Getting the tools integrated with developers’ tools is only part of the work we do at Snyk. An even bigger part of the work is helping security and development teams work together to take a more prevention-oriented approach to security. Of course, that involves the use of Snyk’s tools but also education and security champion programs; defining and measuring app sec success metrics; and scaling successes from the first application team, to every application and team. Serving our customers over this period, ASPM stands as a testament to our dedication and the productization of our accumulated expertise, setting a benchmark in application security.

What is ASPM?

Application security posture management (ASPM) is an application security approach that leverages holistic visibility into the application environment, automation, and comprehensive security measures to implement, measure, and improve application security programs.

ASPM aggregates, correlates, and assesses security signals throughout the software development, deployment, and operation lifecycle. Its goal is to enhance visibility, manage vulnerabilities, and control enforcement to improve application security efficacy and risk management.

To harness the full potential of these tools, a strategic alignment between the Development and Security organizations is essential. This alignment often poses a challenge, as security and development can sometimes appear to operate in distinct realms. With the backdrop of the benefits offered by ASPM, it becomes even more vital to grasp each team’s unique motivators.

Grasping each team's unique motivators is key to achieving broad developer adoption of security tools like Snyk.

Team needs


Where needs clash

  • Focus: Vital security patches vs. vital new features.

  • Pace: Security's caution vs. Development's sprint.

  • Tool adoption: Developers' enthusiasm for new tools might skip the security vetting queue.

  • Communication: Both can sometimes speak different languages — documentation for one can be gibberish for another.

  • Training: To a developer, security training might look like a detour.

Introspection: Spotting the misalignment

To resolve potential developer security tooling adoption issues, first, diagnose any existing misalignment:

Questions the security leaders could ask themselves

  • Strategy: How are developers incorporated in our security vision?

  • Tooling: How do we back developers in embedding security?

  • Learning: What's our security education plan for developers?

  • Feedback loop: How's the developer-security communication?

Questions the engineering leaders could ask themselves

  • Developer view: How do developers perceive their role in security?

  • Challenges: What hurdles do they face with developer security tooling?

  • Security-developer dynamic: How would you define the current security-developer relationship?

  • Learning from mistakes: Post security incidents, how are lessons integrated?

  • Sprint allocation: What percentage of our sprints are we dedicating to security?

Creating synergy: Boosting developer security tooling adoption

Once you've pinpointed the disconnect, it's about building the bridge:


  • Security lead: Engage developers with regular security updates and be receptive to their feedback.  

    • Prioritize essential updates: While regular engagement is vital, it's also important to distinguish between critical security notifications and lesser alerts to avoid overwhelming developers.

    • Meet regularly: Organize monthly or quarterly meetings with developers to discuss security insights, addressing trends rather than isolated incidents.

  • Engineering lead: Push for open developer participation in these discussions. Appoint a liaison who can work directly with the security tooling vendor.

Seamless Integration

  • Security lead: Security tooling checks in the SCM and/or CI/CD is a start. Ensure the security data is visible and actionable. Don’t fail PR security checks or builds initially in order to build developer trust through education rather than enforcement.

  • Engineering lead: Equip developers with security tooling know-how. Coordinate on vulnerability alerts, triage, and policy plans.

Continuous Learning

  • Security lead: Leverage developer security tooling for targeted security workshops.

  • Engineering lead: Encourage developers to attend when workshop sessions are directly relevant to their jobs.  Provide regular feedback to Security on sessions to ensure they remain engaging and applicable to developer audiences.

Unified Metrics

  • Security lead:  Kick off vulnerability KPIs. Share, celebrate, and be open to developer feedback.

  • Engineering lead: Dedicate a portion of tech debt spend on security by allocating a percentage of sprints to fix existing issues. Incorporate security goals into sprint planning, especially when launching new features.  Encourage devs to provide ongoing feedback on security alerts — differentiate between critical issues and background noise.

Prioritize to stay secure

In conclusion, to optimize AppSec programs at scale, we must transition from solely addressing individual vulnerabilities to establishing integrated security strategies across all development initiatives. Understanding the distinct motivations of developers and security teams is crucial in this endeavor.

Platforms like Snyk have the potential to be a catalyst for collaboration between security and development teams through enhanced visibility, security controls, in-depth risk analysis, and strategic prioritization. This collective approach is the future, where security not only identifies threats but also collaborates with developers to design proactive defenses, ensuring a unified, agile, and secure tech ecosystem.

Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer’s toolkit.

Start freeBook a live demo