DevSecOps What Why

This presentation by Anant Shrivastava at BlackHat ASIA 2019 introduces DevSecOps — the practice of integrating security into DevOps pipelines to achieve “Secure by Default” outcomes. Delivered in a concise 25-slide format, the talk covers the what, why, and how of DevSecOps, walking through the concept of shifting security left in the development lifecycle, the specific tooling categories that can be automated within CI/CD pipelines, the cultural changes required to make DevSecOps successful, and real-world case studies demonstrating what happens when security is neglected. The presentation emphasizes that DevSecOps is not a one-size-fits-all solution and requires both automation and organizational culture shifts.

Key Topics Covered

• What is DevSecOps: An effort to strive for “Secure by Default” by integrating security into tools, creating a Security as Code culture, and promoting cross-skilling across development, operations, and security teams.

• Why DevSecOps is Needed: Traditional security cannot keep pace with modern DevOps velocity. Security must be embedded as part of the process to ensure safety. The “shift left” concept demonstrates that finding a vulnerability (e.g., SQL injection) earlier in the pipeline requires fewer man-day effort, no new deployments, and can be caught by automated source code review.

• DevSecOps Pipeline Stages: The presentation maps security controls across the entire pipeline:

  • Pre-Commit: Hooks and IDE plugins to catch secrets and basic security issues before code is committed
  • Secrets Management: Tokenizing credentials to prevent leakage from config files
  • Pre-Build (CI/CD Server): Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to identify vulnerable code and third-party libraries
  • Post-Build: Dynamic Application Security Testing (DAST) for deployment-specific issues
  • QA/Staging: Manual web application pentesting for business logic flaws
  • Production: Security in Infrastructure as Code (IaC), Compliance as Code, alerting, monitoring, and vulnerability management

• Tools of the Trade: Categories and specific tools mentioned include:

  • Pre-Commit Hooks: Git Hound, truffleHog
  • IDE Plugins: CAT.net
  • Secret Management: Keywhiz
  • Threat Modeling: ThreatSpec, Microsoft Threat Modeling Tool
  • SCA: Retire.js, plus language-specific tools
  • SAST/DAST: Various open-source options (preference given to open-source tools)
  • Infrastructure Scanning: Docker Bench for Security
  • Vulnerability Management: Jackhammer
  • WAF: Multiple options listed

• Tool Selection Criteria: For a tool to belong in the pipeline it must have API/command-line access, complete execution within 15 minutes maximum, be containerizable/scriptable, have minimal licensing limitations, produce machine-readable output (JSON/XML, not stdout), and be configurable to manage false positives and false negatives.

• Cloud Security Considerations: The threat landscape changes in cloud environments with new concerns around Identity and Access Management, billing attacks, security groups, permissions to resources, rogue/shadow admins, and forgotten resources that can lead to compromises or unexpected billing.

• Cultural Aspect and Security Champions: Automation alone will not solve problems. Organizations need to foster collaboration and an inclusive culture, encourage security mindset outside the security team, build security champions (one per team) who bridge Dev, Sec, and Ops, incentivize collaboration through internal bug bounties and sponsored cross-skilling trainings, and avoid the blame game.

• Case Studies: Four real-world scenarios illustrating security failures:

  • Unaccounted and unmonitored assets — prevented by recurring asset inventory and automated assessments
  • Auth tokens accidentally exposed — prevented by pre-commit hooks and continuous repository monitoring
  • Cloud assets misconfiguration — prevented by continuous monitoring and review of cloud configuration
  • Misconfiguration leading to code disclosure — prevented by patching and continuous monitoring

• Beyond DevSecOps: Periodic penetration testing and continuous bug bounty programs remain essential. Organizations should act on feedback, and risk acceptance documentation should represent the worst-case scenario rather than being the first resort.

Actionable Takeaways

1. Start by mapping your current DevOps pipeline and identifying where security checks can be injected at each stage — pre-commit, build, post-build, staging, and production.
2. Implement pre-commit hooks (Git Hound, truffleHog) to catch secrets and credentials before they enter the repository, but treat them as defense-in-depth rather than sole protection.
3. Adopt the “15-minute rule” for pipeline tools — any security tool in the CI/CD pipeline should complete within 15 minutes and produce machine-readable output.
4. Establish a Security Champions program with one representative per team to bridge the gap between development, security, and operations.
5. Prioritize Software Composition Analysis (SCA) alongside SAST, as the majority of modern software consists of third-party libraries with potential vulnerabilities.
6. For cloud environments, expand your security focus to include IAM policies, billing monitoring, security groups, and asset inventory — not just application-level vulnerabilities.
7. Remember that DevSecOps is both automation and culture — invest equally in tooling and in fostering a security-conscious mindset across all teams.
8. Validate all tools and approaches in your specific environment before full implementation, as every environment is different and your mileage will vary.