How to Scale Application Security with DevSecOps

TL;DR

Scale application security by automating repeatable workflows, reserving manual intervention for the highest-risk decisions, and giving developers high-signal findings they can act on. DevSecOps requires security teams to stop acting as routine release gatekeepers, accept that perfect security is unattainable, and prioritize business-risk reduction while enabling efficient software delivery.

Transcript

Testing, testing. Okay. Hey, everybody. Uh, so we still have a few minutes. We're gonna let people filter in, but I thought I would just say hi a little bit. Um, so yeah, we'll get to the slides in a second. Uh, but how's everybody doing today? You having a good afternoon, good day? Great. Awesome. Very cool. Um, one thing, uh, I always like to ask... Read More

Key Insights

• Security automation is essential for scale because every security team operates under limits involving personnel time and cost. Automating repeatable workflows allows a small team to support broader development activity while concentrating human expertise on decisions and risks that cannot be handled reliably through automation.
• Security teams can no longer function primarily as release gatekeepers in many companies. They must use blocking decisions sparingly and reserve firm refusals for exceptionally important situations, particularly when a small application security group is responsible for supporting a much larger population of developers.
• DevSecOps is a risk-reduction discipline rather than a promise of perfect security. Organizations must identify the risks that matter most to the business, mitigate those priorities, and consciously accept that some lower-priority problems may remain while development and operations continue moving forward.
• High-signal, low-noise security tooling is preferable when teams have limited capacity to investigate findings. Some companies accept that tools may miss issues if the findings they do produce are accurate, actionable true positives rather than a large stream of questionable alerts.
• Developer experience is an important security design concern because developers are users of security tools, processes, and guidance. Security teams should apply the same attention to usability that product teams apply to customer-facing interfaces, making secure actions understandable and practical within existing development work.
• Traditional security gates do not scale when only a few application security engineers support a very large developer organization. A workable program distributes security capabilities, uses automation, and enables development teams instead of requiring the central security group to review every production change manually.
• SAST and DAST can impose substantial operational effort and cost while delivering questionable value in some organizations. Their usefulness should therefore be judged by the quality and actionability of their findings, rather than by the volume of issues they report or the mere presence of scanning.
• A scalable security program requires both immediate actions and sustained medium-term and long-term investment. The proposed playbook combines broad security principles, practical program improvements, and a concrete action plan that organizations can adapt according to their most pressing needs and available capacity.

Questions & Answers

Q: How can a small security team support many developers?

A small security team can support a much larger developer population by automating repeatable workflows, replacing routine manual approval gates with scalable controls, and focusing human attention on the most important risks. Security professionals should enable developers to make secure decisions through useful tools and processes, while reserving firm blocking decisions for exceptional cases that the organization cannot safely permit.

Q: Why should security teams stop acting as routine gatekeepers?

Routine security gates become impractical when a few application security engineers must review the work of a very large developer organization. Requiring central approval for every production change limits delivery speed and consumes scarce security time. Security teams should instead automate controls, help developers address risks directly, and save their strongest blocking authority for issues that are exceptionally important.

Q: How does automation improve a DevSecOps program?

Automation improves DevSecOps by reducing the amount of limited personnel time spent on repeatable security work. It lets security processes operate across more development activity without requiring a proportional increase in staff. This gives security specialists more capacity for complex judgment, serious risks, and work that cannot be handled effectively through an automated workflow.

Q: What does high-signal, low-noise security tooling mean?

High-signal, low-noise tooling produces findings that are likely to be true, relevant, and actionable instead of overwhelming teams with questionable alerts. Some companies are willing to miss certain issues if the findings they receive are consistently useful. This trade-off protects limited investigation time and makes developers more likely to trust and respond to security results.

Q: Why is perfect security not a realistic DevSecOps goal?

Perfect security is not realistic because organizational decisions involve competing priorities and unavoidable trade-offs. DevSecOps should focus on identifying the risks that are most important to the business and reducing them without unnecessarily stopping delivery. Some lower-priority problems may need to remain unresolved so that limited time and resources can be directed toward more consequential risks.

Q: How should companies balance development speed and security?

Companies should balance speed and security by treating security as risk management rather than as an unconditional approval barrier. They can automate common checks, deliver actionable findings to developers, and intervene manually where the business risk is especially important. This approach supports faster and more efficient delivery while still raising the organization’s security bar in a systematic way.

Q: Why should security teams treat developers as users?

Developers interact with security tools, alerts, requirements, and workflows, so their experience directly affects whether security guidance is understood and followed. Security teams should give these internal systems the same attention to usability that product teams give customer-facing interfaces. Clear, practical, low-friction controls help developers take secure actions as part of their regular work.

Q: When should a company invest in a scalable security program?

A company should begin with actions it can take now, while also planning medium-term and long-term improvements. The approach assumes that teams may invest meaningful time in the present to achieve larger security gains later. Priorities should reflect the organization’s most relevant risks, staffing limits, development practices, and willingness to improve security workflows systematically over time.

Summary & Key Takeaways

• DevSecOps addresses the challenge of improving security without preventing development teams from moving quickly. Because a small application security team may support a much larger developer population, traditional approval gates do not scale. Security programs must instead enable developers, automate repeatable work, and reserve blocking decisions for exceptionally important risks.

• Effective security programs are built around automation because available personnel time and budget are limited. The talk draws its recommendations from more than 50 conference presentations, dozens of blog posts, tools, and conversations with security engineers and leaders at companies that operate mature security programs across modern development environments.

• Security is fundamentally a risk-management practice involving business trade-offs, not a pursuit of perfect protection. Teams should favor high-signal, low-noise tools whose results are accurate, actionable, and useful to developers, even if that approach misses some issues. Security workflows should also be designed with developer experience in mind.