BSides Cleveland 2026: Reducing the Paths Attackers Can Use

Cleveland helped show the world what electric street lighting could become. On April 29, 1879, inventor Charles F. Brush demonstrated 12 arc lamps in Public Square. The successful demonstration attracted international attention and helped establish Cleveland as an early pioneer in electric street lighting. Learn more from Case Western Reserve University.

Almost 150 years later, BSides Cleveland brought another group of technologists together to talk about systems undergoing major change.

BSides Cleveland 2026 took over the Tinkham Veale University Center at Case Western Reserve University on September 26. The Blue Team track covered identity, AI governance, supply chain security, infrastructure compliance, CI/CD, and security operations. Across those topics, one larger theme kept emerging. Security gets stronger when teams reduce dangerous paths before attackers or autonomous systems can use them. View the BSides Cleveland 2026 schedule.

That theme started with hidden administrative access and carried all the way through the final session on using AI inside a SOC.

Ghost Admins Hide Outside Traditional Identity Governance

Craig Birch started the Blue Team track with “Ghost Admins: How Attackers Own Environments Without Touching a User Account.”

Craig defined a ghost admin as a non-human identity or trusted path capable of administrative impact without receiving the governance expected for privileged access. App registrations and service principals can become ghost admins. Managed identities, gMSAs, and abandoned service accounts can create the same problem.

Attackers have learned how to use these paths. Craig walked through five attack scenarios involving app registration hijacking, managed identity abuse, orphaned gMSAs, Service Connection Point manipulation, and Intune policy tampering. Each example showed how trusted infrastructure can accumulate powerful access outside normal human identity controls.

App registration hijacking was a particularly clear example. Someone with sufficient application rights can add a credential to an existing trusted application. That credential lets the attacker impersonate the application and inherit its permissions. The resulting authentication can blend into legitimate machine activity.

Craig's defensive recommendations started with inventory. Organizations need to know which non-human identities exist, what privileges they hold, and who owns them. Credential hygiene and lifecycle management then shrink the number of forgotten paths waiting to become privileged access.

AI Governance Needs Security Triggers Earlier

Elizabeth Wadsworth followed with “Positive Intent Is Not a Control.”

Her talk moved AI security upstream into the decisions that determine what an AI system will eventually be capable of doing. An application team can make consequential security decisions while selecting data sources, connecting external models, or deciding how much authority an agent should receive. Security expertise needs a way into that process before those decisions become architecture.

Elizabeth gave governance teams six useful areas to examine. They need to understand what the system can access and what actions it can take. They also need visibility into its connections and outside influences. Authority and potential consequences complete the picture.

These are security triggers. A governance team does not need to diagnose prompt injection or choose a technical control. It needs enough structure to recognize when IAM, AppSec, security architecture, or another specialist needs to enter the process.

Her recommendation was to turn security expertise into an interface the rest of the AI lifecycle can use. Define entry conditions and escalation paths. Establish required artifacts and reassessment triggers. Security can then reach risky decisions while they are still decisions.

Cybersecurity Fundamentals Still Win

Jerod Brennen brought the conversation back to fundamentals with “The Common Sense Security Framework: Revisited and Revised.”

The Common Sense Security Framework is now ten years old. Jerod revisited it against current security research and found plenty of evidence supporting the original approach. His framework organizes security around governing risk and protecting identities. Devices, networks, and data form another group of core concerns. People, partnerships, and uptime round out the model.

One of the strongest points was his treatment of technical debt. Business leaders use debt strategically all the time. Security debt also needs an owner and a repayment plan. Unpatched systems and skipped hardening steps can compound when that plan disappears.

Jerod also returned repeatedly to defense in depth. Security programs should make it difficult for one mistake to become a damaging event. Endpoint controls can contain a bad click. Tested backups can keep ransomware from becoming a prolonged outage.

His practical recommendations were familiar for a reason. Phishing-resistant MFA, reduced standing privilege, and tested backups solve real problems. Incident response exercises with executives prepare the business for the day those layers are needed.

Removing Dependencies Removes Attack Surface

Jim Ender's “Hardening Supply Chain Security by Pruning JavaScript Dependencies” delivered perhaps the most direct security strategy of the day.

Delete things you do not need.

Jim demonstrated knip, which helps identify unused files, exports, and dependencies in JavaScript projects. He also highlighted the e18e ecosystem cleanup effort, which looks for opportunities to replace bloated packages with smaller alternatives or native functionality.

Developers get smaller bundles and faster builds. Operations teams have less software to maintain. Security teams inherit fewer packages that can become supply chain attack paths later.

That turns dependency removal into a useful security metric. Every safely removed dependency eliminates something that could eventually require investigation or patching. Jim's message fit neatly with the rest of the day. Reducing attackable material can be one of the most effective security controls available.

Security Can Depend on the Path Between Two States

Kavin Muthuselvan took the prevention theme into infrastructure with “Inductive Compliance: Lightweight & Noninvasive Transition-Gating for Declarative Infrastructure.”

Kavin focused on configuration drift and the intermediate states systems pass through during change. A final configuration can appear compliant while the path used to reach it introduced risk. Temporary changes can leave behind dangerous conditions. Rollbacks can also restore sensitive functionality on top of a compromised state.

His model of inductive compliance makes transitions part of the authorization decision. Start from a known compliant state. Allow the local system to apply changes that preserve defined policy. Each transition becomes something the system can evaluate before applying it.

The proof of concept used NixOS and declarative infrastructure. It also explored projected state as a way to verify policy while limiting how much host information needs to be disclosed centrally.

Kavin summarized one of the most interesting ideas of the day in a short phrase: security is path-dependent. Preventing dangerous state transitions gives defenders another option beyond discovering drift after it has already happened.

Zero-Trust CI/CD Reduces Direct Production Access

Shashi Kumar Munugoti continued into deployment security with “Zero-Trust CI/CD: Securing Kubernetes and GitOps Pipelines for Regulated Enterprises.”

Regulated organizations need to move software while producing evidence that changes were controlled. Manual approvals and inconsistent environments make that harder. Excessive production access and weak traceability add even more risk.

Shashi's model followed four stages: declare, verify, reconcile, and observe.

Pull-based GitOps was central to the approach. An agent running inside the cluster reconciles the desired state stored in Git. The deployment path can operate with less direct human access to production and create a durable record connecting changes back to commits and approvals.

The identity model was equally important. Every workload should prove that it belongs in the environment before receiving access. Automation can then enforce policy while preserving the traceability required by regulated organizations.

AI Can Do the Boring Work Without Owning the Decision

Michael Blanchard closed the main run of Blue Team sessions with “The SOC Intern That Never Sleeps: Lessons Learned Using AI for Security Operations.”

His analogy for AI inside the SOC was simple and useful. Treat it like an intern.

AI can read large amounts of material quickly. It can summarize timelines and draft hunting queries. It can also confidently produce the wrong answer while carrying zero accountability for the outcome.

Michael demonstrated AI compressing roughly 20 minutes of context gathering into a couple of minutes. That is useful time savings for an analyst. The system still required verification before anyone escalated, closed, or remediated an incident.

His guardrails focused on making mistakes easier to catch. Ground responses in the available evidence. Require citations back to source events. Give the system room to say when the evidence does not support a conclusion.

“Never automate accountability.”

AI can draft and accelerate the repetitive parts of security work. Humans remain responsible for judgment and consequential decisions.

Move Security Closer to the Action

Your author closed the Blue Team track with “Stop Agents From Leaking Your Secrets: AI Hooks To The Rescue.” The session looked at bringing security controls into the agent workflow itself, close to the moment an AI coding assistant reads files, runs tools, or handles development context.

Security teams will always need detection and response. They can also shape systems so fewer dangerous paths exist in the first place. Inventory what has access. Remove what no longer serves a purpose. Limit authority and put enforcement where decisions are made.

Charles Brush used Cleveland's Public Square to demonstrate a new way to light a city in 1879.

BSides Cleveland 2026 spent a day examining how to safely wire up what comes next.