We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Code (SAST)
        Secure your code as it’s written
      • Snyk Open Source (SCA)
        Avoid vulnerable dependencies
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Develop secure cloud infrastructure
      • Snyk Cloud
        Keep your cloud environment secure
    • Solutions
      • Application security
        Build secure, stay secure
      • Software supply chain security
        Mitigate supply chain risk
      • Cloud security
        Build and operate securely
    • Platform
      • What is Snyk?
        Developer-first security in action
      • Developer security platform
        Modern security in a single platform
      • Security intelligence
        Comprehensive vulnerability data
      • License compliance management
        Manage open source usage
      • Snyk Learn
        Self-service security education
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Support & services
      • Support portal & FAQ’s
      • User hub
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Listen to the Cloud Security Podcast, powered by Snyk
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
https://res.cloudinary.com/snyk/image/upload/v1645713086/snyk-marketingwp/snyk-default-blog-hero.jpg
DevSecOps

Don’t build security tools, build developer tools instead

Guy PodjarnyJanuary 9, 2018

This post originally appeared on CSO Online, on November 3rd, 2017.

Application security leaders and vendors have long been chasing the elusive goal of getting developers to embrace security. This desire is partly driven by the value of building in security, but the main cause is sheer volume and pace. Developers outnumber security people 100 to 1, and the speed of modern development makes it impossible for any external team to keep up. And yet, time after time, we fail to achieve this goal.

Security solutions integrate with development tools, security needs get added to the regular requirement flow, and security training gets repeated quarterly, and yet security is forgotten the moment the security team stops being involved. How can we break this cycle?

The path to success is to stop building security tools that think about dev, and start building dev tools that handle security. This may appear like a semantic difference, but in fact it overhauls the way we look at security tools and programs.

First, it focuses on the developer’s needs.

When a security team sets a process, it typically starts with their needs. They need to know what the developers are doing, ensure certain controls are applied, and require certain tests to run. Understandably, the process or tools focus heavily on satisfying the security, compliance or governance needs, and on the needs of the security team.

To get true dev engagement, we need to see developers as the most important user of our solution, and think about security and compliance as the supporting functions. How would this security practice help reduce the chance of an outage? How would it improve communication and collaboration across the team? How does it empower more junior developers to take on bigger tasks?

If you can reframe security needs with developer goals in mind, you stand a much better chance of having them fulfilled.

Next, it changes your starting point.

Almost without fail, we try to adapt security practices to the dev workflow. We try to run static analysis in the build process, only to find out it takes too long to fit. We apply this analysis in the IDE but don’t trust developers to dismiss false positives in the results. We alert about a known vulnerability to a developer who isn’t equipped to triage it.

Good developer tools start from the other side. How does the development process work? At what point would this security control provide the most value or be least obtrusive? What are the key requirements to successfully integrate at that point? Armed with answers to this type of questions, you should build your security solution with the right priorities in mind.

These questions may also uncover existing tools in the pipeline that can be used for security process. For instance, on separate episodes of The Secure Developer podcast, the PagerDuty security team discussed using Splunk for security purposes, and Chef Adam Jacobs described how InSpec can help your security posture.

Lastly, it replaces the products you’ll compare yourself to.

Developer tools have evolved dramatically over the last decade, driven by the DevOps revolution and the empowerment of dev. Based on the most successful tools, best practices evolved, ranging from usability to pricing to the importance of documentation.

So instead of comparing your web app firewall to your network firewall, compare it to a successful APM (application performance monitoring) tool. Contrast your App Sec testing tools with linters and code review tools, not network security scanners. These are tools that successfully found their way to the hearts and practices of developers, who now depend on them regularly. If you mimic how such tools work, you’ll easily fit the developer mental model and process.

While my examples focus a bit more on tools than processes, the principle applies to both. Secure development practices would benefit just the same from putting the developer’s needs at the center, starting from the current dev methodologies, and comparing to other practices and processes the engineering team employs. An enforced security practice is constantly at risk of being overlooked, but a development practice, even one that deals with security, can stick around far more naturally.

To get developers bought into security, don’t build security tools. Build developer tools that help security, and see the huge difference in adoption it will make.

Discuss this blog on Discord

Join the DevSecOps Community on Discord to discuss this topic and more with other security-focused practitioners.

GO TO DISCORD
Footer Wave Top
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
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • API status
  • Pricing
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
  • Code Checker
  • Python Code Checker
  • JavaScript Code Checker
Snyk|Open Source Security Platform

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.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2023 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom