Sai Sravan Cherukuri
Open Source Enthusiasts and DevSecOps Architect
Actions
Sai Sravan Cherukuri is a visionary technology leader, DevSecOps Technical Advisor, PaaS Automation Lead, and Program Manager. With over 20 years of experience in federal IT transformation, he is a recognized expert in DevSecOps, FinOps, AI governance, CMMC readiness, Infrastructure as Code (IaC), open-source advocacy, and Policy as Code (PaC). He is the creator of the FIBER AI Maturity Model and contributes as a member to the national AI safety initiatives through NIST’s U.S. Artificial Intelligence Safety Institute Consortium.
Sai Sravan, a Commissioner’s 2024 Award recipient, has led enterprise-scale automation, modernization, and capacity planning initiatives that deliver measurable results. He serves on the Board of Directors at TMMi America and is a dedicated community mentor and volunteer.
As a Platform Engineer and Open-source advocate, Sai is committed to advancing accessibility in engineering and inclusivity in the community. He is a strong proponent of the "Docs-as-Code" movement, maintaining that long-term project sustainability relies on clear documentation and automated CI/CD pipelines that lower barriers for contributors. Currently, he is bridging the gap between agentic workflows and cloud-native standards; as an active explorer of the Model Context Protocol (MCP), he utilizes OpenTelemetry to build open-source AI observability frameworks, enabling the scaling of reliable, self-service agents.
Sai Sravan currently serves as the program lead for the application team, spearheading the institutionalization of Infrastructure as Code (IaC) through Terraform practices.
Badges
Area of Expertise
AI Runtime Integrity: Detecting Unauthorized Changes in Linux AI Serving Stacks with eBPF
AI inference services on Linux are becoming complex runtime systems. A single vLLM or SGLang deployment may load model weights, tokenizers, LoRA adapters, shared libraries, CUDA components, Python packages, containers, and GPU kernel modules. These changes often happen below the application layer, where traditional AI security controls have little visibility.
This talk presents an open-source prototype for runtime integrity monitoring of Linux AI serving stacks using eBPF. The tool monitors model and shared library loads, suspicious file replacements, container executions, and selected kernel module activity for inference frameworks such as vLLM, SGLang, and PyTorch.
The goal is to show how Linux kernel observability can detect unauthorized runtime drift in AI infrastructure before it becomes a silent production risk.
Beyond Dashboards: Building Operational Intelligence for Open Source AI Infrastructure
Modern AI systems expose thousands of metrics, yet operators still rely on manual dashboard inspection during performance incidents, capacity planning exercises, and production outages. As AI infrastructure grows in complexity, raw telemetry alone is no longer sufficient.
This session introduces KVScope, an open source observability and diagnostics framework designed to transform low level AI infrastructure metrics into actionable operational intelligence. Rather than simply displaying dashboards, KVScope analyzes runtime telemetry and identifies meaningful operational states such as queue pressure, resource saturation, throughput degradation, latency spikes, and recovery patterns.
Using real world LLM serving workloads as a case study, we will explore how metrics can be normalized, correlated, and converted into timelines, events, and human readable narratives that explain what is happening, why it is happening, and what operators should investigate next.
Attendees will learn practical techniques for building intelligent observability systems, improving incident response, and operating modern open source AI infrastructure with greater confidence and efficiency.
Beyond Dashboards: Operational Reasoning for LLM Inference Systems
Large language model serving systems expose hundreds of metrics, but operators are often left interpreting dashboards manually during incidents, performance regressions, and capacity planning exercises.
This talk introduces KVScope, an open-source observability and diagnostics framework for LLM inference systems built on the PyTorch ecosystem. KVScope attaches to running inference servers, collects runtime telemetry, and converts low-level metrics into operational narratives that explain what is happening, why it is happening, and whats next
Using vLLM on NVIDIA H200 infrastructure as a practical case study, we demonstrate how signals such as KV cache utilization, scheduler backlog, throughput, TTFT, TPOT, and request concurrency can be transformed into higher level operational states including queue pressure, KV cache pressure, saturation, throughput collapse, and recovery.
The session covers metric collection, state modeling, timeline construction, event detection, narrative generation, regression analysis, and forecasting techniques. We also discuss how the architecture extends by an abstraction layer designed for future support of frameworks such as SGLang and TensorRT.
Energy Aware LLM Serving: Open Source Configuration Search for Faster, Cheaper, and Green Inference
Open source LLM serving has become fast, but not always efficient. Teams often tune vLLM, SGLang, TensorRT-LLM, and OpenAI-compatible servers for maximum tokens/sec, then discover later that the chosen configuration wastes power, raises cost, or misses a better deployment tradeoff.
This session presents Serve Optimize, an open source approach to energy aware LLM inference tuning. It detects the available GPU or MIG slice, generates feasible serving candidates, runs controlled workloads, collects power telemetry, and compares configurations using tokens/sec, p95 latency, average watts, joules/token, and tokens/watt. Instead of producing another benchmark table, it builds a Pareto frontier and recommends an operating point for the user’s goal: maximum throughput, lowest latency, lowest energy per token, best tokens/watt, or balanced performance.
The talk will focus on the reusable open source design pattern: hardware detection, candidate pruning, benchmark orchestration, telemetry, reproducible artifacts, and goal-aware recommendations. Attendees will leave with a practical method for making self-hosted AI inference measurable, repeatable, and power-aware.
Measuring Platform Maturity for the Agentic Era: A 7-Dimension Open Framework
Three years ago, I started noticing a pattern. Platform teams had done serious work on service catalogs, golden paths, and automated pipelines. But when AI agents entered the picture, the honest answer to "Is your platform ready for this?" was almost always no. And the harder part was that nobody had a clear way to measure how far they had to go.
So I built one. This session walks through a seven-dimensional maturity framework for platform engineering teams, covering documentation, API and tooling quality, CI/CD, observability, safety guardrails, zero trust, and FinOps. Each dimension scores on a four-level scale. The model is grounded in existing standards: NIST, OpenTelemetry, DORA, and CNCF working group outputs, nothing invented from scratch.
Attendees receive a scored picture of their own platform, a ranked improvement roadmap, and a percentile rank relative to other organizations. The framework, scoring model, and research paper are fully open source.
Regulation-as-Code: Open, Executable, and Auditable Reporting Pipelines for Financial Services
Financial institutions repeatedly interpret the same regulatory texts, translate them into internal requirements, map them to data fields, implement validation rules, build controls, and generate audit evidence. This work is duplicated across banks, broker-dealers, exchanges, vendors, and infrastructure providers.
This session proposes an open-source Regulation-as-Code framework for turning approved obligations into executable, versioned, testable, and auditable reporting pipelines. The lifecycle includes source text ingestion, obligation extraction, human review, rule definition, standards-based mapping, deterministic validation, report generation, evidence creation, submission readiness, and change monitoring.
The talk focuses on open infrastructure, not black-box AI. AI may assist with obligation discovery and change detection, but final rules remain human-reviewed, version-controlled, deterministic, tested, and auditable.
Attendees will see how this can interoperate with FINOS CDM, ISDA DRR, XBRL, ISO 20022, data catalogs, and existing submission systems to reduce duplicated compliance work while improving transparency, auditability, and regulator confidence.
Runtime Drift Is a Security Signal: Building a Continuity Ledger for Cloud Native Evidence
Security incidents in cloud-native systems rarely begin with a single obvious event. They often emerge through drift: a service account gains new permissions, a pod restarts with a different image digest, a policy exception is approved, a secret is rotated, or an emergency deployment bypasses the normal path.
Introduces a Security Continuity Ledger: an append-only evidence timeline that integrates identity, workload, policy, runtime, and supply chain events into a single investigation-ready view.
Demo how teams can combine Kubernetes audit logs, admission controller decisions, RBAC changes, image signing metadata, SBOMs, vulnerability scan results, runtime detections, and incident annotations to answer: did the system drift from its intended security posture?
It focuses on open patterns, not vendor tooling. Attendees will leave with a practical model for turning fragmented security data into durable evidence for incident response, audit readiness, and safer platform operations.
The Invisible Attack Surface: Securing the Linux AI Inference Supply Chain
The Invisible Attack Surface: Verifying the Linux AI Inference Supply Chain from Kernel Modules to Model Weights:
Modern AI inference servers on Linux are no longer a single application. A typical vLLM or SGLang deployment depends on the Linux kernel, GPU kernel modules, CUDA, NCCL, PyTorch, Triton, container images, model weights, tokenizers, and optional LoRA adapters. Each layer is part of the runtime trust chain, but today most operators cannot prove what is actually running once the service is live.
This talk presents an open-source prototype for AI inference supply-chain verification on Linux. The system generates an AI-aware SBOM, records runtime provenance, verifies OCI image signatures with Sigstore and cosign, checks model weight hashes, inspects GPU kernel modules, and detects tampered artifacts in a live vLLM deployment.
The goal is simple: extend Linux supply chain security practices to the AI inference stack, from operating system components to model artifacts.
Serve Optimize: Energy Aware Configuration Search for PyTorch LLM Inference
LLM inference is often tuned for maximum throughput or lowest latency, but those settings can waste power or miss better deployment tradeoffs. This talk presents Serve Optimize, an open-source optimizer for PyTorch ecosystem serving stacks, starting with vLLM, that searches for energy aware LLM serving configurations.
Serve Optimize detects the available GPU or MIG slice, generates feasible backend candidates, launches or attaches to OpenAI-compatible inference servers, runs controlled workloads, collects power telemetry, and ranks configurations using throughput, p95 latency, average watts, joules/token, and tokens/watt. It then builds a Pareto frontier and recommends an operating point for a selected goal: maximum throughput, lowest latency, lowest energy per token, best tokens/watt, or balanced performance.
The session will cover the architecture, measurement methodology, candidate search strategy, and a case study on workstation and MIG based GPUs. Attendees will leave with a practical pattern for making LLM inference tuning reproducible, measurable, and power aware rather than relying on benchmark defaults.
The Platform That Remembers: Building a Continuity Ledger for Cloud Native Operations
During peak traffic, platforms rarely fail in one clean moment. They degrade through a chain of small events: a node reboot, a pod restart, a deployment rollback, a manual fix, a missed alert, or a service that recovers but leaves no clear explanation behind.
This talk introduces a practical pattern called a Performance and Continuity Ledger: an append-only operational timeline that integrates Kubernetes events, Prometheus metrics, OpenTelemetry traces, GitOps changes, CI/CD metadata, and incident notes into a single source of context.
Using a realistic peak-season infrastructure scenario, such as repeated server reboots during tax filing season, we will show how platform teams can move beyond dashboards and build a platform memory that answers: what changed, what broke, what recovered, and what still needs to be fixed.
It is an open-architecture pattern for making cloud-native platforms more explainable, resilient, and easier to improve after real incidents.
We gated our releases and stopped the 3 AM scramble
Every team has some version of this moment: a high-stakes period is two weeks away, a big launch, a busy season, a hard deadline, and someone pulls up a spreadsheet and asks, "Are we actually ready?" And the honest answer is: nobody really knows. You piece it together from whoever remembers the last incident, a few Slack threads, and a general sense of optimism.
This talk is about how I got tired of that moment and built something to make it go away.
I'll walk through how our team built a way to continuously score every service's health and recovery readiness so that by the time peak season arrives, we already know exactly where the risk lies. Not because we're watching better dashboards, but because we built governance into the process before anything ships.
The idea borrows from what DevSecOps figured out years ago: catching a problem at commit time is a hundred times cheaper than catching it at 3 AM during your busiest week. We applied that same thinking to performance and resilience. Every service gets a health score based on real signals: error rates, latency patterns, test reliability, regression history. If a service scores too low, the release is blocked. No exceptions, no manual override without a paper trail.
I'll talk about what broke before this worked, including the organizational pushback, the false confidence that comes from "we have monitoring," and the difference between knowing something is broken and having a process that prevents it from shipping in the first place.
I won't pretend this is a solved problem. But I'll give you a framework you can take back to your team on Monday, regardless of your stack.
(A working demo of the scoring and gating system is available on request- The Performance and Continuity Ledger.)
Your Developer Portal is Lying to You — Because You're Building a Platform, Not a Product
Every platform team has the same graveyard: a portal full of outdated docs, dead links, and tutorials that were accurate at some point in 2022. Engineers stop trusting it. They Slack someone instead.
We blame the tooling. We blame the writers. We run doc sprints. Six months later, the graveyard grows.
The uncomfortable truth: the portal isn't broken. The approach is.
Platform teams think in systems, services, and SLOs, not about real developers who'll bail the moment your golden path costs more time than it saves.
This talk treats the portal as a symptom. The real problem is platform teams that ship infrastructure rather than build products. We'll get into what that shift looks like: talking to developers like a PM, building adoption metrics that matter, and writing roadmaps that stakeholders outside your team actually care about.
This isn't a talk about portals. It's about what happens when a team starts asking, "Would someone choose this?" instead of "Did we ship it?"
The Sleeping Pill: How Attackers Hide Inside Your Systems, Pass Every Test You Run, and Activate on
The most dangerous attack on your systems will never show up in a penetration test report. It will pass your internal validation. It will pass third-party auditing. It will perform flawlessly in production — until a specific, precisely engineered trigger is met. Then it will fail in a targeted, controlled way. Against a specific target. On command. With no trace.
This session presents original research into how hidden backdoors are planted during the customization phase of enterprise software — and survive every form of testing organizations currently rely on. The backdoor is invisible during normal operation. It wakes up only when a specific combination of conditions appears in an ordinary-looking request. Nothing in standard security tooling catches it.
This is not an exotic edge case. It describes exactly how most organizations are building and deploying these systems right now: a company takes an off-the-shelf base product, trains it on proprietary internal data to customize it, runs their standard checks, and ships it to production. The Sleeping Pill is planted during that customization step — through a compromised data source, a malicious insider with access to the training environment, or a third-party vendor handling the customization work — and then it waits.
The consequences are concrete. The system steers a specific financial transaction toward fraud, but only when a specific account triggers it. It leaks proprietary information to an outside destination, but only when the request comes from a specific location. It produces outputs that violate regulatory requirements, but only in specific jurisdictions, on command.
The live demonstration in this session shows the full attack chain — how the backdoor survives compression, security review, and standard red-team testing — and what it looks like when it activates. The second half presents a practical defense framework: what your current tooling can and cannot catch, which monitoring approaches provide real coverage, and a pre-deployment checklist that meaningfully reduces your exposure without requiring a specialist team to implement it.
Learning Objectives
Understand how a hidden backdoor planted during the customization of a system survives the entire deployment process — including testing and auditing — and arrives in production undetected
Identify the specific points in your organization's build and deployment process where this kind of tampering can be introduced
Apply a pre-deployment checklist that goes beyond standard security testing to surface dormant, trigger-based behavior before it reaches production
Build a monitoring approach that creates visibility into whether your systems are behaving consistently — or selectively failing under specific conditions
Evaluate third-party vendors who handle system customization or training against a concrete set of supply chain security criteria.
Note: his talk has not been presented at any prior event
The Attack That Passed Every Check: How Adversaries Learned to Hide Inside Legitimate Infrastructure
In early 2026, a campaign called EvilTokens quietly moved through federal agencies and enterprise environments. No malware. No exploited vulnerability. The attacker used Microsoft's own OAuth device code flow, a completely legitimate authentication mechanism — to steal session tokens directly. This bypassed both passwords and multi-factor authentication. The tokens lived for up to 90 days and survived password resets. Security tooling saw nothing wrong because, technically, nothing was wrong. It looked like a normal login.
That gap is what this talk is about.
There is a growing class of attacks built specifically to look legitimate. They do not trigger rules because they do not match known malicious patterns. Threat intelligence cannot flag what has never been documented. And by the time the attack is understood well enough to write a detection rule, it has already succeeded somewhere.
I will walk through the EvilTokens campaign in detail: how it worked, what it bypassed, and why the organizations that caught it caught it while others did not. The organizations that stopped it were not running better rules. They were asking a different question entirely. Instead of "does this match a known threat," they were asking "should this be happening at all for this user, on this device, at this time." That shift, from pattern matching to behavioral understanding, is what actually stopped the attack.
The rest of the talk covers what that shift looks like in practice. What behavioral baseline modeling requires. Where it fails and how to tune it without burying your team in false positives. What the transition looks like for organizations still running legacy detection stacks. And what you should be asking your vendors right now to figure out how exposed you actually are.
Learning Objectives:
Attendees will leave understanding exactly how OAuth device code flow abuse works and why it bypasses MFA. They will be able to identify the class of attacks that signature-based and rule-based defenses cannot structurally catch. They will understand behavioral baseline modeling as a practical detection alternative, not just a concept. And they will have a working evaluation framework to assess their own blind spots before an attacker finds them first.
Note: this has not been presented in any other conferences.
The 4AM Call: A Live Playbook for When Your Automated System Does Something Nobody Authorized
Every CISO in this room has a ransomware runbook. You know who calls whom at 4 AM, what authority you have to pull the plug, how you contain the damage, and where the investigation starts. Not one of you has an equivalent playbook for when your automated system starts doing things nobody told it to do.
This session is about that gap.
Over the past 18 months, a pattern has quietly emerged across enterprise deployments: systems that passed every test, every audit, every review, and then did something unexpected in production. Not a hack. Not a breach in the way anyone would recognize it. A decision. An action. A consequence that landed in the real world before a human being noticed.
This talk builds a first-of-its-kind response playbook drawn from documented failures across financial services, healthcare, infrastructure, and logistics, and runs it live in the room as a tabletop exercise with the audience.
The scenario: your company's automated procurement system has just executed $4.2 million in purchase orders across 17 vendors. Every transaction was technically within your policy guardrails. No outside attacker was involved. The system made a call. The call was wrong. The vendors have already confirmed receipt.
Walk through the actual decision tree: Who has the authority to shut the system down? Is shutting it down a bigger risk than leaving it running? How do you reconstruct what happened and why in a way that holds up to legal and regulatory scrutiny? What do you tell your board in the next six hours?
Attendees leave with a practical, vendor-neutral response playbook they can take back to their organization, a governance authority template that defines who can stop or override an automated system during a live situation, and the uncomfortable clarity that their current incident response plans were written for a different era.
Learning Objectives
Understand the difference between a security breach and an unauthorized system behavior event, and why your current response plan does not cover the second one
Apply a clear first-response decision framework when an automated system produces real-world consequences nobody approved
Define who in your organization has the authority to halt, override, or roll back an automated system during a live situation before you ever need to use it
Reconstruct what a system did and why in a way that satisfies legal, regulatory, and board-level scrutiny
Identify the three most common governance gaps in current enterprise deployments that create this kind of exposure
Note: This talk has not been presented at any prior event.
Quantum-Proof Visibility: Indexing Real-Time Cryptographic Risk with OpenSearch
Nation-state actors are archiving your encrypted traffic today, waiting for quantum computers to decrypt it, a threat CISA calls Harvest Now, Decrypt Later (HNDL). Federal mandates require full post-quantum cryptographic (PQC) migration by 2030. Most organizations have zero real-time visibility into their exposure.
This session demos QVault, an open-source PQC governance dashboard that uses OpenSearch as its analytics backbone. I will show how eBPF-based telemetry that captures TLS handshake algorithms and cipher suites per connection is indexed in OpenSearch in real time, and how OpenSearch aggregations compute a live HNDL Exposure Score across an entire infrastructure estate.
Attendees will see:
- A telemetry pipeline from kernel-level eBPF probes to OpenSearch indices
- Real-time risk scoring using bucket aggregations and scripted fields
- OpenSearch Dashboards panels for CNSA 2.0 and NSM-10 compliance tracking
No agent installation. No code changes to monitored systems. Just OpenSearch is making the invisible visible.
Observability for Agents: Tracking the Life of an MCP Request with OpenTelemetry
As developers move to professional, reliable workflows using agents, unexpected errors that are hard to notice, known as "silent failures," can occur. When a language model interacts with multiple Model Context Protocol (MCP) servers, regular program logs do not show the detailed steps by which the model, the main program, and the tools exchange information.
This beginner-friendly session offers practical skills: learn hands-on ways to watch and fix Model Context Protocol (MCP) interactions using the OpenTelemetry (OTel) toolkit, and follow a request from the first large language model (LLM) prompt through to the last tool in the process. You'll also see each step with OTel, making it easier to find and solve hidden problems and making your workflow more reliable and clear.
1. The "Trace" Mindset: Mapping the request journey across the Open-Source MCP Host, the client, and the server.
2. Standardizing Logs: Implementing structured logging within your OSS MCP servers so they integrate seamlessly with the broader cloud-native ecosystem.
3. Debugging Failures: Identifying latency bottlenecks and prompt injection attempts in tool-calling using OSS telemetry tools.
Ghost Employees: When the Threat Inside Your Automated Workforce Isn't Human
Most security teams are still thinking about this problem the same way: a human attacker on the outside, trying to get in. That threat model is already running behind the actual risk.
Here is what is happening in enterprise environments right now. Companies have built networks of automated software workers :systems that communicate with each other, make decisions, access financial platforms, query internal data, send communications, and execute transactions, continuously, with minimal human oversight. These are not single tools sitting in a corner. They are ecosystems. And ecosystems have entry points.
The threat this session addresses does not look like a breach. No perimeter gets crossed. No password gets stolen. An adversary or an adversary's own automated system, presents itself as a legitimate participant in your workflow. It passes your authentication checks. It operates inside your normal guardrails. And from that position, it quietly steers decisions, redirects outputs, and pulls information outward at a speed and scale no human attacker could sustain.
I’m calling them Ghost Employees.
This talk walks through three real attack scenarios in plain language: a ghost participant injected into a financial services workflow that systematically tilts credit decisions in favor of fraud; an infiltrator inside a corporate research pipeline that routes proprietary work to an outside destination as it is produced; and a compromised security monitoring workflow that is quietly trained to look away from specific attack signatures.
None of these require you to understand the underlying technology. All of them are active risks in production environments today.
The second half of the session gives security leaders a concrete starting framework for building trust boundaries inside automated workflows borrowed from the same zero-trust principles already familiar to this audience, applied to a layer that currently has none. You do not need to rebuild your systems. You need to know where the unlocked doors are.
You will leave with a clear map of where your exposure sits and the language to walk your board through it in under ten minutes.
Note: This talk has not been presented at any prior event
Architecting for Onboarding: Building a "Docs-as-Code" Pipeline for Open Source Sustainability
In open source, a project's survival depends on its contributor funnel. If developers can't build, test, or grasp your project in the first ten minutes, they'll leave. Documentation is the primary interface for that experience, but is often the most neglected part of the repository.
This session goes past the basic README to show how maintainers can set up a clear Documentation Development Life Cycle. We will explore the 'Docs-as-Code' idea, treating documentation like code by keeping it in Git, peer-reviewing it, and checking it with CI/CD pipelines.
Key takeaways include:
The Pipeline: Setting up automated linters (Vale, Markdownlint) to enforce style and technical accuracy.
The Process: Make sure every new feature includes updated documentation to prevent it from becoming outdated.
The Community: Learn ways to help non-coders contribute, and manage docs with people all over the world.
Join this session to learn actionable steps you can implement right away to make your open-source project more welcoming, robust, and future-proof. Start applying these strategies today and transform your documentation process.
Federal Zero Trust: Scaling Sigstore & Keyless Attestation for Linux
As federal mandates like EO 14028 and OMB M-22-18 redefine software integrity, agencies face a critical challenge: how to implement "Zero Trust" without paralyzing the development lifecycle. This session provides a strategic and technical blueprint for modernizing the Linux supply chain in a highly regulated environment.
Drawing on the dual perspectives of a PM and a DevSecOps Technical Advisor, we explore the transition from legacy, manual GPG management to automated, keyless attestation using Sigstore (Cosign/Rekor). We dive into "Day 2" operational realities:
https://github.com/saisravan909/fed-sigstore-blueprint-zero-trust-linux
Policy-as-Code: Translating NIST SSDF into automated controllers (Kyverno) to enforce signature verification.
Identity over Keys: Leveraging OIDC and federal providers (PIV/CAC) to eliminate "key debt."
Auditable Integrity: Using the Rekor transparency ledger as a tamper-proof "Source of Truth" for audits and procurement.
Blueprint for Scale: Navigating friction when moving to a cryptographically verified "Verify-Before-Deploy" architecture.
Attendees will gain a framework for aligning open-source innovation with federal compliance to ensure security enhances mission delivery.
Open Source Summit + Embedded Linux Conference North America 2026 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top