DEV Community: Gary Austin

It Compiles. Nobody Asked If It Was Safe: The One-Afternoon Review for an AI-Built App

Gary Austin — Wed, 30 Sep 2026 14:07:00 +0000

It compiles. Nobody asked if it was safe: the one-afternoon review for an AI-built app

In Veracode's 2026 testing, AI-generated code compiled almost every time and passed security checks about half the time — with no security prompting, on raw models. Two public cases — a scan of Lovable's showcase in 2025 and Wiz's Moltbook disclosure in 2026 — show one shape a failure can take: a key that is meant to be public, and a server-side rule that was missing or wrong. Here is the mechanism, what the record actually establishes, what it does not, and the afternoon that checks for it.

Somebody on your side of the table shipped an app this quarter that no security person ever read. A client intake portal. A technician's internal tool. A dashboard built in an afternoon with an AI coding assistant and a login page that made it feel finished.

It works. I believe you. That is not the question any more.

Working is the easy part now

Veracode's 2026 GenAI Code Security Report (press release, July 28, 2026) tracks code generated by more than 100 models. By Veracode's numbers:

the code compiles at a near-universal ~100% syntax pass rate;
it passes Veracode's security tests 56% of the time on average — "virtually unchanged" from their previous report;
the best model on their summer leaderboard still failed nearly one security task in three.

Two conditions ride with those numbers and they matter: the tests used no security-specific prompting, and they ran against raw models — not agents, not tools with guardrails, not code a human reviewed. Veracode says so explicitly.

So the honest reading is not "AI code is insecure." It is narrower and more useful: code that nobody asked about security, and nobody reviewed, passes security checks about half the time. Our read: that describes a lot of the apps quietly going live inside small businesses right now.

The key is supposed to be public

Many of these apps put their data in a hosted database — Supabase is a common one — and the browser talks to it directly. To do that, the page carries a key.

Here is the part people get backwards: that key is supposed to be public. A publishable (or "anon") key is designed to sit in the browser. Anyone can read it. That is fine, because the key is not the lock.

The lock is a rule on the database itself — in Supabase, a Row Level Security policy — that says this user can read these rows, and only these. When the rule exists and is right, the public key is harmless. When the rule is missing or wrong, the public key opens the whole table, for anyone, without logging in. And nothing on the screen looks any different.

That is the entire mechanism behind both cases below.

170 of 1,645: the showcase scan

In March 2025, Matt Palmer — who works in developer relations at Replit, which builds a competing AI app builder; read the finding with that in mind, and read his method yourself — found a Lovable-built site that would hand over its whole users table when a request was edited to ask for everything. So he and a colleague checked the rest.

Lovable keeps a showcase page of launched projects. Their script visited the homepages of 1,645 projects listed there, captured each request to the database, and re-issued it asking for everything. Per Palmer's published statement:

170 projects (about 10.3%) returned data with inadequate Row Level Security;
across 303 endpoints;
exposing things like emails, phone numbers, subscription and payment details, and developer API keys.

He is careful about the method, and so are we: the script only analysed homepages. It never logged in and never crawled deeper. Our read: that count is a floor, not a ceiling.

It was published as CVE-2025-48757 on May 29, 2025. Palmer also writes (as of May 2025) that Lovable's later "security scan" checked that an RLS policy existed, not whether it was correct. That is his assessment — but hold onto the underlying point, because it comes back below.

One setting: Wiz and Moltbook

In January 2026, Moltbook — a social network for AI agents that had just gone viral, and whose founder said publicly he had vibe-coded it — got a visit from Wiz researchers who, in their words, were "simply browsing like normal users."

Within minutes they found a Supabase key in the site's client-side JavaScript. Wiz is precise here: it was a publishable key, and exposing one "does not automatically indicate a security failure." The failure was behind it — no Row Level Security. Per Wiz's write-up (Gal Nagli, February 2, 2026), that key gave unauthenticated read and write access to the production database:

1.5 million API authentication tokens;
35,000 email addresses;
private messages between agents, some containing plaintext third-party API keys;
and the ability to edit live posts.

Moltbook secured it within hours of Wiz's report, over several rounds of fixes, and Wiz deleted the data it had accessed. This was a research disclosure, not an attack report. (Wiz notes that researcher Jameson O'Reilly independently found the same misconfiguration.) Wiz's own summary is the line worth keeping: the issue "ultimately traced back to a single Supabase configuration setting."

The button is hidden. The route is not.

Neither case is new in kind. OWASP's Top 10:2025 keeps Broken Access Control at #1; in OWASP's contributed test data, every application tested had some form of it. And OWASP states the principle plainly: access control is only effective when implemented in trusted server-side code.

One of OWASP's own example scenarios is an app that keeps its access checks in the front end — JavaScript that stops you navigating to the admin page — while the admin URL itself still answers a direct request. The attacker never clicks the button. They call the route.

Our read: this is the pattern an assistant ships most easily, because it builds exactly what was asked for: a page, a hidden button, a redirect for non-admins. It all looks right in a demo. Nothing in the demo asked the server to refuse.

What we do not know

It is worth being honest about the edges of the record.

We do not know how many AI-built apps your clients are running today. If you do not know either, that is finding number one.
We do not know how many of those 170 are still open. Palmer's scan is from March 2025.
We do not know how representative either case is. One was a showcase of one builder's apps; the other was one viral app. Neither is a census.

What does hold across both: a rule that exists is not a rule that works, and the only way to know which one you have is to try it — from the outside, as somebody who should not get in.

The afternoon

One app. The one a real person can sign into today. Put whoever built it in the room.

THE PRE-LAUNCH AFTERNOON — ONE APP
1  PICK     one app a real person can sign into.
2  SECRETS  search the BUILT front end (view source,
            network tab, build output) — not the repo —
            for keys. Publishable key: fine.
            Service / admin key: remove it,
            redeploy, rotate, treat as exposed.
3  ROWS     for every table the browser can reach,
            confirm the row rule EXISTS, then prove it
            WORKS with two test accounts: B's record
            as A, and with no session; read AND
            write. You should get nothing back.
4  ROUTES   call the admin API directly as an
            ordinary user. Expect a refusal (401/
            403/404) or empty result, never data.
5  HOW      every PASS gets a How-verified line, a date
            and a named human.

Step 5 is the one that turns an afternoon into evidence. "The assistant said it did" is not a how. "Called /api/users/2 as user 1, got 403, 2026-09-29, J. Smith" is.

Two ground rules. Run this only on apps you own or are authorized to test. And if a check returns data that should not have been readable, treat it as a potential exposure — follow your incident-response plan and bring in counsel and your insurer; notification duties are a legal question, not a checklist one.

The free kit: The Vibe-Coded App Pre-Launch Kit (Gatorbyte #015) is this afternoon on paper — 26 controls in six groups, the five things the login page probably forgot, a legal and trust pass, a review-only prompt for the assistant that built the app, and a pre-launch register with a How-verified column. Runs offline as a portable Windows app; no account, nothing phones home. Free to use inside your organization and with your clients, including in paid engagements.
→ https://thesecuritygator.gumroad.com/l/gb015-vibe-coded-app-prelaunch-kit

The kit supports secure-development, pre-release review and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for a penetration test or an application security assessment. The Security Gator is not affiliated with Veracode, Wiz, OWASP, Replit, Lovable or Moltbook.

Sources:

Veracode, 2026 GenAI Code Security Report — press release, July 28, 2026: https://www.businesswire.com/news/home/20260728207685/en/
Matt Palmer, Statement on CVE-2025-48757, May 29, 2025: https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/
Wiz Research (Gal Nagli), Hacking Moltbook, February 2, 2026: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
OWASP Top 10:2025, A01 Broken Access Control: https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

Twenty Got Three Days, Eight Got Fourteen: CISA's KEV Due Date Is the Free Sort Key Nobody Reads

Gary Austin — Wed, 23 Sep 2026 14:07:01 +0000

Twenty got three days. Eight got fourteen. Your patch queue's sort key was already free — and it's a date.

CISA's Known Exploited Vulnerabilities catalog publishes no CVSS score. Not for any entry, not ever. What it publishes is a dueDate — one per flaw — and in the first half of September 2026 that single field sorted twenty-eight CVEs into two piles with nothing in between. All ten security and remote-management products landed in the short pile. Here is how to read the field, why a Cisco-rated 10.0 and an Acronis-rated 7.8 drew the same deadline, and the one-afternoon inventory that turns it into a queue.

I pulled the catalog on September 18, 2026. It is a public JSON file — no account, no vendor, no scanner:

https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

catalogVersion 2026.09.18 · dateReleased 2026-09-18T13:49:41.7236Z · 1,715 entries in the catalog · 28 of them added since September 1.

Open one entry: CVE ID, vendor, product, vulnerability name, dateAdded, dueDate, knownRansomwareCampaignUse, CWEs, a required action, notes.

Now notice the absence. There is no CVSS field. CISA publishes no severity score in KEV — not a base score, not a vector, nothing. Every CVSS number you have seen sitting next to a KEV entry came from a vendor or from NVD, and somebody else put it there.

What CISA publishes instead is a date.

Twenty got three days. Eight got fourteen. There is no middle.

Subtract dateAdded from dueDate across September's twenty-eight entries and the month falls into exactly two buckets.

Three days — 20 CVEs. Linux Kernel ×2 (CVE-2025-39964, CVE-2026-53266) · Google Pixel (CVE-2026-58704) · Cisco Identity Services Engine (CVE-2026-76460) · Acronis Backup (CVE-2026-87886) · Cisco Secure Email Gateway (CVE-2026-76461) · ConnectWise ScreenConnect (CVE-2026-84869) · GitLab CE/EE (CVE-2026-85706) · MikroTik RouterOS ×2 (CVE-2026-86060, CVE-2026-67277) · Citrix NetScaler (CVE-2026-19490) · Fortinet Multiple Products (CVE-2025-25249) · Cisco Secure Firewall Management Center (CVE-2026-20079) · Adobe Commerce and Magento (CVE-2026-75650) · N-able N-central (CVE-2026-86218) · Kestra OSS (CVE-2026-49869) · JFrog Artifactory (CVE-2026-82329) · Sangoma Switchvox (CVE-2026-9586) · SonicWall SMA1000 ×2 (CVE-2026-83548, CVE-2026-83549)

Fourteen days — 8 CVEs. JFrog Artifactory ×2 (CVE-2026-42016, CVE-2026-42018) · Google Chromium V8 ×2 (CVE-2026-87491, CVE-2026-85046) · Microsoft Windows ×2 (CVE-2026-81963, CVE-2026-85880) · BerriAI LiteLLM (CVE-2026-59822) · Kludex Starlette (CVE-2026-48710)

20 + 8 = 28. No sevens, no twenty-ones, no thirties. Two values and a hard edge between them, which is what a decision looks like once it lands in a data structure. Somebody read each entry and put it in a pile.

One more fact about all twenty-eight, because it is the field people reach for when they want to feel urgency: every September entry carries knownRansomwareCampaignUse: "Unknown". The scary column is blank on the whole month. The date still says three days on twenty of them.

The honest part, before you take this anywhere

BOD 26-04 deadlines are compulsory for Federal Civilian Executive Branch agencies only. They do not bind your company, your MSP, or your clients. Not a little, not implicitly, not "as a best practice." That distinction gets flattened constantly, usually by someone with something to sell — and the flattened version is worthless anyway: "patch within three days or you're non-compliant" describes no obligation a private company actually has. Binding for federal civilian agencies; free for everyone else to copy. Copy the signal, not a claim of compliance.

The field comes from BOD 26-04, Prioritizing Security Updates Based on Risk, issued June 10, 2026, which sets remediation urgency from exposure, KEV status, exploit automation and technical impact. You do not have to adopt the directive to use its output: the dueDate is that four-variable model already run, already published, already free, shipping in the same file as the CVE ID.

The ten — and what they have in common

Ten of September's twenty-eight are security or remote-management products, defined tightly enough to be auditable: products whose purpose is to secure, authenticate, protect, back up, or remotely manage other systems.

#	Product	CVE	Added	Due
1	Cisco Identity Services Engine	CVE-2026-76460	09-16	09-19
2	Acronis Backup	CVE-2026-87886	09-16	09-19
3	Cisco Secure Email Gateway	CVE-2026-76461	09-14	09-17
4	ConnectWise ScreenConnect	CVE-2026-84869	09-11	09-14
5	Citrix NetScaler	CVE-2026-19490	09-09	09-12
6	Fortinet (Multiple Products)	CVE-2025-25249	09-09	09-12
7	Cisco Secure Firewall Management Center	CVE-2026-20079	09-09	09-12
8	N-able N-central	CVE-2026-86218	09-08	09-11
9	SonicWall SMA1000 Appliances	CVE-2026-83548	09-02	09-05
10	SonicWall SMA1000 Appliances	CVE-2026-83549	09-02	09-05

Every one: three days. Not one of them got fourteen.

State the boundary out loud, because a category you cannot audit is a statistic you cannot trust. MikroTik RouterOS appears twice in the three-day pile and is excluded here as general networking rather than security tooling; count it in and the number is twelve. The claim is ten, under that definition, checkable against the feed in about a minute.

Then read the list again and notice what it is. That is not a software inventory. It is an org chart of a security program — the box that decides who gets on the network, the box that filters the mail, the box that manages the firewall, the box that holds the backups, and the two boxes that reach every machine you own.

Contrast one: Cisco's 10.0 and Acronis's 7.8 drew the same three days

Cisco Identity Services Engine, CVE-2026-76460. Added September 16, due September 19, CWE-648 Incorrect Use of Privileged APIs. Cisco's own advisory scores it 10.0 — Cisco's number; CISA publishes no CVSS score in KEV. It was a zero-day, and Cisco PSIRT states it is aware of active exploitation. A remote, unauthenticated attacker bypasses authentication with crafted requests to an API endpoint that does not apply sufficient authentication controls, and successful exploitation can execute commands with root privileges — which includes hiding or deleting the indicators that anyone was ever there. It affects Cisco ISE and ISE-PIC regardless of device configuration. Fixed in 3.5 Patch 4, 3.4 Patch 7, 3.3 Patch 12, 3.2 Patch 11 and 3.1 Patch 12.

That is the appliance that decides who is allowed onto the network. Root on it means the system of record for who got in becomes a system the intruder controls.

Acronis Backup, CVE-2026-87886. Added the same day, due the same day. CWE-276 Incorrect Default Permissions. Acronis rates it 7.8 — Acronis's number, again not CISA's. Acronis describes it as a local privilege escalation from insecure file permissions, requiring an attacker to already hold authenticated, low-privileged local access to the Linux server. It affects the Acronis Backup plugin for cPanel & WHM (Linux) before build 1.9.3.1021, the extension for Plesk (Linux) before 1.8.11.638, and the plugin for DirectAdmin (Linux) before 1.2.3.238. Acronis confirmed exploitation observed in the wild against the cPanel & WHM plugin.

So: Cisco's 10.0 — remote, unauthenticated, root. And Acronis's 7.8 — local, foothold required first. A 2.2-point spread, two entirely different threat models, and the same deadline to the day.

The scores are not wrong. They answer a different question. Severity asks what could happen; the deadline asks whether somebody is doing it. One of those is a continuum two databases can argue about. The other is a yes or a no, and it changes when you wake up tomorrow. Only one is a sort key.

Contrast two: the browser waited, the backup plugin did not

Google Chromium V8 out-of-bounds write, CVE-2026-87491, added September 9 — fourteen days. The rendering engine on effectively every desktop you own.

Acronis Backup local privilege escalation, CVE-2026-87886, added September 16 — three days. A plugin on a control panel, needing an attacker already authenticated on the box.

Rank those two by instinct and most people invert them. Instinct ranks blast radius. The field ranks evidence.

The MSP item: two management platforms, three days apart

N-able N-central, CVE-2026-86218 — added September 8, due September 11, CWE-96 Static Code Injection. We took that one apart last week; here it is the second data point.

ConnectWise ScreenConnect, CVE-2026-84869 — added September 11, due September 14, CWE-269 Improper Privilege Management plus CWE-862 Missing Authorization. It affects the ScreenConnect client prior to 26.6.5: missing authorization controls allow file transfer and execution through an active remote session without host confirmation. Huntress reported it exploited in the wild since August 20, 2026 — roughly three weeks before it reached the catalog. The behaviour Huntress reported was worm-like: a modified ScreenConnect instance deployed four VBScript files for persistence and propagation to other ScreenConnect clients. The fix is 26.6.5 or later; ConnectWise's interim mitigation is to disable TransferFiles permissions.

I have deliberately not quoted a CVSS figure for either. The week's argument is that the date outranks the score, and the paragraph is stronger without a number in it.

Two remote-management platforms, three days apart, both in the three-day pile. If you run one, that console reaches every endpoint in your book of business — row one on the asset list, not a footnote under "tools." If you buy from someone who runs one: which management platforms reach your estate, are they internet-facing, and when were they last patched? Ask in writing. Keep the answer with a date on it.

The mail gateway, and what a zero-day looks like in the record

Cisco Secure Email Gateway, CVE-2026-76461 — added September 14, due September 17, CWE-89 SQL Injection. Cisco's advisory published on September 14, the same day CISA added it to KEV. That is what "exploited before disclosure" looks like read off a timeline instead of a press release: the vendor's first public word and the catalog entry land together, because the exploitation came first and the paperwork caught up.

Unauthenticated, no user interaction. A crafted email passing through the gateway carries SQL statements, and exploitation can reach root command execution on the underlying OS. Affects AsyncOS 16.5, 16.0, and 15.5 and earlier, on-premises physical and virtual appliances. Fixed in AsyncOS 15.5.5-0141, 16.0.4-3021 and 16.5.0-780. No workaround — meaning the mitigation column on your tracker reads "upgrade" and nothing else, which is worth knowing before the maintenance-window conversation rather than during it.

How to read the due date yourself

Three fields do all the work.

product      → what you search on. NOT the score.
dateAdded    → the day CISA published the entry.
dueDate      → the deadline it carries.

dueDate − dateAdded = CISA's urgency verdict, as an integer.

All three are free and account-free: the JSON feed above; a CSV at the same path with a .csv extension, if you would rather open it in a spreadsheet; and the browsable catalog at cisa.gov/known-exploited-vulnerabilities-catalog. Pull the file, filter entries on product against the names on your own list, and for every hit subtract. A 3 means CISA set a three-day remediation window; a 14 means fourteen. Both are in the catalog because exploitation was observed — the integer is urgency, not evidence.

Search by product, never by score. Most teams get this backwards, and it is the difference between a five-minute answer and an afternoon reconciling severity numbers two databases disagree about. You are not asking "how bad is this CVE." You are asking "is anything I own in this file, and what integer did it get." Product name in, integer out — and read the version off the host, not off the management dashboard, because dashboards report what they were last told and appliances get rebooted, restored and half-upgraded.

The list you have to build first, because you probably don't have it

You cannot filter a feed against a list you never wrote down, and the list this month demands is the one almost nobody has — not the servers, not the laptops, but the tools doing the protecting, including the vendor consoles you neither host nor patch.

Those tools sit in a structural blind spot, and it is the same one every time: excluded from the vulnerability scan because they are the security stack, patched on the vendor's cadence rather than yours, owned by "whoever set it up," and frequently the only boxes in the building with no named human on them. That is precisely the population that went ten-for-ten into the three-day pile this month.

So the afternoon runs in three passes:

Enumerate the security and management stack. One row per product: vendor, product, version read off the host, where it is reachable from, and a named human — not a team, not a mailbox, not someone who left.
Filter the KEV feed on product for every name on that list.
For every hit, record dateAdded, dueDate and the integer between them — then inherit the integer as your own priority order. Federal civilian agencies are bound by that date; you are voluntarily copying homework somebody published for free. Where no fix exists yet, write the actual mitigation in the row: restrict source addresses, take the interface off the internet, disable the feature. "Waiting on the vendor" is a status, not a control.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"We're on top of patching" is a mood. Something shaped like "23 security and management products inventoried Sep 18; 4 matched KEV by product; 3 patched, 1 mitigated by source restriction pending vendor fix; versions read off-host; owner named on every row; next pass Dec 18" is an artifact — and it is the shape of answer that cyber-insurance applications and client security questionnaires keep asking for.

The re-ranking itself costs nothing. It is a change of sort order, not a change of budget, which makes it the cheapest item on any security roadmap this quarter.

The severity number is a judgement two authorities can disagree about. The due date is CISA's verdict on whether the thing is currently being used against people: published in a free file, updated as new exploitation is confirmed, expressed as an integer you can subtract in your head.

The sort key was already free. And it's a date.

The kit is free. The Security Stack Kit (Gatorbyte #014) is this afternoon on paper: the inventory of the tools doing the protecting, the version-read-off-host column, the KEV cross-check by product, the dateAdded / dueDate / days-between fields, and the named-owner column that makes a row survive triage. It supports vulnerability-management and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice. Kits are free to use inside your organization and with your clients, including in paid engagements — thesecuritygator.gumroad.com/l/gb014-security-stack-kit

CISA Binding Operational Directive deadlines are compulsory only for the Federal Civilian Executive Branch agencies BOD 26-04 names. Nothing here creates an obligation on a private organization, and nothing here substitutes for managed security, penetration testing, or incident-response services.

Sources: CISA KEV catalog · KEV JSON feed, catalogVersion 2026.09.18, read 2026-09-18 · CISA KEV addition alerts, 2026-09-02, 09-09, 09-14 and 09-16 · Cisco security advisories for CVE-2026-76460 and CVE-2026-76461 · ConnectWise advisory for CVE-2026-84869 · Acronis advisory for CVE-2026-87886 · CISA BOD 26-04 — "Prioritizing Security Updates Based on Risk"

A note on the scores, because it is the article's premise: the KEV catalog contains no CVSS field. The 10.0 is Cisco's, from Cisco's own advisory; the 7.8 is Acronis's. Trade coverage carries CVSS figures for the Cisco Secure Email Gateway and ConnectWise ScreenConnect flaws too — omitted here on purpose, because a piece arguing that the date outranks the score should not lean on the score. No figure here is CISA's. CISA publishes none.

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

Gary Austin — Thu, 10 Sep 2026 14:07:00 +0000

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

The instructive intrusions of the season share a shape: the authentication failed, not the firewall. Here's the afternoon review that counts every door your organization exposes — and turns the count into a signed record.

The pattern with no forced entry in it

Read this month's actively-exploited list with one question in mind — what actually failed? — and a theme emerges. A screen-sharing service that authenticated a network attacker without valid credentials. A collaboration platform whose security feature could be walked past after a public proof-of-concept dropped. A management console, weeks earlier, whose login could be skipped entirely via an alternate path. And in the same season, a seven-figure dump of contact records — name, email, address, phone — whose main criminal application is making the next call to a help desk sound exactly like the user it claims to be.

No malware had to beat your EDR in any of those stories. The doors did what they were configured to do. The configuration was the finding.

Which leads to an uncomfortable reframe: your perimeter is not a firewall diagram. It's the set of every internet-reachable place that accepts a credential for your organization — or for each client, if you're the MSP. And in most shops, that set has never been written down.

You can't lock a door you haven't counted

The review starts with an inventory, because every later question is per-door. Twelve categories jog the memory:

Identity provider / SSO — the front desk itself
Email & webmail — including the legacy paths (OWA, ActiveSync, basic auth)
VPN portals & remote-access gateways
Firewall / network-gear admin interfaces
RMM & remote-support tooling — last week's master key cabinet
Hypervisor & infrastructure management — vCenter, iLO/iDRAC, cloud consoles
File / intranet / collaboration platforms
SaaS admin consoles — PSA, billing, backup, the password manager
Remote desktop & screen sharing — RDP, VNC, OS-native sharing
Break-glass & emergency accounts
Service accounts & API keys — doors with no human attached
The help desk's reset procedure — a door that answers to a voice

One row per door: what it is, who uses it, what it accepts, who owns it, when it was last checked. If producing that table takes more than an afternoon, that fact is itself the first finding.

"We have MFA" is a per-door claim

Here's where last week's management-plane review and this week's shake hands. The five console questions asked is MFA enforced on the console itself — because a console with local accounts is indifferent to how good your identity provider's MFA is. This week generalizes it. For every row in the inventory, mark exactly one:

ON THE DOOR — the service itself enforces a second factor, local accounts included.
UPSTREAM — MFA lives at the IdP; anything the door authenticates locally walks past it.
NOWHERE — a password alone opens it.

Then two follow-ups per door: can any account skip it? (service accounts, legacy protocols, app passwords) and does this door hold accounts the IdP has never heard of? The org-level sentence "we have MFA" aggregates away exactly the information an attacker cares about. The matrix exists to de-aggregate it.

The side doors

Most gaps the matrix finds fall into a short, familiar list — the paths that skip the second factor:

Legacy mail protocols still answering basic auth
App passwords and long-lived tokens that outlive their owner's MFA
Vendor and default accounts that shipped with a product and still resolve
Break-glass accounts with no compensating alert on use
Admin interfaces exposed to the whole internet where an allowlist would do
API keys embedded in scripts older than the last rotation
The MFA exception that was "temporary" two migrations ago

Close what you can in the afternoon. For what you can't, write down the reason and an owner — an accepted risk with a name and a date is a decision; the same gap undocumented is just exposure.

The human door

The password reset flow is an internet-reachable authentication endpoint. It runs on a human, under social pressure, and its verification data — the things a caller is asked to prove — is precisely what large contact-data dumps put in criminals' hands. So the script is short and strict: never authenticate on knowledge alone; call back on the number already on file, never the one the caller offers; verify through a second channel the account owner controls; allow no urgency exceptions, because manufactured urgency is the technique; and log every reset — who asked, how verified, who approved, when.

Five lines, printable. It converts the softest login you own into one of the most defensible — and the log converts it into evidence.

The record is the deliverable

Same rule as restore week and console week: every claim gets a number and a date. The afternoon ends with one page: doors enumerated, MFA state per door, paths closed, exceptions accepted (with owners), script deployed, next check booked. "Twenty-two doors, MFA enforced on nineteen, three legacy paths closed, Aug 27, J.R., re-check November" is an artifact — the kind cyber-insurance applications and client questionnaires increasingly expect. "We're pretty locked down" is a mood.

The whole thing, packaged free

The Login Surface Kit (Gatorbyte #010) bundles the review: the 12-category inventory worksheet, the MFA coverage matrix, the legacy-path kill list, the help-desk verification script, and the evidence log — free: thesecuritygator.gumroad.com/l/gb010-login-surface-kit.

One afternoon. Twelve categories. One signed page either way it lands. Because a door you haven't counted is a door you can't lock.

This is a review format, not managed security services — and not legal, compliance, or audit advice. Authentication capabilities vary by product and license; verify against your vendor's current documentation. If a review turns up evidence of compromise, follow your incident-response plan.

Same Attack, Two Companies. One Never Responded: The One-Afternoon Alert Coverage Review

Gary Austin — Wed, 09 Sep 2026 14:07:00 +0000

Same attack, two companies. One never responded.

CISA ran the same red team playbook against two organizations at the same time and published both outcomes. One SOC quarantined the machines. The other received the alerts and never responded — and the reason it didn't is the cheapest problem in this whole story to fix.

In August, CISA published something unusual: the results of two red team assessments run at the same time, against two different critical-infrastructure organizations, using similar tradecraft. Advisory AA26-237A, titled "A Tale of Two SOCs."

It is unusual because it is the experiment nobody gets to run on themselves. Same attackers, same playbook, same week, two environments — and the results printed side by side.

Both organizations were compromised at domain level. In both, the red team reached sensitive business systems and cloud resources. So the interesting variable is not whether the attack worked. It worked twice.

The interesting variable is what happened in the minutes after.

The one that worked

Organization B, a water and wastewater entity, was phished. Three users clicked, and the red team landed on three workstations.

The SOC caught the payload on each one. Every execution generated a medium-severity alert; staff quarantined the workstation, analyzed it, and reimaged it before putting it back online. Three times. Command-and-control never held.

Then something worth noticing happened. Because the defenders removed that initial foothold, the red team could not proceed — so the engagement was restructured. Organization B's own trusted agents — IT staff who knew about the assessment — executed a red-team-provided payload on a designated internal host tied to a standard, non-administrative account, replicating the access the team would have had if they hadn't been thrown out.

Assume-breach is a standard phase of these assessments, so this isn't a trophy on its own. What it does tell you is the direction the pressure ran. The team didn't move to assume-breach on schedule; they moved to it because containment worked.

Later, when the red team reached a bastion host in the OT DMZ, that host blocked outbound connections and the payload execution triggered an alert. Staff quarantined it. When the team logged into the Azure portal with a compromised account, an automated alert fired and staff blocked the account.

None of that is exotic. It is ordinary tooling, plus somebody reading the output.

The one that didn't

Organization A, in government services, did not respond.

Not to the phishing. Not to the privilege escalation — a default Machine Account Quota and a misconfigured AD CS certificate template. Not to credentials sitting in cleartext, or static cloud access keys set never to expire. At one point the red team used an over-permissioned application to review SOC staff email, specifically to see whether staff were aware of the compromise. The SOC never responded.

Here is the part that should change how you think about your own program.

The alerts fired.

The advisory is explicit: the SOC received medium- and low-severity EDR alerts related to red team activity "but did not respond to them." Thousands of false positive alerts corresponding to normal business operations — many at higher severity — obscured the real ones.

That is not a detection failure. The tools detected it. It is a response failure, and it has a completely different fix, at a completely different price.

The detail worth an afternoon

One alert in that environment was real, and a human looked at it.

Red team members observed defenders' chat about an alert on an SCCM server. The defenders tried to determine who owned that system, what it did, and how it was normally used. They could not. The SOC eventually flagged it a false positive.

Read that again slowly. The detection worked. The alert was true. It died in triage because the asset inventory could not name a person.

Which means your CMDB is doing detection work, whether or not anyone staffed it that way. An alert arrives carrying a hostname. Whether it survives the next four minutes depends entirely on whether someone can attach meaning to that hostname at two in the morning.

CISA also found Organization A running multiple SOCs and multiple EDR products whose staff neither communicated with each other nor had visibility into each other's detection tools — and SOC staff and system owners did not communicate either. More consoles is not more coverage. Each additional console is another place a signal can arrive and stop.

The advisory's closing line is blunt, and worth quoting exactly:

"Detection tools are only as effective as the people, processes, and procedures supporting them."

It is not one unlucky organization

You could read all of that as a story about one badly-run SOC. The numbers say otherwise.

The Blue Report 2026, published in August by Picus Labs, measured more than 338 million attack simulations run in real production environments. Two of its scores matter here:

Logging: 58%
Alerting: 14% — flat year over year

Fewer than one simulated attack in seven produced an alert at all.

Worth naming the obvious: Picus sells breach-and-attack-simulation tooling, and a report finding that untested detection underperforms is a report that sells more testing. Read it as vendor research. It is still worth citing, because the methodology is stated, the sample is enormous, and the finding is independently corroborated by a government advisory with nothing to sell — one describing a SOC that received real alerts and did not act on them.

Put the two numbers side by side, because the gap is the entire argument. More than half the telemetry is arriving. The event gets written down. What almost never happens is a rule that reads it and routes it to a human.

That is not a collection problem, and it will not be fixed by more retention or a bigger ingest bill. It is a detection-engineering problem. One of those costs money. The other starts with an afternoon.

The afternoon

Five events. Not fifty.

Fifty detections is a project, a budget line, and a thing you never start. Five is an afternoon. Pick five you would be embarrassed to miss, and leave the rest for next quarter:

A new global or domain administrator
A log source going dark
An impossible-travel or anomalous-location login
A mass export or bulk download
A new mailbox forwarding or inbox rule

Pick by consequence, not by ease of detection. The temptation is to choose the five you already know alert — which measures your confidence, not your coverage.

Then, for each one, three questions:

Is it logged? Usually yes. Name the source and the retention window, not just "yes."
Does it raise an alert? Now you're guessing. A rule in a vendor template is not a rule that is enabled and scoped to your tenant.
Who receives it, at 2am? This is the one that decides everything.

Question three is where most programs quietly die. "Does it alert" is answerable on paper. "Who receives it at 2am" is answerable only by looking, and the answer is startlingly often a distribution list with one person on it who left, or a channel nobody has opened since the integration was built.

Then stop guessing

Everything above is still paperwork. This part isn't.

Generate the event. Get approval, work inside a change window, and tell the people who would otherwise page out that it's you. Create a throwaway administrator. Trigger a deliberate bulk download. Add a test forwarding rule.

Then watch three places: the console that should show it, the channel that should carry it, and the human who should receive it. Record the wall-clock deltas — trigger to alert, alert to acknowledgement. Those numbers are the deliverable.

And record the silences. An event that produced nothing is the most valuable row on the page, because it converts "would we catch that?" from an assumption into a finding — one you made on your own schedule instead of during an incident.

Then remove what you created, and log the removal.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"We'd catch that" is a mood. Something shaped like "five events tested Sep 10; three alerted within four minutes; one alerted to a dead channel; one produced nothing — two tickets filed, retest Sep 24" is an artifact. It is also the exact thing that answers an assessor asking whether your monitoring is real or aspirational, and the kind of evidence assessors and insurers increasingly ask about.

Fix the routing before you fix the rule, incidentally. An alert nobody receives and an alert that doesn't exist cost precisely the same during an incident, and the routing is usually the cheaper repair.

Both organizations in that advisory had tools. Both had logs. One of them knew what it would see.

Your logging is probably fine. Your alerting is the open question.

The worksheets are free. The Alert Coverage Kit (Gatorbyte #012) is a self-contained offline HTML file — the five-event picker, the three-question test, the generate-and-watch protocol, a coverage log with time columns, the asset-ownership check, and an evidence register — plus CSV and Excel export of every worksheet. No account required — thesecuritygator.gumroad.com/l/gb012-alert-coverage-kit

This is a review format and a practical starting point to adapt for your organization. It supports detection-coverage documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Generating test events changes state in a live environment — get approval and work inside a change window.

Sources: CISA AA26-237A — "A Tale of Two SOCs" · CISA KEV alert, Sep 2 · Blue Report 2026, Picus Labs

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Gary Austin — Wed, 02 Sep 2026 14:07:01 +0000

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Last week CISA added vulnerabilities from 2015 to the actively-exploited catalog. The mechanism that keeps an eleven-year-old bug exploitable is the same one that keeps a departed employee's API token alive — and here's the afternoon review that finds it.

Decay, with a date stamp on it

On August 26, 2026, the Known Exploited Vulnerabilities catalog picked up four entries worth reading twice: CVE-2015-3246 and CVE-2015-5287, both Red Hat, both from 2015; CVE-2019-1068, a SQL Server remote code execution; and CVE-2021-23758, a deserialization flaw in Ajax.NET Professional. Entries land in that catalog on evidence of active exploitation. Somebody is still exploiting a bug that turned eleven years old.

The catalog doesn't say why. But the simplest explanation for an eleven-year-old bug still being exploited is that it is still running somewhere, on a host nobody owns, that nobody has deliberately logged into since the person who built it left.

Five days later the same catalog added two PaperCut NG/MF flaws, one of which is described in its own entry as Missing Authentication for Critical Function — on a print management server, the archetypal thing an MSP installs once in year one and never revisits. And in between, on August 27, an ownCloud improper-authentication bug from 2023 was added with a three-day federal remediation deadline.

Read together, those look less like three patching stories than one ownership story. The risk factor is not unpatched; unpatched is a symptom. The risk factor is unowned — and access decays exactly the same way, only more quietly, because an orphaned account never throws an alert.

HR closes a person. Security has to close identities.

Offboarding gets filed as an HR event, and that framing is why it quietly fails. HR closes a person. Access lives as identities, and the mapping is one-to-many.

The directory account is the one identity that reliably has a human's name attached and a process pointed at it. It gets disabled on day one, and it is what everyone points to when you ask whether offboarding works. Underneath it sits everything that was created ad hoc, is owned by nobody in particular, and has no lifecycle tied to employment at all.

So the process reports success while most of the surface is untouched.

The six-month rule

Before the hunt, one decision determines whether this review measures anything: who you audit.

Reviewing last week's leaver tells you almost nothing. The ticket is still open, the manager remembers, someone is still copied on the thread. Of course it looks clean — you are measuring your attention, not your process.

Pull five people who left six months ago or longer, or five contractors whose engagement ended that long back. That tells you what your process produces once attention has moved on, which is the only condition it will actually operate under for the rest of its life.

It is the same logic as testing a restore instead of trusting a green backup job. The green light describes an intention. The restored file describes reality.

Ten places access hides

One row per identity, not per person. A single departure usually produces several:

Directory / SSO account — the easy one, and the one that flatters the process
Local accounts on appliances — firewall, hypervisor, NAS, print server, switch; tied to no directory
Shared credentials in the team vault — four people know it, so rotating it means telling four people, so it never gets rotated
Service accounts — nobody offboards one, because nobody thinks of it as a person; yet it carries their naming convention and their permissions
API tokens and app passwords — they outlive the human because the token appears in no list anyone reads
MFA enrolments on personal devices — the account is disabled, the phone is still a registered authenticator
Vendor and support portals — they are still the registered contact, so resets and license changes still route to them
Client tenants and delegated access — MSP-specific, and the highest blast radius on the list
Repos, CI, and deploy keys — org membership and personal access tokens both outlive employment
Mailbox rules and forwarding — survives the mailbox being converted to shared, and quietly keeps delivering

If your hunt produces one row per person, you have found the checklist, not the access.

Verify in the system, not on the checklist

This is the step most reviews skip, and skipping it makes the other steps decorative.

A completed offboarding checklist is a claim. The system's actual user list is evidence.

On a first pass those two usually disagree — and when they do, the checklist is what's wrong. It recorded an intention formed at the moment of ticking, and nothing re-validated it afterwards. A user list pulled today is a statement about now.

The failure modes are mundane, which is exactly why they persist:

The account was disabled but never removed from its security groups, so a re-enable for a mailbox restore silently returns full access.
The human was revoked and the token they generated wasn't, because the token isn't attached to them anywhere a person looks.
The shared vault entry was never rotated, because rotating it is a conversation with four people.
Two admins each assumed the other one did it.

None of these require carelessness. They require a process that stops at ticked.

The artifact is the point

The review is just how you produce the record. The record is what survives.

Log what you revoked, from where, on what date, verified how, and checked by whom — and fill it as you go, because retro-filling is how dates stop being true. Then write the per-departure summary: systems checked, identities found, how many were still active, when they were closed, and what process gap let it happen.

That last field matters more than it looks. What you found is a gap in the runbook, not in one person's file. Patching the record leaves the next departure exactly where this one was.

The rule carries over from every review in this series: every claim gets a number and a date. "We offboard people properly" is a mood. Something shaped like "five departures reviewed, 31 identities found across 9 systems, 6 still active, all revoked, Sep 4, verified by J.R." is an artifact — and it is the one an assessor asks for when they want to know whether your access-control process is real or aspirational.

When you find something

Preserve before you act — screenshots, exports, timestamps — and if there is any sign the access was used after the person left, stop and follow your incident-response plan. A worksheet is not one. Engage counsel and your insurer per your policy's terms before external communications.

And a clean review is still a deliverable. Identities counted, nothing still open, dated and signed, filed. An identity nobody owns goes on the risk register with one owner and one fix-by date, not in a drawer.

The worksheets are free. The Offboarding Evidence Kit is a self-contained offline HTML file — identity hunt across all ten categories, verification pass, revocation log, per-departure review record, evidence register — plus CSV and Excel copies of the three registers. No account required — thesecuritygator.gumroad.com/l/gb011-offboarding-evidence-kit

This is a review format and a practical starting point to adapt for your organization. It supports access-review and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Account and token lifecycle behaviour varies by product and license — verify against your vendor's current documentation.

Sources: CISA KEV catalog · KEV alert, Aug 26 · KEV alert, Aug 27 · KEV alert, Aug 31

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

Gary Austin — Wed, 19 Aug 2026 14:07:00 +0000

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

One console in your stack can reach every machine you manage. This month an attacker demonstrated exactly what that means — without deploying a single piece of malware. Here's the two-hour review that turns that lesson into a signed record.

The intrusion with no malware in it

The most instructive incident reporting of the month describes an attack with no phishing email, no dropper, no encrypted payload. An authentication bypass in a widely deployed remote monitoring and management (RMM) platform gave the attacker administrative access to the management console — and from that point they never needed an exploit again. They used the product's own remote-control feature, the same one technicians use every day, to reach managed endpoints and leave persistence behind. In at least one confirmed case, the session ran under a default support account that ships with the product.

Read that chain again from your tooling's point of view. The endpoint agent saw a legitimate remote-support session. The firewall saw a signed, widely used tunneling utility connecting to a well-known service. The audit log saw a support account supporting. Every control was working correctly. They were answering questions nobody had asked.

Why the management plane is a different asset class

Compromise an endpoint and an attacker owns an endpoint. Compromise the management plane and they own every endpoint it manages — and if you're an MSP, that's not one company, that's your entire book, through one console that lives on the internet because it has to.

A workstation is a room. Your RMM is the master key cabinet. That asymmetry is why the console deserves harder questions than any other server you run — questions that outrank every feature comparison on the next renewal call:

Does the console share an identity system with your domain? Shared identity means one takeover becomes two.
Is MFA enforced on the console itself — not just on the technician's email account?
Can any technician open remote control on any endpoint at any hour, or is that scoped and scheduled?
Does the management server have unrestricted outbound access? A server that can tunnel anywhere can beacon anywhere.
Is there one session record an administrator of that same server cannot quietly edit? If the intruder is admin on the console, the console's log belongs to them too.

Patched is not fixed

Here's the detail worth tattooing on the inside of the ticket queue: the flaw being actively exploited exists because the patch for an earlier vulnerability was incomplete. The first fix shipped; the underlying path stayed open; a second CVE was issued for the same way in — and the second one is what attackers are using. A population of teams did everything right, applied the update, closed the ticket, and remained exposed.

So verify patches the way you'd verify a restore:

Check the version on the host itself. The console reporting on itself is a claim; the host is the fact.
Check every instance, not the one you remember.
Where the vendor documents the closed path, re-test the path rather than trusting the version string.
Re-read the advisory a week later. Incomplete fixes are usually discovered after the first patching wave, not before.

Then write it down: version confirmed, instances checked, date, who, what test. "We're patched" is a mood. That log is an artifact — the same artifact cyber-insurance applications and client security questionnaires keep asking for.

The four tells (context, not tooling)

What actually separates an attacker from a technician when the tool, the account, and the feature are all legitimate? Context. Four kinds of it:

1. HOUR    — a support session at 3 AM on a Sunday
2. SOURCE  — a consumer-VPN exit node, not your office or corporate VPN
3. IDENTITY— a default account name nobody on your team actually uses
4. SHAPE   — connect → enumerate → disconnect
             (reconnaissance looks nothing like support)

None of these are alerts in most shops today. All four are answerable this week, from logs you already collect.

Hunt backwards, then write it down

Because this class of flaw tends to be exploited before it's catalogued, forward-looking controls are half the job. The other half is a 90-day retro-hunt: pull remote-session history and read it against the four tells; look for tunneling utilities registered as services on machines with no business running them; look for executables in user document folders wearing system file names; search for persistence no ticket explains. You're not looking for a hit — you're building the ability to say you looked, and what you found. A clean hunt, dated and signed, is still a deliverable.

The whole thing, packaged free

The Management Plane Kit (Gatorbyte #009) bundles the review: the five-question hardening checklist, the patch verification log template, the four tells as a starting detection list, and the 90-day retro-hunt worksheet — free: thesecuritygator.gumroad.com/l/gb009-management-plane-kit.

Two hours. Five questions. One signed page either way it lands. Because a control you can't evidence is a control you're only assuming you have.

This is an exercise and review format, not managed security services — and not legal, compliance, or audit advice. Vendor advisories change; verify version guidance against the current advisory before acting. If you find evidence of compromise, follow your incident-response plan.

Your Backups Are a Hypothesis: The 45-Minute Restore Test

Gary Austin — Sun, 16 Aug 2026 09:15:00 +0000

The green checkmark problem

Every MSP dashboard has one: the backup column, green for months. Green feels like safety. But a green job proves exactly one thing — the job ran. It does not prove the data comes back, how long that takes, whether the increment you'll need survived the retention policy, or whether anyone alive can find the decryption key at 2 AM.

Two weeks ago this series argued that an incident response plan that's never been exercised is a hypothesis. Backups are the same species of hypothesis, with quieter failure modes:

Rotated credentials. The backup service account changed; jobs kept "succeeding" against a subset of targets.
Corrupt increments. The chain is only as good as its weakest link, and nothing verifies links like a restore.
Retention surprises. The copy you need is from 9 days ago; retention keeps 7.
Key-inside-the-vault. The decryption key or console password is documented… inside a system that's now encrypted.
Scope drift. The new file share, the new VM, the migrated mailbox — added to production, never added to the job.

Every one of these is invisible on a green dashboard, and every one of them is found in one of two moments: a scheduled drill on a Tuesday afternoon, or the worst hour of your year.

The drill

THE 45-MINUTE RESTORE TEST  (roles: an operator + a scribe. That's the team.)

0:00  Pick the target BEFORE you feel ready: one production system that
      would hurt Monday morning — file server, finance share, the PSA/RMM
      database. Not the easy one. The one that matters.

0:05  Restore last night's copy to an ISOLATED target: a spare VM, an empty
      VLAN, a cloud sandbox. NEVER over production. No internet egress
      required — isolation is the point.

0:35  Verify like a USER, not an admin: open three files, run one report,
      log in with a real non-admin account. "It boots" is not "it works."

0:40  Write four numbers: minutes to restore · GB restored · items verified
      · today's date. The scribe signs the page.

That signed page is the deliverable. Everything else — the war stories, the "huh, interesting" moments, the ticket you'll open about the service account — is bonus.

The one rule

Borrowed from the tabletop drill and repointed: every claim gets a number and a date.

"Restores work fine" is a mood. "47 minutes, 212 GB, three files opened and readable, August 11, signed by the scribe" is evidence — the kind cyber-insurance applications and enterprise security questionnaires are explicitly asking for when they say tested recovery and documented RTO. You're not doing extra work to satisfy the questionnaire; the drill's natural output is the answer.

The math you can finally do

Recovery time estimates usually divide a known number by a guess:

Real downtime ≈ (data that must come back) ÷ (restore throughput)

Every team knows the first number. Almost nobody has measured the second — and the difference between an assumed and a measured throughput is the difference between promising "a few hours" and delivering a long weekend. After one timed drill, your RTO conversations use a measurement. Guessing is over.

The trap: your backups are the first target

Ransomware crews have told reporters for years that backup infrastructure is their first stop — delete or encrypt the recovery path, then detonate. Recent KEV traffic makes the architectural point for them: Veeam's advisory for CVE-2026-44963 describes a critical RCE on domain-joined backup servers, reachable by any authenticated domain user. One stolen domain account, and the vault is another room on the sinking ship.

So alongside the restore drill, three architecture questions worth an hour:

Credential separation. Does the backup console share credentials (or auth domain) with production? It shouldn't.
An undeletable copy. Does at least one copy live where a domain admin cannot delete it — immutable object storage or genuinely offline?
Console-loss drill. If the console died tonight, who could still reach a copy, and by what path?

The commonly used rule of thumb is 3-2-1-1-0: three copies, two media, one offsite, one offline or immutable, zero errors on verification. The last digit is the one everyone skips — and it's the only one that involves actually restoring. Treat it as a starting point to adapt, not a certification to claim.

When the test fails

A restore test that fails is a successful test — it located a real gap for the price of 45 minutes. Run the tabletop rule on it: the gap gets an owner and a date, and the failed log page stays in the file next to the eventual passing one. The paper trail from red to green is itself evidence of a functioning program. The only failed test is the one never run.

Make it a rhythm

One drill is a data point; a rhythm is a program. Rotate targets quarterly — file server this quarter, the PSA database next, a full VM the one after. Fifteen minutes of scheduling covers a year: four calendar invites, each with an operator, a scribe, and a target named in advance. Booked beats intended.

This is a review format and a practical starting point to adapt for your organization. It supports backup- and recovery-evidence documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Restore behaviour varies by backup product and license — verify against your vendor's current documentation and rehearse inside a change window.

Local-first GRC: why I'm building a compliance workbench that doesn't phone home

Gary Austin — Tue, 28 Jul 2026 09:27:58 +0000

I'm Gary — The Security Gator. I build a GRC command deck for vCISOs, MSPs, and consultants who are tired of renting access to their own compliance data.

The premise is simple: most compliance platforms are SaaS. Your control assessments, your risk scores, your client evidence — all of it lives on someone else's servers, behind a subscription that never ends. Stop paying, lose access.

The bet: own it, don't rent it

AxiomLens is a NIST CSF 2.0 workbench that runs entirely on your machine — SQLite under the hood, a local GUI on top, one-time license. After activation it's strictly offline.

	CaaS / SaaS	AxiomLens
Your data lives	On their servers	In a SQLite file you own
Access model	Log in to their cloud, every session	Activate once, then fully offline
Cost shape	Subscription, forever	One-time license
When you stop paying	Locked out	Nothing happens — it's yours

$ axiomlens status --json
{
  "controls_total": 106,
  "in_scope": 100,
  "coverage": "computed locally"
}

Coverage math, scored risk, board-ready reports, client hand-off docs — computed on your machine, owned outright. It supports compliance documentation and audit preparation; it's not a substitute for legal, compliance, or audit advice — and I'm careful to never claim otherwise. That honesty is part of the pitch.

What I'll write about here

The build, in public: SQLite schema decisions for framework crosswalks, packaging Python into a single exe with Nuitka, deterministic report generation instead of LLM roulette, and the general weirdness of shipping desktop software in a SaaS world.

The free stuff — field guides, a governance tool, starter kits — lives on the Gatorbyte Free Shelf.

Everything else: thesecuritygator.com · Bayou Bytes newsletter