Developer Security Snyk Bigfix

This presentation, delivered at The Big Fix 2023 by Snyk, addresses the intersection of developers and security from the vantage point of Anant Shrivastava’s decade-and-a-half of experience across development, system administration, and information security. The talk makes the case that developers must take full ownership of their product’s security, that DevSecOps should transform security from a subjective art into a repeatable science, and that practical tooling integrated close to the point of code creation is more effective than gate-based security reviews.

Key Topics Covered

Speaker’s Dual Developer-Security Perspective:

• Maintained a WordPress plugin and experienced irresponsible vulnerability disclosure firsthand, leading to closing the plugin
• Single-handedly maintained AndroidTamer (TamerPlatform), a custom Debian-based distribution, from 2012–2018 with next version planned
• Runs CodeVigilant, a PHP/WordPress static analysis project with 200+ public disclosures, 150+ pending, built and maintained the entire backend, automation, and disclosure coordination
• Builds a fully static HTML/CSS-only website with a custom Hugo theme, deliberately avoiding JavaScript
• Managed 15+ self-hosted WordPress sites since 2007 and ran the complete offensive, defensive, and operations network for an infosec company for 6+ years

Software Is Eating the World — And Breaches Follow:

• The Verizon DBIR 2021 shows web applications as the primary technical cause of data breaches
• Over the 2011–2021 decade, the attack landscape has fundamentally shifted to target the application layer
• This makes application security inseparable from the development process

The Misunderstanding Between Dev and Sec:

• A persistent disconnect exists between how developers and security professionals perceive each other’s responsibilities
• Security teams are often positioned as blockers; developers are often blamed for vulnerabilities
• This adversarial relationship produces worse outcomes than a collaborative model

DevSecOps — Converting Security Art to Security Science:

• “DevSecOps as a term should not have existed but it’s here and people use it”
• The goal is to transform security practices into something automatable, documented, testable, and repeatable
• While 100% conversion is not possible, achieving the high 90s through systematic automation is realistic
• DevOps should naturally absorb security rather than treating it as a bolted-on phase
• Reference to the NotSoSecure “DevSecOps: What, Why, and How” methodology from BlackHat 2019

Developer Ownership of Security:

• No one knows code better than the developers who wrote it
• Security teams should serve as an enabler and support function, providing inputs early and often
• Developers must take final ownership of their product’s security posture
• If the security team is acting as a bottleneck, the process is fundamentally broken

Community Perspectives on Developer Security:

• A Twitter thread surveying what the security community wants developers to focus on produced a mix of responses
• Common themes: shift security to earlier stages, address third-party dependency risks, and empower developers rather than restrict them
• Veterans in the field consistently emphasize collaboration over gatekeeping

Dependency Tracking as a Critical Gap:

• Third-party dependencies emerged as a major community concern
• The software supply chain introduces risk that individual developers may not fully appreciate
• Proactive dependency management and auditing are essential development practices

Practical Tooling and Shift-Left Hierarchy:

• Use customizable tools like Semgrep that developers can tune to their specific codebase and coding patterns
• Learn to test for vulnerabilities, not just to prevent them
• Shift detection as close to code writing as possible: IDE Plugin (immediate) > git commit hook (pre-commit) > CI tool (build time)
• OWASP resources for practical implementation: Application Security Verification Standard (ASVS), Proactive Controls, Integration Standards, Spotlight Series

Key Recap Points:

• Developers are the best judges of how code gets changed and should drive security decisions for their code
• Security teams can help but cannot take ownership of product security on the developer’s behalf
• Pick tools that work for your team’s workflow and automate security activities wherever possible

Actionable Takeaways

1. Accept that application security is a developer responsibility — leverage security teams for guidance and expertise, but take final ownership of your product’s security posture.
2. Transform security activities from subjective expert assessments into automatable, documented, testable, and repeatable processes integrated into your existing DevOps workflows.
3. Implement the shift-left detection hierarchy: IDE plugins for immediate feedback during coding, git commit hooks for pre-commit validation, and CI pipeline tools as the final safety net — catching issues earlier is exponentially cheaper.
4. Adopt Semgrep or similar customizable static analysis tools that developers can configure with rules specific to their codebase, rather than relying solely on generic security scanners.
5. Make dependency tracking and auditing a first-class development practice — treat third-party component management with the same rigor as your own code.
6. Use OWASP’s practical frameworks (ASVS for requirements, Proactive Controls for implementation, Integration Standards for tooling) as the foundation for embedding security into your software development lifecycle.
7. Foster a collaborative model between development and security teams — replace adversarial gate-based reviews with continuous, supportive engagement that starts at the earliest stages of development.