Developer Security Based on 15 Years Experience

This presentation at The Big Fix 2023 by Snyk addresses the intersection of developers and security from the vantage point of Anant Shrivastava’s 15 years of experience across development, system administration, and information security. The central argument: developers must take full ownership of their product’s security, DevSecOps should transform security from a subjective art into a repeatable science, and practical tooling integrated close to the point of code creation is more effective than gate-based security reviews. The talk draws on personal experience maintaining open-source projects, a WordPress plugin that was weaponized against him through irresponsible disclosure, and years of bridging the gap between dev and sec communities.

Summary

Anant opens by establishing his dual developer-security perspective through personal projects: maintaining a WordPress plugin (WP File Manager) used by many — including, ironically, by infosec professionals to compromise WordPress sites — and experiencing irresponsible vulnerability disclosure firsthand, which led to closing the plugin. He single-handedly maintained AndroidTamer, a custom Debian-based distribution, from 2012–2018. He runs CodeVigilant, a PHP/WordPress static analysis project with 200+ public disclosures and 150+ pending, having built the entire backend, automation, and disclosure coordination. He deliberately builds a fully static HTML/CSS-only website with a custom Hugo theme, avoiding JavaScript. These credentials establish that the talk comes from someone who has lived on both sides of the divide.

The problem is framed through data: the Verizon DBIR 2021 shows web applications as the primary technical cause of data breaches, with the 2011–2021 decade showing a fundamental shift to application-layer attacks. Anant describes the current dynamic using a Superman analogy: security consultants swoop in, declare they saved the world, and when asked to help clean up the mess, respond with “Not my job.” Security is a cost center, developers understandably feel that “ain’t nobody got time for security,” and the adversarial relationship produces worse outcomes than collaboration.

The proposed solution comes from Black Hat USA 2019: “Automation alone is not going to solve the problems.” What is needed is encouraging security mindset outside the security team, having common goals for the greater good, building allies rather than adversaries, and focusing on collaboration and inclusive culture. Open source projects like OpenSSF, MITRE ATT&CK, Sigma, and D3FEND demonstrate the collaborative model working in practice.

The core of the talk reframes DevSecOps through a provocative lens: security professionals treat security as an art (subjective, unteachable, each practitioner doing it differently), while it needs to become a science (documented, testable, repeatable). Anant argues that developers already accomplished this transformation with infrastructure through DevOps — they took what operations considered an art and made it automatable and replicatable. DevSecOps should do the same: “Eat security art, make it security science.” While 100% conversion is unrealistic, reaching the high 90s through systematic automation is achievable.

A Twitter thread surveying veteran infosec professionals produced telling responses about what they would tell developers: “You are responsible for security of your apps”; “Listen to developer needs carefully”; “Developers are highly intelligent and genius — trust them to do good once you provide them the information.” The consistent theme from those who have spent the most time working with developers is empowerment over gatekeeping.

The practical framework prioritizes shift-left tooling in a clear 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. The talk specifically recommends customizable tools like Semgrep that developers can tune to their specific codebase and coding patterns. Dependency tracking emerges as a critical gap — the software supply chain introduces risk that individual developers may not fully appreciate. OWASP resources (Application Security Verification Standard, Proactive Controls, Integration Standards, Spotlight Series) provide practical implementation guidance.

Key Themes

• Security as Science, Not Art: The transformation from subjective expert assessment to automatable, documented, testable, repeatable processes is the core DevSecOps mission — mirroring what DevOps did for infrastructure
• Developer Ownership: No one knows code better than its authors; security teams should enable and support, not gate and block
• Shift-Left Detection Hierarchy: IDE plugin (immediate) > git commit hook (pre-commit) > CI tool (build time) — each step further from the developer is exponentially more expensive
• Collaboration Over Gatekeeping: Veterans in the field consistently emphasize empowering developers over restricting them
• The Superman Problem: Security consultants who identify problems but refuse to help fix them undermine the collaborative model the industry needs

Notable Points

• Anant’s WP File Manager plugin was ironically used by security professionals themselves to compromise WordPress installations
• CodeVigilant has disclosed 200+ vulnerabilities with 150+ pending, demonstrating that automated static analysis at scale produces real results
• The “automation alone is not enough” insight from Black Hat USA 2019 is critical context — tooling without cultural change fails
• Security professionals who have spent the most time working with developers converge on trusting developer intelligence and providing them information rather than mandates
• The talk explicitly states it is not arguing that “security should be the developer’s responsibility” — rather, it reflects what experienced practitioners observe works

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 existing DevOps workflows
3. Implement the shift-left detection hierarchy: IDE plugins for immediate feedback, git commit hooks for pre-commit validation, and CI pipeline tools as the final safety net
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 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 the development lifecycle
7. Foster a collaborative model between development and security teams — replace adversarial gate-based reviews with continuous, supportive engagement starting at the earliest stages