Developers and Security

This presentation, delivered as an invited talk to a developer audience, shares Anant Shrivastava’s perspective on the relationship between developers and security — drawn from over fifteen years of experience spanning development, system administration, and information security. The talk argues that developers are uniquely positioned to take ownership of application security, that DevSecOps should transform security from an “art” into a repeatable “science,” and that collaboration between security teams and development teams is the key to producing stable, secure software.

Key Topics Covered

Speaker’s Developer Credentials:

• Maintained a moderately successful WordPress plugin, experienced irresponsible disclosure firsthand, and closed the plugin after fixing the reported vulnerability
• Single-handedly maintained AndroidTamer, a custom Debian-based distribution, from 2012–2018 with full infrastructure and setup responsibility
• Runs CodeVigilant, a static code analysis project focused on PHP/WordPress with 200+ public disclosures and 150+ pending
• Builds a fully static HTML/CSS-only website with a custom Hugo theme, specifically avoiding JavaScript
• Managed 10+ self-hosted WordPress sites since 2007 and maintained the complete offensive, defensive, and operations network for an infosec company for 5+ years

Software Is Eating the World:

• The Verizon Data Breach Investigation Report (DBIR) 2021 shows web applications as the primary technical cause of breaches
• Over the decade from 2011 to 2021, the attack landscape has fundamentally shifted toward application-layer threats
• This makes application security a developer-centric problem, not just a security team concern

The Mess of Misunderstanding:

• A disconnect exists between how developers and security professionals perceive each other’s roles
• Security teams are often seen as blockers; developers are often seen as the source of vulnerabilities
• This adversarial dynamic produces worse outcomes than collaboration would

DevSecOps — Making Security a Science:

• “DevSecOps as a term should not have existed but it’s here and people use it”
• The goal: transform security from an art (subjective, expert-dependent) into a science (automatable, documented, testable, repeatable)
• While 100% automation may not be possible, achieving high 90s coverage through automation is realistic
• DevOps practices should naturally absorb security activities rather than treating them as a separate phase

Developers Must Take Full Ownership:

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

Collaboration Over Silos:

• Reference to a Twitter thread showing the community’s perspectives on what developers should prioritize for security
• Common themes: shift security left, address third-party dependencies, and embrace developer empowerment
• Veterans in the field consistently emphasize collaboration between dev and sec teams
• The OWASP Securing the SDLC framework cited as a reference for integrating security throughout development

Dependency Tracking:

• Third-party dependencies identified as a major concern across the community
• Developers need to track, audit, and manage their dependency chains proactively
• Supply chain security is a shared responsibility between producers and consumers of software components

Practical Tooling and Approaches:

• Use customizable tools like Semgrep for static analysis that developers can tune to their codebase
• Learn how to test for vulnerabilities, not just how to prevent them
• Shift bug detection as close to code writing as possible: IDE plugins > git commit hooks > CI pipeline tools
• Key OWASP references: Application Security Verification Standard (ASVS), Proactive Controls, Integration Standards, and Spotlight Series

Actionable Takeaways

1. Developers should take ownership of application security rather than deferring it entirely to security teams — no one understands the code and its context better than the developers who built it.
2. Transform security from an art into a science by making it automatable, documented, testable, and repeatable through DevSecOps practices integrated into existing development workflows.
3. Shift security testing as far left as possible using the hierarchy: IDE plugins (immediate feedback) > git commit hooks (pre-commit checks) > CI pipeline tools (build-time validation).
4. Adopt customizable static analysis tools like Semgrep that developers can configure and tune for their specific codebase rather than relying on opaque, one-size-fits-all scanners.
5. Proactively track and audit third-party dependencies as a core development practice, not an afterthought.
6. Use OWASP resources (ASVS, Proactive Controls, Integration Standards) as practical frameworks for embedding security into the software development lifecycle.
7. Restructure the security team’s role from gatekeeper to enabler — provide early, frequent input to developers while ensuring the security function never becomes a bottleneck in the delivery pipeline.