September 16, 202617 changes

Configuration, quality checks, team access and a round of fixes

+New accounts receive the welcome sequence — day 1, day 3 and day 5 — and the two-day "anything blocking your first scan?" note. Accounts created from today onwards enter the sequence; nobody receives a backlog of older messages.
+A page that cannot load your data says so instead of showing you an empty one. This covers your security checklist, account activity log, team, team scans, trend chart and saved scan intent — and the checklist no longer saves over itself when it could not load.
+Site-verification tokens are no longer reported as possible secrets. Google, Bing, Yandex and Facebook domain-ownership tokens are published on purpose — Next.js renders them into a meta tag on every page — so flagging them cost you grade for doing the right thing. Secret detection also now weighs the name a value is assigned to, so a credential called something like `apiKey` is caught even when the value itself looks unremarkable. Your next scan may report secrets earlier ones did not.
+The compliance page now covers NIST SP 800-53, the CIS Critical Security Controls and the HIPAA Security Rule, alongside SOC 2, ISO 27001, OWASP and CWE. Each finding maps to specific controls, with the control's official title shown so a reviewer can check it. As before, this is an informational mapping to help you answer a security questionnaire — not an audit, a certification, or a claim that any control is satisfied. Long control lists collapse, so a tab opens on what matters.
+Long lists are paged. A scan report showed every finding at once — up to 500 full cards on one page — and now shows 25 at a time, worst first, so the criticals are always on the first screen. Links that jump straight to a finding still land on it, whichever page it is on. Your saved questionnaire responses are paged the same way.
+A pull request whose scan failed gets scanned on the retry. GitHub re-sends a delivery when a scan does not complete, but the record we write to avoid scanning the same pull request twice was also swallowing those retries — so a scan interrupted by a timeout or a transient error left the pull request with no check at all, looking exactly like the App not being installed. An interrupted scan now releases its claim, and a completed one is still never repeated.
+Downgrading from Team now removes team seats, whichever plan you move to. Moving to Indie left every member active, so ex-teammates kept a stale membership that locked them out of managing their own billing. Separately, "Free Months Earned" on the referral panel now counts credits that were actually applied to your account rather than conversions — a referral that converted while the credit could not be applied is shown as pending instead of counted as paid.
+The unprotected-payment-webhook check no longer reads comments as code. A file that calls the Stripe API and happens to explain itself — mentioning a webhook, or naming an event type in a sentence — could be reported as a critical unprotected webhook even when nothing external can reach it. The check now looks at code only, in both directions: a comment can no longer raise the finding, and can no longer silence it on a webhook that really is unprotected.
+Four operations now finish what they promise. Deleting your account stops rather than proceeding if the subscription cannot be cancelled first, so a closed account can no longer keep billing. The free Trust Page success screen says plainly when we could not email your Edit URL — it is the only way back in, so save it. Removing a team member permanently deletes their scans first, so a failure leaves the action retryable. And a CLI login that times out no longer permanently consumes an API key slot.
+New: a second catalogue of checks, about correctness rather than security. The scanner's 214 rules ask whether your code can be attacked. These twelve ask whether it tells the truth — a page that shows an empty list when the database was unreachable, an action that reports success it never got, a record written before the payment it stands for, a control only a mouse can reach. They are reported separately from security findings and are not counted among the 214.
+`// VC###-OK:` and `// scanner-OK:` now work on every rule. They were described as a general mechanism and applied to only a handful, so on most rules the comment did nothing and said nothing. `rules.disable` now applies to every engine, not just the VC rules — entropy, config, cross-file, dependency, semgrep and gitleaks findings too. Also honoured: `scan.exclude`, `scan.extensions`, `scan.maxFileSize`, `output.format`, `output.verbose` and `ai`. The GitHub Action gains a `fail-on-quality` input.
+The Custom Rules tab in Settings is gone. It let you write rules and saved them in your browser, but no scan ever read them, so nothing written there affected a result. It was labelled "Not applied to scans yet"; now it is removed rather than pending. To turn off a built-in rule, use `rules.disable` in `.xploitscanrc`, or `.xploitscanignore` to scope one to certain paths.
+Three checks decided things by searching the whole file, so a second component in the same file could answer for the first. An autosave warning could be raised from an unrelated component's state, and a stale-response warning from an unrelated input. All three now resolve names the way the language does, and a new test runs every published example twice — once with a neighbouring component added — so this cannot come back quietly.
+Every scan now runs a second set of checks beside the security rules. They look for code that runs without error and quietly reports something that did not happen — an empty list because the request failed, a "Saved" that never landed, a control only a mouse can reach. Free on every plan, in their own section, never counted toward your security grade. Worked examples for each at /quality.
+Two checks were narrowed to stop reporting correct code, and the narrowing was too tight. A failed read shown as an empty state went unreported when the response was cast, destructured or assigned rather than declared; an autosave armed by a failed load went unreported in any file with a second component using the same flag name. Both now match on shape rather than one spelling, each pinned by a test.
+Admins can invite teammates again. The invite form was offered to them and then refused with an upgrade prompt for a plan their team already had. A membership row left behind by an ended plan also no longer restricts the person holding it — it could block them from the billing portal and from scanning on their own account. Roles are now read from a team with a live subscription, so they end when it does.
+Cancelling a Team plan now clears its seats. Members' rows previously stayed active after the final invoice, and the team trend chart kept aggregating their scans. Both halves are fixed: cancellation deactivates non-owner seats, and the trend endpoint checks the team owner's subscription the way every other team endpoint already does. Teams inside Stripe's payment-retry window keep full access, and personal trends are unaffected.

September 15, 202640 changes

The scanner now checks your code against what you said it would do

+Actions that fail now say so. Saving notification preferences, revoking an API key or a session, deleting a saved questionnaire response, renaming a device and creating a checklist share link all report the outcome instead of assuming success, and a failed rename puts the old name back.
+Claiming a free Trust Page after signing up completes cleanly. If the page has already been claimed by another account, you are told that directly rather than sent back to your inbox.
+Deleting your account now removes everything tied to it, including your Trust Page — which previously stayed reachable by its public link — along with saved questionnaires and their per-prospect responses, custom domain verifications, project descriptions, your AI-analysis preference, dismissed prompts, review reminders and feedback. A connected GitHub App is unlinked rather than deleted, since the App still exists on GitHub.
+Saved scans now keep up to 500 findings, most severe first, so the detail you open matches the counts you were shown. Scans saved earlier kept fewer — re-run one to see everything it found.
+New: an intent check. Every other thing a scanner tells you is about code; this one is about the gap between your code and your own description of it. If your README says "customers can only see their own orders" and an endpoint returns orders without checking who is asking, you get that as a sentence: what you wrote, where you wrote it, and the endpoint that disagrees. It reads README.md, CLAUDE.md, AGENTS.md, .cursorrules, and a .xploitscan-intent file if you keep one.
+Benchmark figures quoted on the comparison and blog pages now match the benchmark page: XploitScan catches all 16 of the held-out third-party set.
+The benchmark page now states which rule set produced our score. Ours uses the full catalogue — what the MCP server and a paid CLI run — while Semgrep and Bearer are measured with their free rules. The number is unchanged; the comparison is now described accurately.
+The intent check reads the file your AI tool already wrote: .cursorrules, .windsurfrules, .github/copilot-instructions.md, .bolt/prompt, and saved chat transcripts under .specstory/history — where it reads your turns and ignores the assistant's, because the model's summary of what it built is not a specification of what you asked for.
+If your project says nothing about what it is for, the scanner asks. One question, once, saved to a plain .xploitscan-intent file you can edit. It only asks in a real terminal — never in CI, never when output is piped, never inside a git hook. `xploitscan intent` does the same deliberately, and `--intent "..."` passes a sentence for a single run.
+The intent check ignores code that does not count toward your grade — vendored, generated and bundled example code. It also reads the exceptions a sentence states about itself: "all API routes except /api/health require authentication" no longer treats a correctly-public health check as a contradiction.
+The intent check only reports a disagreement it can prove. Each line points at a finding the scan already produced, with a file and a line. A claim the scan cannot dispute is left alone rather than dressed up as a pass. Run a scan and it appears on its own — there is no flag to find.
+Why the intent check is worth having if you build with AI tools: you described what you wanted in the prompt, and the generator produced something plausible. It currently understands six kinds of claim — who owns which rows, what needs a login, what is admin-only, what is private, which webhooks are verified, and what is rate limited.
+Paid plans were running an older rule catalogue on the command line than the one we publish. Your next CLI scan runs the current set. If it reports findings last week's did not, those findings were already in your code.
+Payment webhooks written the way most AI builders produce them — a Next.js route under app/api/webhooks/stripe/ that never names Stripe in the body — are now checked for signature verification. If that describes your app, your next scan may report a critical finding that was always there. The check also reads the arrow form of the handler, and stays quiet when verification lives in a helper.
+The MCP server no longer reports some findings twice. The findings were real; the count was wrong. Fixed in MCP server 1.3.0. The VS Code extension has the same fix, but it has not reached the Marketplace yet; the version there today (1.1.2) still counts some findings twice. The CLI and web scanner were never affected.
+The MCP server starts reliably on installs whose path runs through a symbolic link — the ordinary case for npx on macOS and for anything installed with pnpm. Previously it could launch and never answer your editor. Fixed in MCP server 1.4.1.
+Three checks stopped firing on correct code. Routes meant to be reached without logging in — Open Graph images, sitemaps, robots, manifests, status badges — are no longer reported as missing authentication. Neither are magic-link routes, where the unguessable token in the link is the credential. And a constant that merely names a cookie is no longer mistaken for code that sets one, while a Secure flag switched on by environment now counts as set.
+A saved project description is now kept per project, so a sentence about one project is never checked against another. Anything saved before today is no longer applied — the scanner will ask again when it next needs one.
+The dashboard's promotional cards can be dismissed, and stop calling themselves new after you have been using the product for a while.
+"Last scanned" times are accurate on the dashboard, the reports tab and the scan table. Recently-completed scans could show a negative age.
+The Launch Checklist has a way in. It reads your latest scan, tracks what is left before you ship, lets you mark items done or not applicable, add your own, export a PDF and share a link — and it feeds the completion percentage on your Trust Page. It is now in the Scan menu, on your dashboard, and on both scan result views.
+Rule counts now read the same on the Docker image and the CLI README: 214 rules across 14 categories.
+Indie plans get on the command line what the pricing page says they get. Indie accounts can now create an API key and download the full rule catalogue, so a CLI scan runs all 214 rules rather than the free 30. Web scans always ran the full set. If you are on Indie, generate a key in Settings → API Keys and your next CLI scan picks it up.
+If your card fails, you keep everything you pay for while Stripe retries — scan limits, Trust Page editing, pull-request scanning, API keys, and the same for every member of a team. Access now follows one rule for the whole retry window, matching what the billing banner has always said. Nothing changes when a subscription is genuinely over.
+All Scans on the Reports tab is paged — 25 at a time, with "Showing 26–30 of 137 scans" so you can tell where you are. If you are at the 500-scan ceiling it says so, rather than leaving you to assume that is everything.
+The compliance page measures coverage against the actual standards rather than against our own list of mapped controls: 11 of SOC 2's 33 common criteria, 13 of ISO 27001's 93 Annex A controls, and the OWASP Top 10 in full. Each framework also says which parts a code scanner cannot speak to — SOC 2's control-environment and risk-assessment criteria are assessed by an auditor reading policies, not by reading source. The mapping itself is unchanged.
+Export My Data now includes your Trust Page configuration, the security questionnaires you filled in and every per-prospect copy of them, your custom domain verifications, what you wrote about your projects, and your AI-analysis preference. Keys and claim tokens are still deliberately excluded.
+Checklist completion times are accurate on both your checklist and the shared version you send to customers. Items the scanner passed for you showed "Completed just now" indefinitely.
+Text across the signed-in pages is readable. Labels, descriptions and helper text on the dashboard, reports, settings, checklist and scan pages were rendering in greys too faint against the dark background to meet the accessibility standard. Anything you are meant to read is now a legible tone.
+The AI analysis opt-out is enforced on every path. Turning it off in Settings already stopped scans from the web app sending code excerpts for false-positive filtering; GitHub App pull-request scans now consult the same setting, and a preference we cannot read is treated as "off" rather than "on". If the filter is skipped for that reason, the pull request check says so.
+The dashboard trend chart and the weekly digest email cover the full window you asked for. The oldest day of each window was being left out.
+A page that cannot reach your scan history now says so, instead of showing the screen a brand-new account sees. A scan that fails to save reports that too, rather than looking identical to one that saved.
+The scan limit notice matches the plan you are on — which cap you reached and when it actually resets — and no longer offers you an upgrade to the plan you already have. Scanning a public GitHub repository also reports a failed save the same way every other scan does.
+The subscription confirmation page reports what actually happened to your subscription. The 7-day trial applies to your first Pro or Team subscription; if you upgraded or re-subscribed you are charged straight away, and the page now says so instead of announcing a trial.
+The plan comparison in Settings matches the public pricing page. Scan history is available to free accounts and is no longer shown as something an upgrade unlocks, and both tables quote the same rule count.
+Team scan history is readable. Teammates on an active Team plan can open each other's scans, which is what shared scan history was meant to be. Deleting stays with the person who ran the scan.
+Team seats are counted. The invite form shows how many of your five included seats are in use, and an invitation past the fifth is declined with a note about adding more. Existing teams keep every seat they already have.
+The CLI tells you when a scan did not reach your dashboard. It prints one line — "Scan saved locally only" — rather than printing the report exactly as usual and leaving the scan quietly missing. Your results and exit code are unaffected.
+Dialogs and table sorting work without a mouse. The pop-up panels on the dashboard are announced as dialogs, move keyboard focus into themselves and close on Escape, and the scan history table can be sorted from the keyboard with the current sort announced.
+Form fields on the signed-in pages are labelled properly. The webhook URLs and custom-rules editor in Settings, every field in the Trust Page panel and the questionnaire editor, and the three scan pickers on Reports all had their label text sitting beside the field rather than attached to it — so a screen reader announced an unlabelled box, and clicking the label text did not put the cursor in the field. The scan pickers also now say that they open a list, and whether it is open.

September 14, 202613 changes

Findings now tell you the URL they sit behind — CLI 1.5.0

+CLI 1.5.0 — machine-readable scan output now names the AI builder that scaffolded the project. The terminal has shown this for a while ("Detected: Lovable project"); JSON, SARIF and the Splunk, Elastic and Datadog formats did not carry it at all, which is exactly where it is most useful — grouping or filtering findings by builder across many repositories in CI. It is context only and never affects a finding's severity or your grade.
+SARIF output was reporting the scanner's version as 0.1.0 regardless of which version produced it. If you upload results to GitHub code scanning, runs from different releases were indistinguishable. It now reports the real version.
+A finding used to give you a file and a line. It now also tells you the URL that reaches it, where one exists: "reachable at /api/webhooks/clerk". The scanner reads your project's own route table rather than guessing from folder names, so the path it shows is the path your app actually serves. Next.js, TanStack Router, React Router, Express and Flask are supported. It appears in the terminal, in JSON output, and on the finding card in the web report. Route information is shown for context only and does not change any finding's severity or your grade.
+Two new rules for account state that lives in the browser. The first flags an entitlement or role — a plan, a tier, an admin flag — read out of localStorage or sessionStorage and then used to decide what the user can do. Anyone can edit those values in their own browser, so the check has to happen on the server. The second is informational and flags per-account lifecycle state, such as whether onboarding is finished, being decided by browser storage alone: it is not a vulnerability, but it is why a signed-in user gets greeted as a first-time visitor on a new device.
+That second rule came from our own bug, and it is fixed here too: the "Welcome to XploitScan" prompt no longer appears for people who have already run a scan. Whether you are new is now answered by your scan history rather than by a flag in the browser, so signing in from a different browser or clearing site data no longer makes the product forget you.
+A scanner coverage fix worth naming plainly: files inside a folder called "onboarding" were being skipped during scans. The exclusion was meant to ignore our own demo fixtures and was matching far too broadly. If your project keeps real code in an onboarding folder, it was not being scanned, and your next scan may report findings that were always there. We would rather tell you that than let the number quietly change.
+Platform detection no longer mistakes writing about a tool for using one. A page or document that merely mentions Lovable, Bolt or Replit was being treated as evidence the project was built with it.
+The authentication check now recognises four kinds of endpoint it previously could not see at all. Vercel serverless functions, Netlify functions, Supabase Edge Functions and Next.js server actions were simply invisible to it — not judged and found safe, but never examined. Server actions are the notable one: a file marked "use server" turns every exported function into a callable endpoint with no route file and no URL anywhere in your project, so tools that work from routes cannot see them at all.
+For Supabase projects the scanner now reads supabase/config.toml. That file decides whether Supabase checks a caller's token before your edge function runs, and it is the difference between an endpoint anyone can call and one only signed-in users reach — a fact that simply is not visible in the function's own code. It cuts both ways: functions the platform already protects are no longer reported, and functions with that check turned off are now reported with confidence.
+The IDOR check asks a better question. It used to scan a whole file for any sign of an ownership check and stay quiet if it found one anywhere; now it looks at the database query itself. A file that displays the current user's name in one place and fetches records by a raw id in another is no longer treated as safe because of the first one.
+The benchmark page now separates blind recall from total. One case in the held-out set — a broken-access-control bug from DVNA — was read in detail before the rule that catches it was written, so it can no longer measure how well the scanner handles code nobody has looked at. It is excluded from the headline figure and named on the page rather than quietly counted as a win.
+CLI 1.5.0 and rule set 1.22.0 are on npm. If you run the scanner with npx you already have them; if you installed it globally, run `npm i -g xploitscan@latest`.
+The exported questionnaire PDF had an invisible title. Print or Save as PDF on the security questionnaire produced a document whose heading did not appear — the title was printing white on white, so the file you hand to a procurement team opened with a blank space where "Security Questionnaire" should be. Fixed, and the site navigation and footer no longer print with it: they are part of the app, not part of the document you are sending.

August 25, 20262 changes

The benchmark page now names the version of every scanner it compares against

+The methodology section of the benchmark page was showing a blank space where Bearer's version number should have been. The comparison itself was never affected — the numbers on the page are correct — but the page could not tell you which build of Bearer produced them, which is the whole point of publishing a methodology. It now names the version, and the same page states Semgrep's version the same way.
+If a version genuinely cannot be determined, the page now leaves it out of the sentence instead of printing an empty value. We would rather say less than show you something we did not actually measure.

July 30, 20262 changes

CLI 1.3.4 — please upgrade if you are on 1.3.3

+If you installed xploitscan 1.3.3, upgrade to 1.3.4. A change intended only to print an accurate rule count in the terminal caused the published package to carry rule definitions that belong to the paid tier. 1.3.4 removes them; the count is unchanged and still correct. Run `npm i -g xploitscan@latest`, or nothing at all if you use `npx`, which will pick up the new version on its own.
+The scanner's own detection benchmark now reports its coverage correctly. The page said a number of rules had no test fixtures that was wrong twice over — first by four, then by one — because the count was written by hand and then computed against a list that includes the entropy scanner, which is not one of the rules being counted. It is now derived from the rule catalog itself, so it stays right as rules are added.

July 29, 202612 changes

Prove you own the domain, and we'll scan the source behind your public source maps

+The top navigation now fits every window it is in, and collapses to the menu button at widths it cannot fill. Signed-in visitors see their own links on first paint rather than the marketing menu, and the bar stays put as you move between pages.
+New: if your source maps are public, we can now scan the source behind them. When a URL scan finds source maps being served, prove you control that host and we'll download them, rebuild your original TypeScript, and run the full rule set over it — real findings at file and line, with no repository access and nothing to install. It is the same scan you'd get from pointing the CLI at your code, reached from a URL box.
+Proving it takes about a minute: we give you one line to save at /.well-known/xploitscan-verification.txt on that host, and check for it. A DNS TXT record works too if you'd rather, and if you control the zone — many apps live on a builder-provided subdomain where you don't, which is why the file comes first. The proof belongs to your account, so verifying a domain doesn't hand it to anyone else, and we re-check it rather than trusting it forever, because hosts change hands.
+The reconstructed scan always tells you what it could not read. Plenty of builds ship maps without the original file contents embedded, and a large map may be more than one scan will download — in either case you get the count of files that went unchecked instead of a clean-looking result over half your app. Nothing is stored: the source is rebuilt in memory for that one request and dropped.
+Everything the URL scan already did stays free and needs no account. The verification step exists only for the reconstructed scan, because that output is the one thing on the page that isn't already sitting in your visitors' devtools.
+Every verification command on those pages tells you what it can answer on your plan. Some of the checks they cover run only on a paid plan, so each command names the rules a free scan skips and says what the number it returns does and does not mean — a zero from a command whose checks never ran is not a clean result, and a command that mixes free and paid checks returns the free one's count, not nothing. Same for the closing call to action: the first scan still needs no card and no signup, and it runs the 30 free rules rather than the full 212 the Index round used.
+The other three builder pages are now live: /for/v0, /for/bolt and /for/base44. Each reads its own builder's results rather than repeating Lovable's, and what repeats genuinely differs — v0 projects come with a real server from the first prompt, so unprotected route handlers lead; Base44 apps run against a hosted backend, so permission checks written in the browser lead; Bolt's smallest sample leads with a secret travelling back out in an error response. Every page carries what we're worst at on that builder's code alongside what we catch, with the confidence interval attached. The Bolt page is deliberately reported in counts rather than percentages, and says why: its sample is the thinnest in the round, and a rate over that many projects would read as more precise than anything we measured.
+The URL scanner now describes what a source map actually contains instead of assuming. It used to tell every site with a public map that anyone could reconstruct its original TypeScript — which was wrong whenever the map held plain JavaScript, and wrong again when the code belonged to a theme or a library rather than to the person running the site. It now reads the file list in the map, names the real language, and says plainly when the exposed code is third-party, so a finding about a WordPress theme's bundled script no longer reads like your own application source is on the internet. Genuine exposure of your own code is reported exactly as strongly as before.
+New page: xploitscan.com/security-questionnaire. If a prospect has sent you a security questionnaire and the deal is waiting on it, that page explains what the questionnaire tools do — the questions covered, how answers get sourced from your scan history, what stays blank for you to write, and which plan it's on. It's also reachable from Resources in the top nav, and if you're signed in below Pro it now appears under Procurement, where the tools themselves were previously invisible to you.
+Every questionnaire answer now shows what's behind it. Answers drawn from a scan are marked Verified by scan and carry the date and how many scans are on record; answers drawn from your trust page or your security checklist are marked Self-attested, because they're your own entries rather than something we measured. Both are useful and they aren't the same thing, and a procurement reviewer can now tell at a glance which is which. Scan-backed answers also show their age, and once the evidence passes 90 days we say so and suggest a re-scan rather than letting a nine-month-old result read like this morning's. The labels survive Print / Save as PDF, so whoever receives the document sees the sourcing too.
+The security questionnaire now answers only what your account can actually show. Several questions used to arrive pre-filled with claims about your side of things — that scans run on every code change, that findings block your deploys, that your traffic is on TLS 1.2 — whether or not anything on your account supported them. Those are facts about your pipeline and your infrastructure, and we have no way to see them, so they now come to you blank to fill in. The questions we can answer from your scan history still fill themselves, and now cite the date of the scan they came from, so a procurement reviewer can see what's behind each one. If you've never scanned, the security questions stay empty rather than agreeing on your behalf.
+The endpoint-authentication check now reads Supabase Edge Functions. If your app is a Vite or React front end talking to Supabase, your whole backend lives in supabase/functions/ — and that check only understood Next.js and Express handlers, so it had almost nothing to say about your server code. It now flags an edge function that never establishes who is calling it, and stays quiet when the function resolves the caller's token, leaves the tenant boundary to row-level security, verifies a signature, or is a health check, preview image or scheduled job. The same check also picks up Next.js route handlers written as export const GET = async () => {}, which it used to read straight past. As always, // VC003-OK: <reason> marks any endpoint that's public on purpose.

July 28, 202610 changes

Scanning the same code twice now gives you the same answer

+Scan results are reproducible. Both AI-assisted steps — the false-positive review that removes findings, and the optional contextual analysis that adds them — now run at a fixed sampling setting, so scanning unchanged code returns the same findings and the same grade every time. Both previously ran at the model's default sampling, where a second scan could quietly differ from the first with nothing in your code having changed.
+Scanning a subdirectory now respects the .xploitscanignore at your project root. Previously that file was only read when it sat directly in the directory you scanned, so xploitscan scan src/ — and any CI job pointed at a single package in a monorepo — quietly scanned everything you had excluded. Paths are matched relative to the file that declares them, and a nested .xploitscanignore still takes precedence, exactly like .gitignore.
+The GitHub Action's outputs (grade, score, findings-count, the per-severity counts, and sarif-file) now carry real values, so you can branch on them in later workflow steps. They previously resolved to an empty string.
+Your Trust Page can now show how your app compares to the Vibe Security Index. When your latest scan supports it, the scanning section adds a line like "Fewer findings than 62% of the 25 Lovable apps we scanned for the Vibe Security Index" — matched to the builder that scaffolded your project where we can tell, and to the whole round where we can't. The sample size is always in the sentence, the methodology is one click away, and the line simply doesn't appear when the sample is too small to support it. It is a comparison, not a badge or a certification.
+The inline "I've reviewed this" comment now works where you most need it. Marking a single finding as accepted with // VC003-OK: <reason> or // ENTROPY-OK: <reason> had no effect on those two checks — the endpoint-authentication check and the high-entropy-string check — so the only way to quiet one intentionally-public endpoint or one published verification token was to exclude the whole file. Both now honour the marker, and your explanation can run across several lines instead of having to fit on one.
+New: scan a URL, no signup. Paste your app's address at /url-scan and see what your deployed build already tells every visitor. Top of the list is whether your source maps are publicly served — if they are, anyone can read your original file names and, where a map embeds its source, your original TypeScript, comments and all. Below that: whether your backend configuration ships to the browser, which AI builder the bundle looks like it came from, and which security headers are missing.
+The URL scan reads only what your site already serves any browser — its HTML, its JavaScript bundles, its response headers. It never sends attack payloads, never attempts a login, and never queries anyone's database. It is deliberately a smaller question than a code scan: it can tell you your source maps are public, but it cannot see the authorization check missing from an API route, because that code never reaches the browser.
+When a builder is detected, the report quotes that builder's Vibe Security Index rate beside it — how often apps built with the same tool turned out to have a critical finding, with the sample size printed next to the number so you can see what it is worth. The report holds nothing back: it names the exact source maps it confirmed and the backend project it found, because every one of those values is already served to anyone who opens your site in a browser. Find it under Scan a URL in the nav.
+The navigation menus are now fully keyboard-operable. Open a menu with Enter, Space or the arrow keys, move through it with Up and Down, jump with Home and End, and close it with Escape — which puts you back on the button you opened it from. The mobile menu closes on Escape too, and it no longer stays stuck open when you widen the window past the point where its button disappears. Screen readers now get the menu behaviour they were already being promised.
+New: What Lovable apps get wrong, at /for/lovable. If you build with Lovable, this is the security findings that actually repeat across the 25 Lovable projects in the latest Vibe Security Index round — and for each one, why building this way produces it, the prompt change that stops it coming back, and the command that proves it's gone. It also says where our own detection is weakest on this kind of code, because a scanner that only advertises what it catches isn't much help in deciding whether to trust it. Aggregate only, every rate shown with the count behind it, no repository ever named. More builders to follow.

July 27, 20268 changes

Your grade now reflects your code, not your scaffold — and a public index of what AI builders ship

+Findings in code you didn't write no longer set your security grade. AI app builders copy shadcn/ui into your project verbatim, codegen writes into __generated__/, and READMEs contain example code that exists to show what not to do. All of it is still scanned and every finding is still reported — it just doesn't decide your grade or fail your CI build.
+This was a real problem, not a theoretical one: one vendored UI component uses dangerouslySetInnerHTML to set CSS variables, which trips a critical XSS rule, and a single critical caps a project at grade D. In a 20-repo study of Lovable, v0, Bolt, and Base44 projects, that critical rule fired in 16 of the 20, and most of its hits were in vendored code rather than code the author wrote. Projects graded on their own code now see a very different — and accurate — result.
+Nothing is hidden. Held-out findings appear in the CLI, the web report, the SARIF upload, and the GitHub Action's PR comment, each tagged "Not graded," with the count shown right next to the grade. A grade that excluded findings always says so.
+Prefer to grade everything? Run xploitscan scan . --grade-vendored, or set { "scan": { "gradeVendored": true } } in .xploitscanrc.
+New: the Vibe Security Index. That 20-repo study became a recurring public one. Each round we sample public repositories built with Lovable, v0, Bolt, and Base44, scan them with the full rule set, and publish the aggregate results — how often critical findings show up, how grades are distributed, and which issues repeat. It applies the same application-versus-scaffold split described above, so no builder is charged for a component library it copied in. No repository is ever named: every figure is an aggregate, because publishing the list would mean pointing at live vulnerabilities in other people's projects. The full methodology and every limitation we know about are published beside the numbers.
+Dashboard: choosing "All Projects" now shows a genuine portfolio grade — the average across each project's most recent scan, with total open findings by severity beside it. It previously showed whichever single project you happened to scan last, which read as your overall posture when it wasn't. The portfolio grade now matches the one on your reports and exported PDFs.
+The Index now publishes the median project size per builder, because it changes how the table should be read: this round spans a fivefold range, and a smaller app has fewer places for a critical finding to occur regardless of how it was built. The vendored-scaffold column also carries a plain warning that it is not a security ranking — it mostly reflects how much of a component library each builder copies in, so a 0% rate means a builder vendors less code, not that it writes safer code.
+The benchmark page and the Index now link to each other. They answer different questions and both answers matter: the benchmark is whether the scanner is accurate, measured against code where the right answer is already known; the Index is what that same scanner finds when pointed at real projects.

July 4, 20265 changes

A smoother path from first scan to signed up, and docs that match the CLI exactly

+The live demo scanner now gives you 3 scans of your own code per day, plus unlimited scans of the sample code — so you can kick the tires properly before creating an account. Try it from the new Live Demo link in the nav.
+Pricing buttons now take you straight to sign-up with your plan and billing interval pre-selected, and signing in returns you to whatever you were doing instead of dropping you on the dashboard.
+Anonymous and free-plan web scans now run the 30-rule free set — the same set the free plan gets in the CLI and everywhere else — and every scan result reports exactly how many rules ran. Paid plans scan with all 210+ rules on every surface.
+Documentation refresh: the docs and guides now match CLI 1.2.2 exactly — current flags (--diff, --watch, the SIEM output formats), the real .xploitscanrc reference, complete GitHub Action inputs and outputs, and an API reference listing the actual public endpoints.
+Slack and Discord webhook settings (Pro) now save to your account instead of a single browser. Configure them once in Settings → Webhooks and scan-complete notifications fire for every scan you upload — web, CLI, or CI. Settings previously saved in this browser are picked up automatically; just hit Save once to finish the move.

July 3, 20263 changes

We added a benchmark case we can't detect (on purpose)

+The held-out benchmark now includes a real-world broken-access-control (BOLA) case — a logged-in user editing another user's record — that no scanner we test catches today, including ours. The held-out score is now 15 of 16, with the miss shown openly on the benchmark page. Static analysis genuinely struggles with authenticated-but-not-authorized bugs, and we'd rather show you that gap than hide it.
+Scans now recognize what built your project: reports say "Detected: Lovable + Cursor project" when the scaffold is unambiguous, so findings read in the context of what those tools typically get wrong.
+Improved IDOR detection for Express and Hono apps: routes that fetch a record by a request-supplied ID (URL, body, or query) without an ownership check are now flagged — tuned to avoid false positives on routes that already enforce ownership. The new held-out case above is a harder shape those improvements don't yet cover.