I walked into BSides SF 2026 — theme: "The Musical" — expecting stickers and war stories. I walked out with a thesis: three booths — one Gold, one Silver, one Bronze — mapped the entire modern security stack from package registry to browser tab.
### The MusicalBSides SF 2026 drew 139 sessions, 155 speakers, and 50+ sponsors to City View at Metreon — and sold out every sponsorship tier.
BSides San Francisco runs the weekend before RSA Conference, and it's the anti-RSA in the best way. Where RSA costs $3,000 and fills Moscone with enterprise sales theater, BSides costs $100 and fills the Metreon with people who actually break and build things. The 2026 theme was "The Musical" — talks framed as performances, the evening party leaning into the metaphor. The floor was dense. Fifty-plus sponsors across Gold, Silver, Bronze, and category tiers. Sticker tables you could spend an hour at. A 48-hour CTF sponsored by Upwind. Graphic recordings by Webflow capturing talk highlights in real-time. Calming kits from Embed Security for neurodiversity. It was a community event — volunteer-organized, non-profit, and somehow still landing speakers from Anthropic, Netflix, OpenAI, Cursor, Google, and the EFF. I spent two days walking the floor, photographing booths, sitting in talks, and talking to anyone who'd let me record them. Out of everything I saw, three conversations crystallized a thesis about the modern security stack. ### Socket: The Package Registry GuardianSocket's threat engine catches malicious packages within minutes of publication across 10+ ecosystems. $65 million in funding, 10,000+ organizations, and the Lazarus Group on their radar.
I stopped at the Socket booth on Saturday. They were a Gold sponsor with a prime spot inside City View at Metreon, and the rep walked me through their platform for nearly eight minutes while I recorded. Socket's pitch starts where traditional SCA tooling stops: known vulnerabilities. Their engine goes after the unknowns — malicious packages, typosquats, supply chain attacks that haven't been CVE'd yet — across ten-plus ecosystems including npm, PyPI, Maven, Go, Ruby, Cargo, and NuGet. AI plus deterministic rules checking 70-plus behavioral signals on source code and metadata the moment a package is published. Their engine flags a malicious package within two to six minutes of upload. When Socket researchers documented the StegaBin campaign — 26 malicious npm packages using steganography and Pastebin for payload delivery — they flagged the first package within two minutes of publication.| Capability | How It Works |
|---|---|
| Threat Engine | Real-time analysis across 10+ ecosystems — 70+ behavioral signals via AI + deterministic rules on source and metadata |
| Socket Firewall | Ephemeral proxy on developer machines — intercepts package downloads, blocks known malware before installation |
| Reachability | Reduces CVE noise 80-90%+ by identifying which vulnerabilities are actually callable in your app (powered by Coana acquisition) |
| Socket Patches | For CVEs with no upstream fix — patches the vulnerability without changing package functionality |
DryRun processes 250,000 code reviews monthly, claims an 88% SAST benchmark detection rate, and lets you write security policies in plain English.
I tried to record an interview at DryRun's booth — met both co-founders, James Wickett and Ken Johnson — but the file came back corrupted. Doesn't matter. I grabbed their holographic sticker — the best conference swag I collected — and stayed for a demo that did all the talking the recording couldn't. Wickett and Johnson are both DevSecOps veterans with deep roots in the AppSec community. Their thesis: with AI generating more code than ever, traditional SAST tools can't keep up. Static analysis rules were written for human coding patterns. AI-generated code looks different, and it breaks different. Their answer is a Contextual Security Analysis engine — AI-native, designed to understand not just the syntax of code changes but their behavior and execution context. According to DryRun's own benchmarks (internally tested, not independently audited), their engine hits an **88% vulnerability detection rate** — tested against four traditional SAST tools: Semgrep, Snyk Code, CodeQL, and SonarQube. The closest competitor caught 46%. They process over 250,000 code reviews monthly. The feature that stopped me was **Natural Language Code Policies**. Instead of writing regex-based SAST rules or learning a vendor's DSL, you write security policies in plain English. "No API endpoint should accept user-controlled input without authentication checks." "All database queries must use parameterized statements." DryRun's engine enforces these across every pull request. Security teams skip the SAST rules and write what they actually mean. Two other things stood out. First, their **Code Insights MCP** — an MCP server that embeds DryRun's security intelligence directly into AI coding agent workflows. When Claude Code or Cursor generates code, DryRun's security context is available as a tool the agent can call. The agent checks its own work against your security policies before it even opens the PR. This is the kind of agent-native integration I wrote about in [The Night Agents Took the Stage](the-night-agents-took-the-stage.html) — not an afterthought, but a first-class participant in the AI-assisted development loop. Second, their **DeepScan Agent**, launched in February 2026. Full-repository application security reviews that complete in hours instead of the weeks a manual assessment would take. The founders told me the standard platform runs per-seat pricing; DeepScan adds a usage-based consumption model on top. All of this on roughly $11 million in total funding, per the founders. And the timing is sharp. Two weeks before BSides, DryRun published their Agentic Coding Security Report — testing Claude, Codex, and Gemini building real applications. The finding: **87% of AI-generated pull requests introduced at least one vulnerability**. Broken access control was the most universal issue. If you needed a thesis for why AI-native code review matters, DryRun wrote it. The dual sponsorship — Silver booth plus lanyard — is a serious community investment for an early-stage company. But when your product is "security review for every PR," a conference full of security engineers wearing your brand around their neck is exactly the right play. ### C|Side: The Last MileC|Side is a JavaScript hypervisor — a proxy layer that intercepts every third-party script before it reaches the browser. VPN detection, agent detection, PCI DSS automation, all on $7.7 million.
I caught C|Side founder Simon at their booth in the sponsor hall. They were a Bronze sponsor — small booth, small team, about two years old. But the technical depth of what they're building is disproportionate to their size. Simon Wijckmans founded C|Side (cside.dev) after managing client-side security products at Cloudflare, where he watched Magecart attacks evolve faster than the tools built to stop them. He's Belgian, under 30, and on the Forbes 30 Under 30 Europe list. Simon walked me through the architecture at the booth, starting with a name that stuck: a JavaScript hypervisor. C|Side's core is a proxy-based interception layer. A single script tag loads first in your HTML head. It rewrites every third-party script URL to route through C|Side's proxy infrastructure. Before any script reaches the browser, C|Side's self-hosted LLMs analyze the payload — deobfuscating it, classifying intent, and flagging anything malicious. The proxy adds 8-20ms of latency for dynamic scripts; static scripts are cached at their edge. The result, per C|Side's own documentation: complete visibility into what your users actually receive. The PCI DSS angle is what makes this enterprise-ready. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 — mandatory since March 2025 — require complete script inventories on payment pages, integrity verification for every script, and change-and-tamper detection at least weekly. C|Side automates all of it and goes further: continuous monitoring instead of weekly scans, plus tracking 14 security-impacting HTTP headers when visitors hit payment pages. What surprised me was the VPN detection. Most VPN detection services maintain lists of known exit node IPs and check against them. C|Side does multi-layered analysis across OSI layers 3, 4, and 7 — browser fingerprints, device characteristics, network packet behavior, and timing discrepancies. They look for the actual indicators of VPN infrastructure within the request itself, not just known IP addresses. "It's not a list," Simon told me. And given that any motivated user can spin up a fresh VPN endpoint not on any list, that distinction matters. The most interesting part of the conversation was about strategy, not technology. I mentioned that putting detection on a WAF makes it obvious to attackers when they're caught — leading to the eternal cat-and-mouse game of rotating fingerprints and IPs."If you make it a quiet, silent failure somewhere in the app — or it's a signal to your fraud detection in the backend — you tend to have better results."Instead of throwing a 403 and telling the attacker exactly what caught them, you let the request proceed into a dead end. The attacker thinks they succeeded. Your fraud system has already flagged them. No arms race. No fingerprint rotation. Just a quiet signal and a closed door. C|Side is architecturally fail-open by design — if their proxy goes down, scripts load directly from their original sources. Their tooling never becomes the reason a site breaks.
| C|Side Capability | How It Works |
|---|---|
| JavaScript Proxy Layer | Rewrites third-party script URLs through C|Side's edge — self-hosted LLMs analyze every payload before it reaches the browser |
| PCI DSS Automation | Script inventory, integrity verification, continuous change detection — requirements 6.4.3 and 11.6.1 (mandatory since March 2025) |
| VPN Detection Engine | Multi-layered analysis across OSI layers 3, 4, and 7 — fingerprints, device characteristics, packet behavior, timing |
| Agent Detection Toolkit | Identifies agentic browsers (Comet, ChatGPT Atlas, Manus) via timing patterns, fingerprint mismatches, and known LLM platform signals |
| Fail-Open Architecture | If the proxy goes down, scripts load directly from original sources — 99.99% uptime SLA |
| Layer | Company | What They Watch | Sponsor Tier |
|---|---|---|---|
| Package Registry | Socket | Open source packages at install time | Gold |
| Code Review | DryRun Security | Pull requests and AI-generated code | Silver + Lanyard |
| Browser Runtime | C|Side | Client-side scripts, bots, and VPNs | Bronze |
| Layer | How the LiteLLM Attack Touched It |
|---|---|
| Package Registry | Backdoored package published directly to PyPI — the install-time interception point |
| Code Review / CI | Entry point was a compromised security scanner (Trivy) inside the CI/CD pipeline |
| Agent Runtime | Discovered when an MCP plugin in Cursor pulled the poisoned package as a transitive dependency |