






















As part of Aikido’s Security Masterclass series, Mackenzie Jackson sat down with Bill Harmer (CISO, Supabase) and Etienne Stalmans (Security Engineer, Supabase) to explore how Supabase approaches security as part of design, not something to bolt on later.
From Row Level Security (RLS) to the risks of AI-assisted coding, the discussion focused on what it takes to build fast and stay secure.
Supabase’s philosophy begins with the data itself.
“We’ve built Supabase from a developer’s point of view. Everything starts with the data. Why build secondary layers when you can control everything in one place.” - Bill Harmer, CISO Supabase
Instead of spreading security logic across services, Supabase brings it closer to where the data lives. The closer the control, the fewer chances there are for things to go wrong.
For Etienne, this approach changes how developers think about building software.
“When you move security closer to your data, you start thinking about it from first principles. Once it clicks, you speed up development and stay confident it’s secure.” - Etienne Stalmans, Security Engineer Supabase
By making data ownership and access part of application design, teams remove the guesswork that comes with layered permission systems.
Supabase keeps access control simple. Users are either anonymous or authenticated, nothing in between.
“All updates on data must be logged, who did what, when, and why. Anonymous users get limited access. Authenticated users get exactly what they need and nothing more.” - Bill Harmer, CISO Supabase
Etienne demonstrated this during the session using a live recipe-sharing app.
Public recipes were visible to everyone. Private recipes were visible only to their owners or specific shared users.
A few lines of SQL, backed by Row Level Security, handled the entire model.
RLS defines who can see or change which rows of data. It’s one of the most powerful features in Postgres and one of the easiest to overlook.
“That’s all it takes, one missing check and everything’s exposed.” - Etienne Stalmans, Security Engineer Supabase
Etienne shared an example where an AI-generated policy accidentally returned every record in a table because it skipped one condition.
The fix was a single correction to the query, one line that closed a major security gap.
Bill summed it up simply:
“We want security as close to the data as possible. The closer it is, the less room there is for error.” - Bill Harmer, CISO Supabase
Security doesn’t stop once the app ships. Etienne showed how Supabase uses pgTAP to test database policies continuously.
“You can prove what you believe is secure actually is. These tests keep you honest.” - Etienne Stalmans, Security Engineer Supabase
Each test checks what matters most:
This continuous assurance makes sure small mistakes don’t grow into data leaks.
Supabase runs RLS across millions of users and large workloads without issues.
“We run it everywhere, even at scale. No issues, no excuses.” - Etienne Stalmans, Security Engineer Supabase
By enforcing security at the database level, Supabase keeps logic consistent no matter how complex the application becomes.
Bill closed the session with a warning for anyone using AI to generate code.
“Just because it works doesn’t mean it’s production ready.” - Bill Harmer, CISO Supabase
“If you tell an AI to make something work, it might remove the very security checks that protect you.” - Bill Harmer, CISO Supabase
AI models don’t understand intent. They’ll do whatever it takes to achieve the goal you set, even if that means disabling RLS or deleting authentication logic.
The danger isn’t using AI, it’s using it without guidance.
“The model’s not malicious. It’s doing its job. But it doesn’t know your intent. That’s your job.” - Bill Harmer, CISO Supabase
Security isn’t a blocker. It’s how you move faster without second-guessing what you ship.
Supabase proves that when security lives at the data layer, it becomes part of the way you build, not an afterthought.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。