DEV Community: Sukanya Mondol

AstraOS: I built a Linux distribution with an AI assistant that asks before it touches anything

Sukanya Mondol — Tue, 20 Oct 2026 14:08:19 +0000

AstraOS is a Linux distribution built from Debian packages, with its own package selection, desktop configuration, branding, installer configuration and build pipeline. Its ISO builds in GitHub Actions, passes the checks that build runs, and boots in VirtualBox. It is also an alpha: version 0.2.0, codename Nova, x86_64 only, not finished, and nothing in it has ever run on physical hardware.

Why it exists

The founding brief was blunt about what it did not want: "I do not want a website pretending to be an operating system. I want an actual, bootable, installable Linux distribution that can eventually run on physical computers."

The roadmap gives the reason. AstraOS should be the operating system for the PC people already own: a private, local-first computer that turns plain-language instructions into controlled, verifiable work. Windows 10 support ended in October 2025 and many working PCs cannot officially run Windows 11. The "AI distributions" that get talked about route agent work to cloud services by default, and cloud agent products have drawn privacy criticism for reading and writing personal folders.

The hardware target follows. The reference machine is an Intel Core i5-2500S, a 2011 Sandy Bridge chip, and the assistant is sized for that class on purpose. One principle drives the rest: keep the system usable on modest hardware, which is why the desktop chrome is flat and the expensive graphics live on the boot splash.

What is actually in it

Base. Debian 13 (trixie), pinned in one file and checked against the live archive before a build, using Debian's own linux-image-amd64 kernel (6.12 series) with systemd as the init system. It is a derivative, not a new kernel and not an official Debian release. Packages are .deb with APT and dpkg, selected from ten reviewed lists under config/package-lists, and the root filesystem is ext4 once installed and squashfs on the live image.

Desktop. Xfce on X11, configured and branded: its own wallpaper, panel, icon theme, cursor, LightDM greeter, Plymouth splash and GRUB menu. The identity has two layers. The brand layer, a neon ring with gradients and bloom, appears where you see the system briefly: boot, login, installer. The desktop layer is flat graphite and cyan with no transparency, because a blur pass on every panel repaint is what makes a desktop feel slow on old hardware.

Installer. Calamares, configured and branded. The target disk is never assumed and erasing is never the default, and the build refuses to produce an image that breaks that.

Target hardware. x86_64 Intel or AMD from roughly 2008 onwards. VirtualBox is the primary target, and the guest agents for QEMU/KVM and VMware ship in the image. Graphics drivers are open-source only, so NVIDIA goes through nouveau.

Recovery. A failsafe GRUB entry that drops the splash and turns off modesetting and ACPI, so a failure is visible instead of hidden. astraos-recovery-guide prints the guidance on a running system, and docs/RECOVERY.md covers the cases that need the medium. The snapshot, break, restore drill with Timeshift has not been performed.

The assistant

The interesting part of this project is not the model. It is what happens between the model's request and the machine.

The assistant runs entirely on the computer: a small Python server using only the standard library, and one HTML file with the styles and script inline. A test fails if an external address appears in that page. There is no cloud provider to configure and no API key to enter.

The repertoire is closed. The model may ask for one of 32 named actions and nothing else. The plan is re-checked against that catalogue before it runs, an unknown action name is refused rather than guessed at, and llama.cpp constrains generation with a JSON schema, so a tool call is valid or empty, never half-written.

The confirmation set is seven actions. run_command, shutdown, reboot, suspend, close_window, type_text and press_key. Each has a question written for it, because a person cannot consent to a category of thing. The page shows "the assistant wants to run this command (command='df -h')", not "allow the assistant to run a command". The set grew by one when the research tools landed: write_file writes into the assistant's own workspace and asks as well, so the catalogue asks before eight actions today while the README still says seven.

Underneath sit four permission levels: observe reads and changes nothing, prepare changes the session's surroundings reversibly, modify can change or lose your work (typing, key presses, closing a window, writing a file), and privileged changes the machine (suspend, reboot, shutdown, running a command). Everything above prepare is denied until a human says yes, and the approval names the resolved arguments and the effect rather than the category.

The reasoning matters more than the list. The model cannot approve itself: the plan comes from the model, the yes comes from a person in front of the screen, and the web page and the command line both go through one enforcement point, so neither can take a different route around it. A denial is not a sentence in a message. It is the action not running.

One decision I got wrong and reversed. I had argued that asking for every typed phrase would make typing useless, so type_text and press_key were left out of the set. That was wrong, because a terminal turns typing into a way to run a command. They are in the set now, and the person is asked once per plan with the exact text, not once per phrase.

Documents are data. When the assistant reads a file containing instruction-shaped text, the request is marked as coming from a document and the guard refuses everything above observe for it. The test fixtures order the assistant to open an exfiltration URL, run a command and type over a document. Each one is refused, and the refusal is recorded.

The sandbox covers the model server, not the actions. With bubblewrap or firejail installed, llama-server runs with the root and the model folder read-only and a private /tmp and /dev/shm. The network stays shared on purpose, because the page reaches the server over 127.0.0.1. Landlock is not used. The actions run as you, with your rights, and are not sandboxed.

Undo is a tested library, not yet a feature. It copies files into a snapshot directory with a manifest, restores them exactly, and removes paths that did not exist before. What is missing is the wiring: no privileged action takes a snapshot yet, and there is no astra-ai undo command.

The budgets exist so a weak model cannot loop forever. A plan longer than twelve steps is refused before it starts. A task that spends its 900-second budget is filed paused where it stopped rather than failed, and astra-ai resume continues it. A task may make at most 100 tool calls. A memory cap exists as RLIMIT_AS on the model server and is off by default.

Every decision is recorded as a JSON line carrying the SHA-256 of the line before it, so astra-guard verify can name the first record that was edited or removed. The chain is tamper-evident, not signed.

The engines are built in CI. Compiling llama.cpp costs about twenty minutes of every core, so the Build AI engine workflow builds it for two variants: avx for the Sandy Bridge class and avx2 for Haswell and later. The avx build is proven on an emulated Sandy Bridge with a real model answering over HTTP, because that class of machine once died with SIGILL and printed nothing. The avx2 build is proven natively, with a disassembly check that the 256-bit code is really there. No variant is ever compiled for the build machine's own instruction set. Both are published as the ai-engine-2026-10-19 release, and the image build downloads those assets, verifies their SHA-256 and installs both variants.

The executor is a 1.7B model that reads one request and makes one tool call; the middle brain is a 4B model that writes the plan. The split follows the measured finding that multi-agent systems on small models are planner-limited rather than executor-limited, so the parameter budget goes into the planner.

Try it

Build it yourself on a Debian 13 host with about 25 GB of disk:

git clone https://github.com/rafikulislammollaq-dev/astraos.git
cd astraos
make bootstrap     # install the build dependencies
make iso           # build the image into dist/

make check runs the static suite, make lint checks shell syntax, and make validate-iso, make checksums and make manifest work on the image in dist/. Or run the Build ISO workflow from the Actions tab and take the astraos-iso artifact.

In VirtualBox. Verify the download first:

sha256sum -c astraos-0.2.0-alpha-amd64.iso.sha256

Expect astraos-0.2.0-alpha-amd64.iso: OK. If it does not, stop.

Create the VM: name it AstraOS 0.2.0 Alpha, point it at the verified ISO, choose Type Linux and Version Debian (64-bit), decline VirtualBox's unattended installation, and give it 4096 MB of memory, 2 processors and a 30 GB dynamically allocated VDI disk. The installer's minimum is 2048 MB and 8 GB. For firmware, tick Enable EFI under Settings, System, Motherboard for UEFI, or leave it unticked for legacy BIOS.

Start it, wait for the GRUB menu and choose the normal entry. The live user is astra with no password, and the live session is not persistent.

To install, launch "Install AstraOS" from the menu or the dock and authenticate through the polkit prompt. On partitioning, choose Erase disk, because the disk is virtual, and check that the device you are erasing is the virtual one. Create a user with a password, read the summary, confirm, and choose Restart now when the queue finishes. Before booting the installed system, remove the ISO from the optical drive. That is the step people skip, and then they conclude the installer failed.

On physical hardware, the documentation says do not do this yet. AstraOS 0.2.0 Alpha has never been booted on physical hardware, the installer has never been run there, and no hardware has been tested. The procedure is written in advance so it is not improvised afterwards: verify the checksum, back up everything you cannot lose, write the image to a USB drive with

sudo dd if=astraos-0.2.0-alpha-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync

which erases that drive entirely, boot from it, partition the disk you chose, create the account and confirm. There is deliberately no script in the repository that picks the drive for you. If your firmware refuses the medium, turn Secure Boot off. Use a spare machine or a separate SSD.

What it does not do yet

No physical hardware has been tested at all. The one proven installation is virtual, legacy BIOS, one ext4 partition, no encryption and no swap, and nobody has logged into the installed system. That installed system also carries the live image's initramfs, because nothing in the install sequence regenerates one.

No browser has been launched inside a booted image. The network stack is proven in CI: NetworkManager active, an IPv4 address, a real name resolved over DNS.

The ISO is about 2.4 GB, which is 2,432,696,320 bytes for the last measured build. The next one is expected to be about 3.5 GB with the assistant bundle, and that figure is arithmetic, not a measurement.

The live session has no persistence, the desktop is X11 only, the theme is colour-only so window decorations use the upstream xfwm4 theme, and an upgrade of Debian's base-files can overwrite /etc/os-release and make the system identify as Debian. /etc/astraos-release is the file the project owns, and it is safe.

Wi-Fi is untested, no proprietary GPU driver is shipped, and the firmware for older Broadcom cards cannot be in the image because Debian does not redistribute it.

The assistant has no automatic undo wired to an action, no TLS on the paired phone connection, a tamper-evident ledger rather than a signed one, unsandboxed actions, no wake word, no image input, no stored conversation history, and no published answer-quality numbers for real hardware. astra-ai eval is the instrument that would produce them, and it has only been run as a smoke test on the smallest model in the catalogue.

What I need

The repository is at github.com/rafikulislammollaq-dev/astraos, under the GPL, version 3 or later.

Three specific things would help more than anything else:

Someone with a spare machine. Install it on physical hardware and report what happens. That is the single largest untested area, and a report saying it failed is worth more than a success.
Someone who knows Calamares well enough to review the installer configuration. It was written by reading the documentation, not by using the installer every day, and it is the part of the image most likely to be wrong in a way nobody has noticed.
Wi-Fi chipset results. Which chipsets work, which need firmware that is not in the image, and which need drivers this project will not ship.

Translations are wanted too: the installer and the AstraOS utilities are English only. And if a claim in the README is wrong, say so. Every claim in it is tied to a CI run, a test or an artifact, and "untested" is a word I use on purpose.

Vibe coding security: the step nobody takes after the build

Sukanya Mondol — Tue, 20 Oct 2026 12:51:50 +0000

Here is the loop most apps are built in now. You describe what you want. The model writes it. It runs. You ship it. The loop is fast and it works, and that is why it is everywhere.

There is a step missing from it. Nothing in the loop looks at the code for security. Not the model, because it wrote the code and cannot see what it missed. Not the platform: Lovable's own blog says its Security Scan "catches many issues, but sometimes incorrect database security setups slip through" (Lovable's blog). And not you, because you are not reading the code, and you were never going to.

The 2026 measurements of AI-built apps are consistent enough to take seriously. A June 2026 scan of 62 Lovable apps found 63% carried critical or high severity vulnerabilities, with 10 findings per app on average (DEV.to, Jun 2026). VibeSafe studied 400 public repositories built with Lovable, Bolt and v0: 59% had at least one critical issue, and 18.5% had committed a .env file. Escape DAST analysed 5,600 vibe-coded apps and found 2,038 critical vulnerabilities and 400+ exposed credentials (via Lifehacker, Aug 2026). symbioticsec.ai found that 98% of apps behind a public Supabase URL had at least one exploitable flaw. And vibe-eval measured 37.6% more critical vulnerabilities after just five AI build iterations, so keeping the prompts coming makes the gap wider.

The same five mistakes, every time

The AI writes the happy path and never checks the answer.

export async function getCurrentUser() {
  const { data: { user } } = await supabase.auth.getUser();
  const userId = user.id;
  const email = user.email;
  return { userId, email };
}

getUser() returns { data, error }. If nobody is signed in, user is null and user.id throws. If the request fails, the code carries on with an undefined user. The check is three lines:

const { data, error } = await supabase.auth.getUser();
if (error || !data?.user) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401 });
}
const user = data.user;

The server reads a session it never verified.

export async function readSession() {
  const { data: { session } } = await supabase.auth.getSession();
  return session.user.id;
}

getSession() reads the session cookie but does not check the signature with the authentication server. On the client, that is fine, because the cookie only decides what to render. On the server, it means the visitor answers the question "who is this". A hand-edited cookie is accepted as valid. On the server, ask the auth server instead:

const { data: { user }, error } = await supabase.auth.getUser();
if (error || !user) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401 });
}

A permission check that trusts the browser.

export function isAdmin() {
  return localStorage.getItem('role') === 'admin';
}

Browser storage is entirely under the control of the person using the browser. Change the value in the developer tools and the admin panel opens. Permissions belong on the server, and in the database rules, not in a value the visitor can edit.

A token check that accepts an unsigned token.

const SECRET = process.env.JWT_SECRET || 'change-me-in-production';

export function verifyToken(token) {
  return jwt.verify(token, SECRET, { algorithms: ['none', 'HS256'] });
}

Two problems. 'none' means a token with no signature at all is accepted, and anyone can write one by hand claiming to be any user, including an admin. The fallback means that if the environment variable is ever missing in production, every token gets signed with a value written in plain sight in the source. The fix is to fail loudly and pin the algorithm:

const secret = process.env.JWT_SECRET;
if (!secret) throw new Error('JWT_SECRET is not set');

const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });

A table with no rule on it.

create table public.bookings (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references public.profiles (id),
  total numeric(10, 2) not null,
  shipping_address text,
  created_at timestamptz default now()
);

Nothing after that statement turns on Row Level Security. The full fix, including the policies for each operation, is in the RLS guide linked below.

What this means for you

None of this says the code is bad. AI-generated code is often good code. The gap is a missing verification step, and the fix is to add it once, not to rebuild anything. The mistakes above are all small edits to small places.

It is worth being precise about what the numbers do and do not say. They describe a population of apps that were scanned, and the way those apps were built is not random. They are apps where a person asked a model to produce a working product quickly, and then shipped it. That population describes most AI-built apps, which is why the same handful of mistakes keeps showing up in it. It is not a claim that every AI-built app is broken, and it is not a claim that any particular app of yours is broken. It is a claim that nobody has looked yet.

What changes when somebody does look is that the list of unknowns gets shorter. The first pass usually finds a handful of specific things, and most of them are one or two lines to change. The second pass finds less. The third finds almost nothing, and you can stop.

What to do next

Run the free scanner. It reads your project folder in your browser and checks the six things that matter most in an AI-built project: environment files committed to git, hard-coded secrets, row-level security on your tables, token verification, cross-origin rules, and leftover debug routes. Nothing is uploaded, there is no account, and there is no email address. You get a ship-readiness score out of 100 and a paste-ready fix for every finding. It is not proof that your app is secure. It is a record of what was checked and what was not, which is the step the build loop skipped.

The scanner that finds this is open source: github.com/rafikulislammollaq-dev/vibeaudit

It also runs in the browser, where your project is read on your own machine and never uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

If you would rather have a person read the findings and explain them, that is a $199 review: rafikulislammollaq-dev.github.io/vibeaudit

How to check if your app leaks data

Sukanya Mondol — Tue, 20 Oct 2026 12:51:01 +0000

You want to know whether strangers can read your app's data. You can find out yourself tonight, in about ten minutes, without paying anyone. Here is the method, in the order to run it.

1. Find the public key and the project URL

They are in your frontend bundle on purpose, so this is easy. Open the developer tools, the Network tab, reload the page, and look for the request that goes to *.supabase.co. Or grep the build output:

grep -ro "https://[a-z0-9]*\.supabase\.co" dist/ | head

The key next to it is the "anon" key, sometimes labelled VITE_SUPABASE_ANON_KEY or NEXT_PUBLIC_SUPABASE_ANON_KEY. It is public by design. It is not the thing that protects your data, and the rule that does protect your data lives in Postgres, not in the key. If you cannot find either one, look in the environment files of the project, or in the settings of the tool you built the app with.

2. Send one read request

This is the single most informative test you can run. Use a table name that really exists in your project.

curl -s -i "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

Three possible answers.

200 with a row of data. Anybody on the internet can read this table. This is the one that matters.
200 with an empty array. The read was allowed, but the table has no rows. Nothing has leaked yet. The door is open.
401 or 403. This table is protected. That rule is working.

Send it once, then stop. Do not loop it across tables or pages. That is how a check turns into an incident, and also how you end up holding a copy of your customers' data. The live check in the scanner behaves the same way on purpose: one read request, one table name that already appeared in your own SQL files, no sign-in attempt, nothing written.

3. Check your migrations for the rule that should have stopped it

grep -rn "enable row level security" supabase/migrations/
grep -rn "create policy" supabase/migrations/

Every table that holds user data should appear in the first list. Every table in the first list should have at least one policy in the second list. If a table has RLS on and no policy, it has locked itself, including your own signed-in users, and it usually shows up as "the app stopped working". If a table has neither, it is the case from step two. The full fix, with the policy for each operation, is in the RLS guide linked below.

4. Look for the other four leaks

The committed environment file.

git ls-files | grep -i '^\.env'

If it prints a file, the secrets in it are in your git history and in every clone of the repository. 18.5% of 400 public repositories built with Lovable, Bolt and v0 had a committed .env (VibeSafe). Rotating the keys is the part that actually protects you. Removing the file does not.

The admin key in the browser bundle.

grep -rl "service_role" dist/ build/ .next/ out/ 2>/dev/null

The service_role key bypasses every row-level rule. If it is in the JavaScript that every visitor downloads, then every visitor has it. Moving it server-side is the fix, and so is rotating it afterwards.

The debug route.

router.get('/api/debug', (req, res) => {
  res.json({ ok: true, env: process.env });
});

And express.static('.') serves the whole project folder, which means a request for /.env returns your secrets.

The wildcard cross-origin rule.

res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Credentials', 'true');

That combination tells every browser on the internet that any website may call your API using the visitor's session, and read the response.

5. Write down what you found and what you did not check

This is the part most people skip, and it is the part that matters. A check you did not run is not a pass. "I looked at two tables out of nine" is a fact about your coverage, and it is worth writing down next to the results.

If you do this for one app, the habit is worth more than the answer, because the same five checks catch the same classes of problem in the next project too.

If you would rather have a person read the results than a list, that is a different product, and it is worth comparing the two before you decide.

What to do next

Run the free scanner. It reads your project folder in your browser and covers steps 3 and 4 in one pass, plus a check on token verification. Nothing is uploaded, there is no server, no account and no email address. You get a ship-readiness score out of 100, a paste-ready fix for every finding, and a list of the checks that passed and the ones that were skipped and why. It does not make the live request from step two, because that needs a live URL and your explicit permission, so run that one yourself. It is not proof that your app is secure. It is a record of one pass over your files, and it is worth running again after every build.

The scanner that finds this is open source: github.com/rafikulislammollaq-dev/vibeaudit

It also runs in the browser, where your project is read on your own machine and never uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

If you would rather have a person read the findings and explain them, that is a $199 review: rafikulislammollaq-dev.github.io/vibeaudit

Vibe coding security: the step nobody takes after the build

Sukanya Mondol — Tue, 20 Oct 2026 12:46:17 +0000

Here is the loop most apps are built in now. You describe what you want. The model writes it. It runs. You ship it. The loop is fast and it works, and that is why it is everywhere.

The same five mistakes, every time

The AI writes the happy path and never checks the answer.

export async function getCurrentUser() {
  const { data: { user } } = await supabase.auth.getUser();
  const userId = user.id;
  const email = user.email;
  return { userId, email };
}

getUser() returns { data, error }. If nobody is signed in, user is null and user.id throws. If the request fails, the code carries on with an undefined user. The check is three lines:

const { data, error } = await supabase.auth.getUser();
if (error || !data?.user) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401 });
}
const user = data.user;

The server reads a session it never verified.

export async function readSession() {
  const { data: { session } } = await supabase.auth.getSession();
  return session.user.id;
}

const { data: { user }, error } = await supabase.auth.getUser();
if (error || !user) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401 });
}

A permission check that trusts the browser.

export function isAdmin() {
  return localStorage.getItem('role') === 'admin';
}

A token check that accepts an unsigned token.

const SECRET = process.env.JWT_SECRET || 'change-me-in-production';

export function verifyToken(token) {
  return jwt.verify(token, SECRET, { algorithms: ['none', 'HS256'] });
}

const secret = process.env.JWT_SECRET;
if (!secret) throw new Error('JWT_SECRET is not set');

const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });

A table with no rule on it.

create table public.bookings (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references public.profiles (id),
  total numeric(10, 2) not null,
  shipping_address text,
  created_at timestamptz default now()
);

Nothing after that statement turns on Row Level Security. The full fix, including the policies for each operation, is in the RLS guide linked below.

What this means for you

What to do next

The scanner that finds this is open source: github.com/rafikulislammollaq-dev/vibeaudit

It also runs in the browser, where your project is read on your own machine and never uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

If you would rather have a person read the findings and explain them, that is a $199 review: rafikulislammollaq-dev.github.io/vibeaudit

Is Lovable safe to ship? The checks that decide it

Sukanya Mondol — Tue, 20 Oct 2026 12:40:59 +0000

You built it in a weekend. It looks good, the demo works, and now you have to decide whether to point real users and real data at it. That is a reasonable thing to be nervous about, because the platform cannot answer the question for you. Lovable says so itself. Its own blog puts it plainly: "The Security Scan catches many issues, but sometimes incorrect database security setups slip through… accidentally hardcoding API secrets… or leaving Supabase Edge Function endpoints unprotected." (Lovable's blog)

The measurements behind that gap are not theoretical. A June 2026 scan of 62 Lovable apps found 63% carried critical or high severity vulnerabilities, with an average of 10 findings per app (DEV.to, Jun 2026). VibeSafe studied 400 public repositories built with Lovable, Bolt and v0 and found 59% had at least one critical issue, while 18.5% had committed a .env file to the repository. Escape DAST analysed 5,600 vibe-coded apps and found 2,038 critical vulnerabilities and 400+ exposed credentials (via Lifehacker, Aug 2026). CVE-2025-48757, the 2025 Lovable breach, exposed 170 production apps (cited in the DEV.to checklist). That last one is context, not a threat to you. It shows what a shared class of infrastructure can do.

So the useful question is not whether Lovable is safe. It is which specific things to look at before you ship.

1. The Edge Function that trusts the browser

This is the classic Lovable shape: an Edge Function holding the admin key, reading the session out of the cookie, and taking the target account from the request body.

// supabase/functions/delete-user/index.ts
const supabaseAdmin = createClient(
  Deno.env.get('SUPABASE_URL')!,
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
);

Deno.serve(async (req) => {
  const { data: { session } } = await supabaseAdmin.auth.getSession();
  const userId = session.user.id;
  const { target_user_id } = await req.json();

  const { error } = await supabaseAdmin
    .from('profiles')
    .delete()
    .eq('id', target_user_id);
  ...
});

Three problems in a dozen lines. Edge Functions run with the service_role key, which bypasses Row Level Security completely, so nothing downstream will stop that delete. getSession() reads a cookie without re-checking its signature with the auth server, so the "who is calling" answer comes from the caller. And target_user_id comes from the request body, so the caller chooses whose account gets deleted.

The fix is to verify the caller on the server and never take an identity from the request:

const { data: { user }, error } = await supabaseAdmin.auth.getUser();
if (error || !user) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401 });
}
const { target_user_id } = await req.json();

Then check that the verified caller is allowed to delete that account, usually an admin role or their own account, before running the delete. The scanner's authorisation check flags the unverified session and the request body separately, and the row-level security check deals with the third.

2. The environment file that got committed

git ls-files | grep -i '^\.env'

If that prints a file, your database admin key and your live payment keys are in your git history, on your hosting provider and in every clone of the repository. Deleting the file does not remove it. The key has to be rotated in the provider's dashboard, and .env has to go into .gitignore. This was true in 18.5% of the 400 public repositories VibeSafe looked at.

3. The debug route

router.get('/api/debug', (req, res) => {
  res.json({
    ok: true,
    env: process.env,
    serviceRoleKey: process.env.SUPABASE_SERVICE_ROLE_KEY,
    stripeKey: process.env.STRIPE_SECRET_KEY,
  });
});

One route, three secrets, handed to anyone who types the address. AI assistants add these while building and usually forget them. Deleting the route is the fix. If you still need it, block it in production.

4. The admin page with no check

router.get('/admin/users', async (req, res) => {
  const { data } = await supabaseAdmin.from('profiles').select('*');
  res.json({ users: data });
});

The path says admin. Nothing in the handler verifies that the caller is one. The scanner looks for admin-shaped routes and checks the handler for a role test.

5. The admin key in the browser bundle

// src/lib/supabase.js - this file is compiled into the JavaScript
// that every visitor downloads
const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY,
);

The service_role key bypasses every row-level rule. With a VITE_ prefix, the bundler inlines it into the JavaScript, so every visitor ends up holding a full database admin key. Escape DAST found 400+ exposed credentials across the 5,600 vibe-coded apps it analysed (via Lifehacker, Aug 2026). The fix is to rename the variable so it no longer carries a browser-exposed prefix, move every call that uses it to an Edge Function or a server route, rebuild, delete the old build folder, and rotate the key afterwards.

One more fact worth knowing before you keep building. Shipping more features makes this worse, not better: vibe-eval measured 37.6% more critical vulnerabilities after just five AI build iterations.

What to do next

These five checks are exactly what the $199 review covers, run across your code, migrations, git history and build output in 48 hours at a fixed price. You get the findings ranked by how much they would hurt, the fix for each one written out, and a recorded walkthrough so you can follow it. It is a code and configuration review, not a penetration test, and it is not a guarantee that your app is secure. It is a list of what was checked, what was found, and what is still unknown.

The scanner that finds this is open source: github.com/rafikulislammollaq-dev/vibeaudit

It also runs in the browser, where your project is read on your own machine and never uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

If you would rather have a person read the findings and explain them, that is a $199 review: rafikulislammollaq-dev.github.io/vibeaudit

Supabase RLS not enabled: what it means and how to fix it

Sukanya Mondol — Tue, 20 Oct 2026 12:40:24 +0000

Your app is live. The URL works, the database has real rows in it, and somebody has just opened the browser developer tools, found the Supabase project URL and the public "anon" key that your frontend is built to expose, and sent one request to your database. If that request comes back with your customers' names, emails and addresses, your tables have no Row Level Security. The key was never the problem.

This is not a rare failure. In the 2026 vibe-eval benchmark, 59% of the apps sampled had at least one RLS gap, and 10.3% of sampled Lovable apps exposed real user data through missing Row Level Security. symbioticsec.ai reported that 98% of apps behind a public Supabase URL had at least one exploitable flaw.

The design explains why this happens. The project URL and the anon key are public on purpose. They ship inside your JavaScript bundle, and Supabase grants the anon role access to your tables by default. Your only defence is a rule inside Postgres that says which signed-in user may read which row. If that rule was never written, the public key reads everything.

What "RLS not enabled" looks like in your code

The scanner reads your SQL migrations. This is the pattern it finds:

create table public.profiles (
  id uuid primary key references auth.users (id) on delete cascade,
  full_name text,
  email text,
  phone text,
  role text default 'user',
  company text,
  created_at timestamptz default now()
);

A table holding names, emails and phone numbers, and no enable row level security anywhere in the file. Postgres does not filter rows for that table at all, so the anon role gets whatever the default grants give it.

Three more shapes count as the same problem.

RLS is on, but the policy underneath allows everything.

alter table public.orders enable row level security;

create policy "anyone can read orders" on public.orders
  for all
  using (true)
  with check (true);

The table looks protected in the dashboard. The rule allows every row for every role, so the effect is identical to having no rule.

Access granted straight to the public role.

grant all on table public.profiles to anon;

That hands the unauthenticated role full access to a table with no RLS on it.

A function that runs with admin rights and no pinned search path.

create or replace function public.get_company_stats(company_id uuid)
returns jsonb
language plpgsql
security definer
as $$
declare
  result jsonb;
begin
  select jsonb_build_object(
    'employees', (select count(*) from public.profiles where role = 'employee'),
    'plan', (select plan from public.companies where id = company_id)
  ) into result;
  return result;
end;
$$;

security definer means the function runs with the privileges of its owner, usually the database owner. Without set search_path, a caller can hijack the path and make the function resolve objects they control. This is the classic Postgres privilege-escalation path.

The fix

Turn the rule on, then write it per table. A table that belongs to a person:

alter table public.profiles enable row level security;

create policy "users read own row" on public.profiles
  for select to authenticated
  using (auth.uid() = id);

create policy "users update own row" on public.profiles
  for update to authenticated
  using (auth.uid() = id)
  with check (auth.uid() = id);

A table that belongs to a company:

create policy "owners read own company" on public.companies
  for select to authenticated
  using (owner_id = auth.uid());

Pin the search path on every elevated function:

create or replace function public.get_company_stats(company_id uuid)
returns jsonb
language plpgsql
security definer
set search_path = public, pg_temp
as $$
...
$$;

One trap sits on the other side. If you enable RLS and write no policy at all, the table locks itself. Nobody can read it, including your signed-in users, and it usually shows up as "the app stopped working" after a fix. Write a policy for every table you enable, and add insert and delete if the app needs them.

The table that is not in your code

One more case is worth knowing about. Tables created straight in the Supabase dashboard leave no migration in your repository, so nothing in the code records whether row-level security was turned on for them. The scanner reports those as tables your app uses that it could not review, rather than claiming they are safe. The fix is to export the schema from the Supabase SQL editor and commit it to the repository, so the access rules are visible and reviewable. Dashboards are exactly where row-level security gets forgotten, because there is no pull request where somebody would notice.

Checking it in one request

Once the policies are in, the same anonymous request that used to return your customers should come back empty, or 401, or 403. That is the live check in the scanner. It sends exactly one read request for one table, and it never signs in. It also reports what it could not check, so a table it never saw is never counted as a pass.

What to do next

A scanner will name the table. It will not write the policy that fits your schema, and it will not tell you which of the four operations your app actually needs. The $199 review does that. It reads your migrations, lists every table that needs a policy, and hands you the SQL for each one so you can paste it straight into your builder. 48 hours, fixed price. It is a review of your code, not a penetration test of your live site, and it is not a guarantee that your app is secure.

The scanner that finds this is open source: github.com/rafikulislammollaq-dev/vibeaudit

It also runs in the browser, where your project is read on your own machine and never uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

If you would rather have a person read the findings and explain them, that is a $199 review: rafikulislammollaq-dev.github.io/vibeaudit

vibeaudit: 11 static checks for the security holes AI-built apps ship with

Sukanya Mondol — Tue, 20 Oct 2026 12:19:35 +0000

The last few years of app building went like this: you describe what you want, a model writes the code, the code runs, you ship it. The tooling got dramatically faster; the verification step did not happen at all, and nobody - including the model that wrote the code - was checking.

The numbers are not theoretical. A June 2026 study on DEV.to scanned 62 Lovable apps: 63% had critical or high severity vulnerabilities, 10 findings per app on average. A separate study of 400 public Lovable, Bolt and v0 repositories, published by VibeSafe, found 59% had at least one critical issue and 18.5% had committed a .env file to git.

These are not random bugs. The same handful of mistakes keep showing up, in the same order of severity. That makes them automatable, and it is why I built vibeaudit.

What vibeaudit actually does

vibeaudit is a command line tool. Point it at a project folder and it reads the code, the SQL migrations, the git history and the build output, then produces a ship-readiness report.

Three properties mattered more to me than the detection itself:

Zero runtime dependencies. Node 20+ and the standard library only. No npm install, no build step, no package tree to trust on a client's machine. The only outbound call is npm audit.
Every finding carries a fix, not just a label. File, line, CWE reference, the offending code with the secret redacted, the exact replacement, and a paste-ready prompt.
It reports what it did not find. Passed checks and skipped checks are both listed, with the reason. "Skipped" is never reported as "passed".

The 11 checks, grouped by what they protect

Group	Check	What it finds
Secrets	`env-committed`	`.env` committed to git, or present and not `.gitignore`d
Secrets	`secrets-source`	API keys, Stripe keys, `service_role` JWTs, AWS keys, private keys, webhooks - in source and git history
Secrets	`secrets-bundle`	Admin keys, live Stripe keys and private keys inside the built client bundle
DB access control	`rls`	Tables without `ENABLE ROW LEVEL SECURITY`; unsafe `SECURITY DEFINER`; permissive `USING (true)`; `GRANT` to `anon`
DB access control	`live-supabase`	Admin key in browser code, plus one authorised live read that proves whether a table is readable without signing in
Auth	`authz`	Unchecked `getUser()`; `getSession()` on the server; `user_id`/`role` trusted from the body or `localStorage`; admin routes with no role check
Auth	`jwt`	`alg: "none"` accepted; `jwt.decode()` where `verify()` was needed; signing secret falling back to a hard-coded value
Transport	`cors`	Wildcard origin with credentials; a reflected `Origin`; `cors({ origin: '*' })`
Transport	`live-headers`	Missing HSTS, CSP, `X-Content-Type-Options`, `Referrer-Policy`, `X-Frame-Options`
Supply chain	`debug-routes`	`/api/debug` and friends; `express.static('.')` (publishes `/.env`); source maps in production; GraphQL introspection left on
Supply chain	`deps`	`npm audit` severities, plus dependency names that are bad defaults for AI-built apps

Three checks cover secrets because a key can leak three ways: into a committed file, into source, into the JavaScript every visitor downloads. Deleting the file is not enough, which is why secrets-source also reads the git history - a secret that was committed and later removed is still recoverable, and still valid. Detection is 16 credential patterns, plus JWT handling that decodes the payload to tell a harmless anon key from a deadly service_role key. The database pair is the highest-value part of the tool and the part a linter does not do: with Row Level Security off, the Supabase REST endpoint returns every row to anyone holding the public anon key - which ships inside your app by design.

The scoring model

The score starts at 100 and every finding deducts points:

Severity	Points	Meaning
CRITICAL	25	Customer data or money is exposed, or an attacker can impersonate somebody
HIGH	12	A serious hole a targeted attacker would find quickly
MEDIUM	4	Worth fixing before launch
LOW	1	Hygiene

score = max(0, 100 - 25*critical - 12*high - 4*medium - 1*low)

The weights are chosen so that four criticals, or one critical plus a few highs, can sink a project on their own. A straight subtraction is trivially explainable to a client ("each critical finding costs 25 points") and deterministic, so two audits produce comparable numbers.

Score	Verdict
90-100	Ready to ship
70-89	Ship after fixing high findings
40-69	Do not ship yet
0-39	Unsafe to ship

One rule sits on top of that: a single critical finding caps the verdict at "Do not ship yet", whatever the score. A score must never be able to hide a problem that puts customer data at risk.

What it actually prints

Run against the bundled demo project - a small, deliberately broken app - here is the real output:

Ship readiness: 0/100 - Unsafe to ship

| Critical | High | Medium | Low |
|---|---|---|---|
| 12 | 20 | 7 | 2 |

And the plain-English paragraph that follows it, verbatim:

We checked 16 files in your project for the security mistakes that AI-built apps make most often - leaked passwords and keys, database tables that anyone on the internet can read, and admin pages that are not protected. We found 41 issues - 12 serious problems, 20 important problems, 7 medium problems and 2 small problems. That gives a readiness score of 0 out of 100, which means the app currently has serious security holes and should not be exposed to users or real data until they are fixed. The most urgent one is: A powerful secret key is sitting in your project files. Anyone who gets hold of it can act as you, followed by stripe live secret key found in .env. All of these can be fixed without rebuilding the app. We only looked at the files you gave us - we did not test your live site, so the online parts of your app still need a separate check.

The evidence keeps a short prefix so you can tell which key it is; the rest never appears:

SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJI************************[REDACTED len=203] role=service_role

That is the report's design: the reader is usually a founder who does not read code, so every finding carries a plain-English line, the file and line, the fix, and a prompt to paste back into your assistant.

The safety design

The live checks touch the network, so they are fenced off.

--url alone does nothing. The live checks need both --url <url> and --i-have-authorization. Without the flag they are reported as SKIPPED with the reason, never as passed.
That is not a promise in the README, it is a test. The suite runs a local HTTP server that counts requests: without --i-have-authorization the tool sends NO request at all and with --i-have-authorization the tool sends exactly ONE read request, asserting the method is GET and the path is /. 69 tests, all passing.
It never enumerates tables. The single Supabase probe uses one table name that already appears in the project's own SQL files and sends exactly one request: GET {project-url}/rest/v1/{table}?select=*&limit=1 with the public anon key. No other table is tried.
It never attempts to authenticate. No password guessing, no token replay, no directory listing. The only other request is a single GET to the root of the URL you supplied, to read the response headers.
It reads at most 64 KB of the response body and gives up after 12 seconds.
Secrets are never printed. Every secret is replaced with a short identifying prefix and [REDACTED len=...]. The report gets emailed and pasted into chat windows; a tool that leaks the key it found makes the problem worse.

Everything else is offline and static.

Two engineering decisions that are not obvious

1. The demo fixture's secrets are generated at runtime, not committed. GitHub push protection refuses any push containing a string shaped like a live credential - even a fabricated one - and it scans git history as well as the tip. A demo fixture full of realistic keys would make the repository impossible to publish, defeating the purpose of shipping the tool. So fixtures/build-fixture.mjs writes the vulnerable files at runtime, assembling each credential from parts so no contiguous secret pattern appears in the published source tree, and it creates the fixture's own git repository so the .env is genuinely committed rather than merely present. The demo still exercises every detection path it is supposed to.

2. Scanning a subdirectory of a repo still finds committed secrets. A client sends you one sub-project of a monorepo, and the file that leaks their service_role key is committed in the parent repository. A naive implementation checks for a .git directory in the target folder, finds none, and reports "no git history" - losing the finding that matters most. The fix was isGitRepo, which falls back to git rev-parse --show-toplevel and walks up to the repository root. git ls-files and git log still run from the scanned directory, so the paths they return stay relative to what you asked for and no unrelated project is pulled in.

Install and run

There is nothing to install. Node 20+ is the only requirement.

# 1. See what it finds, against a bundled, deliberately broken demo app.
node cli.js --demo

# 2. Scan a real project.
node cli.js --target ./some-project

# 3. Write the report to a file you can send to someone.
node cli.js --target ./some-project --out report.md

# 4. Add the live checks. Only if you own the site or have written permission.
node cli.js --target ./app --url https://app.example.com --i-have-authorization

Also useful: --json for machine-readable output, --no-history to skip the git history scan, --fail-on-critical for CI, --quiet for just the headline.

What this does not do

It is not a penetration test. It does not break in, exploit anything, attack your live app, or take a copy of your data, and it certifies nothing. It is not a compliance audit, and it is not a guarantee that your app is secure. It is a focused code and configuration review of the files you gave it - the subset of a real pentest that can be automated. If you need a signed penetration test report for a compliance file, that needs a certified tester, and this is not it. It does not cover your hosting, DNS, firewalls or third-party services beyond the keys it found.

If you would rather have a person read the results than run the tool yourself, that is the same review sold at a fixed price: $199 for the report, $599 with the fixes implemented, $899 for a pre-launch ship check that adds deployment hardening and a written checklist.

Try it: https://github.com/rafikulislammollaq-dev/vibeaudit

MIT licensed. Run node --test test/ and you should see 69 passing tests.

Try it

Command line (Node 20+, zero dependencies):

git clone https://github.com/rafikulislammollaq-dev/vibeaudit
cd vibeaudit
node cli.js --demo

In your browser, nothing uploaded: rafikulislammollaq-dev.github.io/vibeaudit/scanner

Source: github.com/rafikulislammollaq-dev/vibeaudit - MIT licensed.

If you would rather have a person read the findings and explain them, that is the $199 review: rafikulislammollaq-dev.github.io/vibeaudit