The move from DevOps to DevSecOps is more than just adding “Sec” to a pipeline; it’s a profound shift in organizational culture, priorities, and workflow. It promises speed and security, but often delivers an overwhelming flood of security findings and friction between teams. How can organizations achieve true integration without becoming the “no cop” or overwhelming their developers?
We recently hosted Matt Tesauro, CTO and co-founder of Defect Dojo Inc. and an AppSec guru with deep experience leading product security at Rackspace and serving on the OWASP Foundation Board. Drawing from his journey—from developer to pen tester to security leader—Matt provided a masterclass on pragmatic DevSecOps adoption, managing vulnerability overload, and building crucial trust between security and development teams.
This article distills Matt’s extensive experience into actionable insights, structured around the most critical questions facing leaders integrating security into high-velocity environments.
You can read the complete transcript of the epiosde here >
Is “Shifting Left” Always the Right Answer in DevSecOps?
The core tenet of the DevSecOps movement is to address security concerns as early as possible in the development cycle, or “shifting left”. While this philosophy is generally beneficial, Matt advises against a dogmatic application, warning that not everything can or should be shifted to the far left of the pipeline.
The Limits of Early Testing
Some security issues only become apparent in a live running environment.
- Complex Interactions: Matt’s experience at Rackspace running a cloud demonstrated that testing new service versions alongside old versions of other cloud components—with many services running different versions simultaneously—is incredibly complex. These intricate interactions can only be fully tested in a live, running environment.
- Need for Forethought: While automation makes processes repeatable and increases visibility , applying the “shift left” principle requires forethought because some things are inherently untestable until late in the cycle.
The Dangers of Dumping Findings
The biggest mistake organizations make when shifting left is generating a high volume of findings and pushing them directly to developers.
- Vulnerability Overload: Security tools are inherently noisy. If you start “flipping over rocks,” you will surface a lot of issues. Handing a developer 666 findings (as Matt once received from a SAST scan—“the static analysis of the beast” ) is a surefire way to make them feel the task is ridiculous and give up.
- The Credibility Killer: Pushing non-actionable findings or false positives to development teams breaks the trust and credibility that the security team needs. Matt’s personal mantra at Rackspace was that passing down non-actionable findings was the fastest way to invite his “foot in your backside”.
How Should Security Teams Manage the Flood of Automated Findings?
Automation produces far more results than manual processes like pen testing ever did. Matt emphasizes that to manage this scale, security needs a dedicated space for processing and filtering results before they are passed downstream.
The Single Source of Truth
Organizations need a single source of truth—a vulnerability management platform (VMP)—where all tool output goes first.
- Pre-Filtering and Prioritization: This platform allows the security team to store and pre-filter the results before pushing them to developers or management. A human must review the issues to separate actionable findings from false positives and prioritize the most spooky items.
- Data Normalization: A major benefit of a VMP is that it normalizes the results from various tools (SAST, DAST, SCA) which all use different names and attributes (finding, issue, vulnerability). This ensures that downstream systems, such as the bug tracker, receive information in one standard, consistent way.
- Strategic Focus: Centralizing data provides visibility to understand what’s happening across the software. For instance, a security team can identify if one specific team struggles with injection attacks while another struggles with library management, allowing for focused improvement efforts.
The Incremental Approach to Tool Rollout (Boil the Frog)
When introducing a new tool, especially one known to be noisy (like SAST ), an incremental approach is vital.
- Start Small: If a tool produces thousands of findings, Matt advises the security team to run the tool and initially only enable critical and high findings. This reduces the workload to a manageable number (e.g., 300).
- Time-Box the Fixes: The team can then be given a reasonable time frame (e.g., a quarter) to work through that initial batch.
- Iterative Improvement: Only after the first batch is complete should the security team talk about turning on the medium findings.
- Avoid “Big Bang”: Security must avoid the “big bang” approach—running every tool on everything at once—as it inevitably “peters out” due to overwhelming complexity and scope. Matt’s success at Duo Security involved running a containerized SCA tool in its lightest configuration across 46 Python repos in three minutes to get a “smell test” and prioritize the cleanest vs. the messiest apps.
How Can Organizations Balance Delivery Speed with Security Cadence?
The pressure for speed is real, with some high-performing teams deploying 75 times a week. Security cannot be a “no cop”. The solution is finding a pragmatic cadence that keeps the pipeline moving while ensuring coverage.
Risk-Based Tool Cadence
Matt’s solution at Rackspace involved a pragmatic approach to running time-consuming tools like DAST.
- Don’t Block the Build: If a team deploys aggressively (e.g., 75 times a week), DAST simply cannot run in line.
- Asynchronous Scanning: Matt set a cadence where DAST would be kicked off with the first CI/CD run, but subsequent runs would check the scanner’s status. As long as the scanner was still running, the new deployments would get a pass. A new scan would only be kicked off once the previous one completed.
- Canary Deployments: Infrastructure automation can facilitate this by allowing CI/CD to fire off a canary deploy that is not part of production, allowing the test to take as long as necessary without impacting the critical path.
- The Payoff: This asynchronous approach meant that security findings were delivered to the developers quickly after discovery. Matt recalled one instance where a team fixed a vulnerability, pushed it to production, and closed the issue in 20 minutes—before the security team could even finish writing the report.
Defining Existential Risk
The speed-versus-security debate should be grounded in understanding the organization’s risk profile.
- Existential Items: Security must identify existential items—the things that absolutely cannot happen. For a financial institution, these are the non-negotiable items that violate banking regulations. These are the issues that receive top priority.
How Can Security Teams Win Trust and Credibility with Developers?
Loss of trust is often caused by security teams being purists and failing to understand the developers’ perspective. This is where empathy becomes the most valuable tool.
Pragmatism and Empathy
- Understanding the Developer: Matt’s experience as an early developer taught him the frustration of receiving security reports where a large portion was “bunk,” forcing him to “burn a day or two to disprove these things”. Security professionals should try shadowing the developer they are providing vulnerabilities to in order to understand how security reports derail their day.
- Contextual Prioritization: The security team must provide the context for a finding, recognizing that developers are incentivized to get stuff out the door. They must articulate why spending 10-20% more time now avoids burning more cycles later when the developer has already forgotten the code.
- Detailed Findings: Security reports should provide sufficient details—the request-response pair, the error message, the HTTP status code—so the development team has everything they need to fix it without having to spend time reproducing the issue. Providing this detail is hugely valuable and wins friends.
Changing the Conversation and SLAs
Matt replaced rigid Service Level Agreements (SLAs) with a more pragmatic approach at Rackspace when faced with an issue requiring the restart of 10,000 active compute machines—a fix that was impossible within the critical 24-hour SLA.
- Mitigation Plan vs. Fix: He changed the Service Level Objective (SLO) definition to require a mitigation plan in place by X rather than a “fix in place by X”.
- Setting Realistic Expectations: Matt worked with the compute team to agree on a realistic date for the full fix and created a check-in reminder on his calendar.
- Focusing on the Plan: This changed the conversation from a fight over an impossible deadline (“critical must be fixed in 24 hours” ) to a collaborative plan that could be communicated to management.
How Do We Prioritize 300 “Critical” Findings?
Even after filtering down to critical and high severity (e.g., 300 findings ), prioritization requires human judgment and context.
- Beyond the Base Score: Security tools provide a base score (like CVSS) but don’t know your environment. The security professional’s value is in providing the environmental context.
- The Context of SQL Injection: Matt provided the perfect example: a SQL injection finding is technically bad. However, a SQL injection in a system used to book internal meeting rooms is not worth spinning up an entire incident response process, whereas the same vulnerability on Rackspace.com warrants pulling the “don cordon” and triggering all alarms.
- Impact on Revenue: The priority must be determined by whether the finding will impact revenue or cause an existential crisis. Issues with low business impact, like the room booking app, can wait “for a few months even”.
- Context is Everything: For newcomers to the field, Matt emphasizes that context is everything. A Cross-Site Request Forgery (CSRF) in a major website that only allows a user to search for “naked penguins” is technically vulnerable, but not important.
What’s the Best Approach to Securing Open Source and the Supply Chain?
Open source software (OSS) is prevalent, with up to 97% of enterprise codebases using it. Matt notes that while OSS is free as in puppy, you still own the problem of feeding, watering, and maintaining it.
Standardization and Automation
- Standardize Library Use: The CIO of American Airlines successfully challenged his dev teams to select only one approved library (e.g., for logging or authentication) instead of having six or seven. This standard list made it easy for new developers to know which library to use, preventing the “library sprawl” that happens when every new dev grabs what they know. Crucially, the dev teams owned the decision, which drove adoption.
- Continuous Scanning: SCA tools have matured significantly. Organizations must wire multiple dependency tools into the pipeline to continually look at dependencies and container bases.
Configuration Management Security
Automation itself introduces the risk of misconfiguration. To secure cloud environments:
- “Shift Left” on Configuration: Use configuration management tools to deploy infrastructure.
- Bless the Tagged Version: The security team should bless a specific tagged version in Git of the configuration code (e.g., version 3 of cloud files deployment).
- Review the Diff: Once the configuration is hardened, the security team’s job shifts from assessing the entire configuration to only reviewing the differential change (the diff) of the code in the PR. If the change is unimportant (e.g., changing the message of the day when SSHing in), the PR can be quickly approved, preventing “drift” from the hardened state.
Is DevSecOps Necessary for a Growing FinTech Startup?
For a growing startup with limited people, time, and money , Matt advises picking battles carefully.
- Focus on Fundamentals: Startups should focus on fundamental work: creating systems that automatically deploy things in a secure or hardened state using configuration management or automation.
- Prioritize Future Avoidance: Invest time and money into systems that avoid future problems rather than solving a one-off issue.
- Agility is Key: Automated deployment gives the startup the fundamentals needed to be quick and agile. If a problem is found, it can be quickly tweaked and reapplied. Handcrafted commands are not repeatable, and if that person leaves, the startup faces a detrimental crisis.
- Maturity is Gradual: Don’t expect “red/green deployments” on the first day; those are very mature practices. Start small, set the basics right, and prioritize long-term, repeatable processes.
DevSecOps as the Lubrication, Not the Brake
The journey from a reactive DevOps environment to a proactive DevSecOps culture is fundamentally a shift in human process, not just technology. The security tools and automation are essential, but they are only effective when used with pragmatism and empathy.
As Matt Tesauro powerfully demonstrated, true velocity isn’t achieved by pushing more findings faster; it’s achieved by acting as the “single source of truth” that normalizes data , provides context , and prioritizes the handful of issues that pose an existential threat to the business. By setting pragmatic SLOs, adopting incremental improvements, and treating developers as partners rather than adversaries, security can transition from being the “no cop” to the lubrication that enables high-speed, secure delivery. The ultimate win is when a critical fix takes 20 minutes instead of a year.
