San Antonio has always understood how to draw people toward a center. The River Walk does it with water, stone, shade, and movement. The city does it at a larger scale, welcoming roughly 40 million visitors a year to the Alamo, missions, museums, parks, caverns, the Pearl, and the long list of places that make the city feel both historic and alive. Each traveler visits in search of something that only this Texas town offers. That attraction toward wonder and greater understanding carried through those of us who gathered for BSides San Antonio 2026.
Over 400 attendees gathered together for a day full of community and learning about the latest best practices and real world experiences in securing our applications and organizations. This year saw 36 presenters give sessions on topic across 4 tracks, spanning 3 buildings of the St. Mary's University campus, along side five workshops, various villages, and CTFs.
Here are just a few notes from this 13th edition of BSidesSATX.
Runtime Is Where Secrets Go To Hide
Hemanth Gorijala, Security Researcher, presented "Secrets That Survive Everything: Finding Runtime Credentials in Production Web Applications," where he explained a gap that every application security team should care about. His research uncovered the fact that a production app can leak secrets even when the repository, pull request checks, static application security testing, and CI/CD scans all come back clean.
His core example followed an Azure AD and API Management architecture where a browser talks to an API gateway, which then reaches a backend API through a service principal. If an attacker recovers the right values, the attacker can "become the application," with every permission that service principal was granted. That is a different class of risk than a user session getting abused. The credential carries the application’s authority.
Hemanth traced the path from “secure enough” tooling to a live secret in the browser, where a team had controls in place. Secret scanning ran in CI/CD. Static analysis ran on pull requests. GitHub security was enabled. All those tools could still report clean because the exposed value appeared later, after build-time injection, CI/CD substitution, lazy chunks, and runtime state entered the picture.
His recommendation was to embrace layered defense across source, pipeline, artifact, runtime, and architecture. Specifically, he said we should research and adopt "backend-for-frontend" (BFF) patterns, secrets managers, key vaults, and artifact scanning, which each catch a different failure mode. Secrets detection has to follow the credentials beyond the commit, into the build, the artifact, and the production paths where attackers are already looking.
Managed Identity Still Carries Trust
The session from Manuel Melendez, Security Researcher at Microsoft, "Stealing Azure Managed Identity Tokens from Serverless Resources," reframed the concept of cloud compromise. Breaches often get described as if the attacker began with admin access. His scenario began with lower access and showed how that can still turn into meaningful cloud control when managed identities are over-permissioned. It was an important lesson that authentication is just half of the IAM question, and the 'what' an identity is authorized to do is just as important to consider.
In Azure, managed identities let resources authenticate to other Azure services without storing passwords in code. They can be system-assigned to one resource or user-assigned across multiple resources. That design reduces secret handling, while still creating an identity with permissions that attackers will value.
The attack paths centered on serverless resources that already run trusted work. Logic Apps handle workflows and HTTP triggers. Function Apps run event-driven code. Automation Accounts execute scripts that often touch administrative tasks. Manuel walked through how an attacker with access to the execution context can request or capture a managed identity token from the workload. From there, the impact follows the permissions assigned to that identity. A token might read Key Vault secrets, access storage, manage Azure resources, or support lateral movement.
The remediation paths that Manuel laid out were straightforward: tighten access to HTTP triggers, avoid anonymous functions, isolate networks where possible, and scope every identity to the smallest useful role. He cited a common cloud anti-pattern, where one Function App identity gets broad contributor rights across a resource group. A safer model separates identities by workload and purpose.
Compliance Works When Operations Can Prove It
“Compliance That Breaks: Why GRC Fails in Practice (and What Actually Works),” from Dustin Cloos, Chief Growth Officer at Taurean, focused on the gap between control intent and control outcome. He used the cobra effect as the opening lesson. A program meant to reduce cobras rewarded people for dead cobras, which led people to breed more cobras. Security programs can create the same kind of failure when they reward the appearance of compliance instead of the behavior the control was meant to produce.
Dustin explained that evidence should prove what you did, not what you could do. A screenshot showing multi-factor authentication is enabled says very little by itself. Authentication logs showing challenges and enforcement over time tell a stronger story. The same principle applies to account reviews, backup testing, and patching programs. Good operations create security, and compliance is the evidence those operations leave behind. Many teams understand the requirement. The real work is turning that requirement into a repeatable process that survives the day-to-day pressure of running the environment.
Dustin also called out where controls usually die. A policy gets written, a procedure gets defined, and an implementation gets built. Then operations and evidence fall behind. MFA has exceptions. Service accounts get ignored. A SIEM is purchased, logs are collected, and nobody owns the process for reviewing alerts or producing control evidence. Tools can support the program, but ownership has to sit with the team. The goal is an environment that continuously demonstrates how it operates. When that happens, audits become a reflection of the work already being done.
Trust Is The Real Attack Surface
If there was a central theme across sessions and conversations at this BSides, it was that attackers do their best work where trust has already been granted. A service principal has permissions because an application needs to work. A managed identity can reach a vault or storage account because the workload needs access. A control looks finished until exceptions, legacy systems, and service accounts quietly reshape the real environment.
Modern security work has to follow trust through the system. The starting point is rarely the whole story. The defender’s job is to keep asking what each trusted path can actually do.
Clean Checks Can Still Leave Dirty Outcomes
Passing a check does not always mean the risk is gone. A repository can scan clean while a production bundle still exposes a credential. A compliance control can exist while any evidence is thin. A security platform can collect logs, but no process turns those logs into action. A cloud service can behave exactly as designed while an attacker uses that normal behavior for persistence, exfiltration, or lateral movement.
Security has to reach past the checkbox and into operations. Controls need enforcement. Evidence needs to prove real activity. Detection needs context. The goal is an environment that can continuously show how it is working, where it is weak, and what changed when risk appeared.
Understanding The Human Layer Is Vital
Under the technical conversations was a consistent human theme. The work we do in security depends on curiosity, courage, accountability, and belonging. People need the confidence to ask why a control exists, how an identity is scoped, where a secret appears, and who owns the response. They also need teams where surfacing uncertainty is treated as a strength to be celebrated.
Tools can multiply good operations when implemented well, but they can also multiply confusion when no one owns the outcome. The difference often comes down to people who are willing to learn in public, share what they know, challenge assumptions, and help others get better. Security knowledge grows fastest when it moves through the community.
Go Find The Room Where You Get Better
Security cannot be carried by one person, one product, or one "perfect" control. The systems are too connected. The trust paths are too layered. The work changes too quickly. Your author was able to share a talk specifically about this rapid evolution and how we need to rethink identity for agents and all workloads. That change is going to take more than technical updates; it will take a shift in how people view the applications they build. And we can get there, together.
Go find the community that helps you keep up and prepare for the future. Join the local meetup. Attend the regional conference. Ask the question after the talk. Volunteer when you can. Share the thing you learned the hard way.
Security gets stronger when people compare notes, test assumptions, and build relationships before the incident. We need each other for the technical answers, and we need each other for the courage to keep doing the work when the answers get complicated.
