AI
Over-Restriction Creates the Insecurity It Tries to Prevent
Tight security controls don’t eliminate risk. They redirect it. Bangser described screenshots of proprietary code sent over unsecured channels because secure Slack channels weren’t shared across organizations and email was blocked. The code left the building anyway, without audit trails. You wind up with more insecurity when you lock down to a point where people can’t do their jobs.
Security teams are incentivized to prevent incidents. The surest way to prevent incidents is for no work to happen. That misalignment, not malice, produces the shadow IT problem.
Platform Engineering as Security Delivery
DevOps handed every team full-stack ownership, including security, which left individual developers running CVE scans and writing access policy as a side job. Bangser’s argument: platform teams should absorb the generalized requirements, dependency scanning, standard base images, while application teams keep the domain-specific decisions only they have context for.
The failure mode is the platform as enforcer. Cummins flagged two anti-patterns: the platform as rule-keeper rather than capability-provider, and leaky abstractions that force developers to fight through every layer to make progress. Done right, the platform shortens the stack a developer has to reason about.
The Broken Supply Chain and the CVE Noise Problem
Open source supply chain security has no clean answer. Mouat pointed to npm incidents as a recurring pattern and flagged a specific dysfunction: curl maintainers spend real working hours answering junk CVE reports with no security basis, time pulled directly from fixing actual bugs. Mouat called the CVE system “very broken” and predicted sustained industry focus on open source verification without offering a timeline.
The panel also challenged shallow security training. Reading the OWASP Top 10 creates false confidence against deeper attacks. Labeling someone the team security expert because they read a few blog posts is its own risk.
Shared Responsibility Contracts Between Teams
Bangser’s build-or-don’t-build rule: a custom platform pays off only when a requirement is unique to the organization AND shared across multiple teams. Her Kratix-based approach starts at the most minimal internal API and adds composable layers, so teams get lower-level access as their needs grow.
Cummins argued for applying AWS’s shared responsibility model internally. AWS states what it covers (physical, networking) and leaves OS patching to the customer. Internal platforms have no such contract. Without one, nobody can safely bump infrastructure they don’t own, security debt compounds, and Google’s Richard Soder “shift down” article names the same gap.
Q&A
Companies banning AI tools — does that actually improve security? Mouat argued banning drives underground use, where employees send company data to personal ChatGPT accounts with no data protection; buying enterprise licenses with no-train agreements is the better control. ▶ 40:31
What’s the take on SSL inspection — running all traffic through a box that decrypts and re-encrypts it? Mouat noted Cloudflare already does this for static sites and called it a centralized man-in-the-middle, with no clear recommendation offered before time ran out. ▶ 42:26
Notable Quotes
wind up with more insecurity when you Abby Bangser · ▶ 7:38
security is definitely the worst subject Holly Cummins · ▶ 4:42
the CVE system is very broken Adrian Mouat · ▶ 20:17
Key Takeaways
- Over-restrictive security controls drive shadow IT workarounds that expose more data than the original policy prevented.
- Platform engineering works when it centralizes access to security tooling without centralizing control over what teams build.
- Internal platforms need explicit shared responsibility contracts so security updates can be applied without breaking application teams.