Hi everyone, and thank you for joining me. My name is Sanny and I work at Salesforce as a director of product management, and today I am thrilled to share a transformative framework for understanding DevSecOps Health, the one that moves beyond individual tools or isolated metrics into a more holistic, actionable engineering first way of driving. Security and operational excellence. This framework responds to a challenge nearly every organization faces. You are investing heavily in DevSecOps, automation, scanners, compliant workflows and whatnot, right? And yet, leadership still struggles. To answer this simple question, is our pipeline actually healthy today? I'll show you how to answer that question with clarity. Precision and confidence. Let's talk a little bit about the DevSecOps Health Paradox that we currently face. This is at the heart of the modern, uh, organizations today. Organizations never had more tools than we have today. Um, more scans than ever, more dashboards than ever, but somehow the actual security posture is less clearer than ever. Strange, right? Security teams are checking boxes. They are, their development teams are pushing code and operations team are maintaining uptime, but they're not speaking a shared language of health. When everything gets measured independently, nothing gets understood collectively and the result, you might have pipelines that technically pass every scan, but they're fundamentally brittle. You might have deployments happening rapidly. Yet the observability debt is masking early signs of incidents, and the more tools we add, the more artifacts we generate, like logs, alerts, reports without necessarily improving decision making. This is called the DevSecOps Health Para. So basically the bottom, the bottom line is more tooling does not really equal more clarity in many cases, less is more. So what are some of these, um, gaps in our current practices today? So we studied organizations across various industries, and there are these three systemic gaps that surface again and again across all of them. The first one being. Lack of standardization. Everyone collects data, but nobody translates it in the same way. What I mean by that is there is no consistent methodology for turning raw scan output into health signals, which means no two teams measure things the same way. The second one is inconsistent threshold. Teams are defining their own acceptable limits, their own threshold. So one group might consider a 32nd bill delay acceptable versus while other would not. Security exceptions may be strict in one unit, but relax in another unit. This inconsistency, undermines benchmarking and meaningful improvement systemically. The third one is missing remediation guidance. Even when a problem is identified, teams don't know what to do next. What is the next best action to take? Is this a configuration fix? Is this a redesign? Is this a backlog item? How do I actually move forward? So our framework addresses all of these three gaps by grounding these thresholds, maturity levels, and remediation pathways across the research that we did. So let's talk about this framework and the four dimensions associated with it. So instead of drowning in dozens of disconnected metrics, these are the four dimensions that we have distilled DevSecOps health into these act as pillars of a secure, sustainable, and scalable ecosystem. The first one being platform efficiency, meaning how effective and stable your underlying platforms are. The second one, customization. Resilience, meaning how safely you diverge from vendor or community defaults. The third one, observability meaning how deeply you understand your application and system behavior. And the fourth one, security guardrail adherence, meaning how consistently teams follow automated, preventative detective and corrective controls when assessed together these dimensions. Give you a 360 view of your security posture, not only in theory, but in reality. Now, let's deep dive into each one of these dimensions and understand a little bit more about what they mean. So the first one is platform efficiency. We start with platform efficiency because nothing else matters if the foundation itself is shaky, right? Security cannot just be bolted on. It cannot be something you add once everything else is finished. It must be embedded inside a performant and scalable, stable and resilient platform. Here's why, right? If builds are slow, developers are gonna bypass the gates. If infrastructure provisioning is sluggish, incident response slows. If reliability is low, teams constantly are in that firefight mode, and when you're firefighting, you're not proactively securing. So what are some of these key indicators of platform efficiency? The top four are pipeline performance. We all no long builds in white shortcuts, so pipeline performance is key. Second one is provisioning speed, 'cause that impacts your blast radius and response window. The third one is resource utilization. Shows whether systems are tuned correctly or accumulating silent technical debt and reliability. Frequent outages, degrade trust in security processes. So a secure organization is first and foremost an efficient one. Hence platform efficiency is one of the key dimensions here. Alright, let's talk about the second dimension. Customization, resilience. This is one of the most underestimated sources of incidents, customization. They involve, they evolve, they drift, they become outdated. Customizations get orphaned. Uh, and that accumulates tech debt, right? And many of them inadvertently introduce vulnerabilities. We classify maturity in these three levels. Low maturity, meaning everything is customized, nothing is tracked. The security implications in this case are wild and unknown, right? And teams inherit this fragmented, inconsistent ecosystem, which is not sustainable. The next level is the developing maturity where teams maintain a customization registry. At least basic reviews are happening, but still like the long-term governance is missing from the picture, which is where the high maturity comes in. This is where the magic happens, right? Customizations have clear owners, lifecycle management exists. Deprecation is intentional. It is regular. Testing coverage is deep and wide, and the security reviews aren't just ceremonial. They are meaningful. This dimension, as you can see, helps organization balance between what they must customize and with what they cannot break. Security hardening by over customizing. Alright, the third dimension talks about observability. Right. Observability is one of the most powerful predictors of incident reduction, right? It tells you what happened, why it happened, where it happened, and what it touched. So observability spans across these four layers. Application instrumentation, which is all about, you know, code level behavior and application logic, execution, infrastructure, telemetry that talks about system level patterns, revealing source usage and performance indicator. Security event aggregation, that all these logs that come from scanners identity system and the correlation across these distributed systems. And the last one is trace propagation, which is all about understanding attack paths across these microservices. But what are the security benefits behind, you know, implementing a robust observability platform? Well, it gives you earlier detection. You can catch these anomalies before they become breaches, and everyone wants to do that, right? The second one is faster investigation. It's all about, you know, reducing your mean time to detect your mean time to remediate, and these containment time so that you are investigating as fast as possible and you're reducing your SLA or you do reducing your turnaround time because that all. Has a business impact. The third one is control validation. You empirically see what guardrails are walking, validating those security control effectiveness through empirical measure measurements. And the last one is continuous learning. Learning from the past incidents through post mortem analysis. 'cause every incident becomes a source of this pattern based improvement. So strong observability isn't optional. It's foundational. So the first dimension that I talked about in the previous slide is security guardrail, adherence. Guardrails generally fall into these three categories, preventative detective and corrective. But the real differentiator here is the maturity. High performing organizations don't just create cartridge. They are operationalizing it so that leadership enforces them consistently. These the exceptions are clear and controlled. The signals are continuously refined and the feedback loops are integrated into development workflows. When guardrail adherence is high, security becomes the fastest path, not the slowest. So now that we have talked about all these four dimensions of the framework, let's talk about the methodology and you know, measuring what matters. So our measurement approach uses a layered data collection architecture. Why layers? Because each dimension needs a different data source. Monitoring tools, repost, storing configuration. Logging and tracing platforms, scanning engines, and policy frameworks. All these have different data sources, so automation is non-negotiable. Manual processes create inconsistency and they don't scale. So we also incorporate data quality validation because missing or incomplete data often reveals infrastructure issues that we didn't know we had. Right. So automated collection priority and data quality validation are the two main concepts to prioritize here. Now, when we talk about establishing thresholds, what we want to avoid is one site, one size fits all number. Instead, we created three performance tiers, baseline meaning foundational health target. Meaning competitive performance and excellence, meaning industry leading outcomes, which is where industry leader performance achieved by top performing organizations. So the key principle here is thresholds must remain stable over time. Only then can an organization truly understand improvement versus fluctuation. Let's talk about some of the different industries that adapted these, this framework to their unique constraints. Healthcare where security intersects with patient safety, custom guardrails for medical device and data needed, and there's a significant compliance lift as well in retail. There's elastic infrastructure that is needed with high seasonal velocity. Payment systems are required with restricted thresholds. Now, when you, when it comes to financial services, that's where like the most advanced customization governance lives, and there's a heavy emphasis on resilience and regulatory stability. Last but not the least, we also looked at manufacturing industry where. IT Convergence creates special safety critical requirements and guardrails had to account for legacy systems and long deployment cycles. This cross-industry validation demonstrates the framework's flexibility and robustness. So what were some of these measurable results? Uh, when we wanted to quantify our impact? Right. The organizations that implemented all four dimensions saw very powerful and tangible outcomes. Actually, there was a major reduction in successful attacks. There's a stronger operational resilience across the board, faster and cleaner incident responses with shorter release cycles, and there's fewer production defects that coupled with optimized resource optimization utilization. And increased developer trust, right? These were not just theoretical results, they were real measurable improvements based on using this framework. Now, how do you get started on this, uh, on, you know, implementing this framework? Right? The first thing to do here is doing a baseline assessment. Understand your starting point, right? Conduct a comprehensive assessment of all these four dimensions and establishing starting points in each of these areas. The second one is stakeholder engagement. Align your stakeholders from various, um, cross-functional teams, including security development, operations, product, and establishing those regular health review forums for cross-functional collaboration and strategic planning. Capacity development, build that statistical literacy, those RCA, the root cause analysis skills, right? And develop these specialized DevSecOps health roles and champions across the company. Then you get into the phased implementation aspect of it. Begin with platform efficiency and security guardrails for quick wins. Those are essential and you need to build upon them. Then progress to customization, resilience, and observability, which require a little bit more of instrumentation. In terms of tool integration, keep it simple. Leverage existing tools that you currently have. Start by what you already have, and less is more. In this case, continuous improvement. That's all about establishing your regular review cycles. Uh, to assess the framework's effectiveness. If you need to tweak something, maintain that governance process, ensuring regular evolution of version control. Ultimately, the DevSecOps Health Framework represents a paradigm shift, the shift conversion, the, the shift con. This shifts conversations from opinions to data. From reactive firefighting to proactive prevention and from siloed metrics to holistic health. Looking ahead, this framework will also start to incorporate AI driven operations, confidential computing, third party risks, supply chain security, and other things like that. So this journey towards DevSecOps Health Excellence begins with honesty, gains momentum through discipline, and sustains itself through evolution. The question is in whether to pursue this or not. It's how fast your organizations can start with this. So thank you. Thank you for your time and attention. I hope this session empowers you to rethink DevSecOps Health holistically and strategically. I.