What the flagship ship checks before a web application reaches anyone outside the fleet. The code, and the thing actually deployed. This page describes the method. Results are never published.
Is this code and its deployment safe to ship. Not "does the code look fine": a review that stops at the repository misses the hosting headers, the hosts the shipped bundle can talk to, what the app leaves in the browser, and the accounts that can publish a new build. The review covers both halves in one run, and writes down what it could not cover.
Least invasive first. Every step writes its raw output next to the report so each finding can point at the line, header, host or field that proves it.
A signed authorization file names the repository and every hostname, and the action classes permitted. One target outside it and the run stops before any tool starts. The file is the audit trail; a chat message is not.
Two scanners over the full git history, not the working tree. Values are redacted before they reach evidence. A verified live credential is the one result that is High on its own.
Every vulnerable package with its identifiers, lockfile and fixed version. A scanner's severity is not a finding's severity: whether the vulnerable path is reachable from the shipped runtime is decided in step 11.
Language and framework rulesets over the application's own source paths. A run that scans zero files is a failure, never "no findings".
A grep over tracked source for the patterns that turn user input into code: innerHTML, eval, permissive CORS, disabled TLS verification, shell execution, private keys. Built output is skipped; that is step 7's job.
Content Security Policy and what its script source allows, HSTS age, frame ancestors, content-type sniffing, referrer and permissions policies, caching of the HTML, version leaks. A missing policy on a page that holds a token is a defence-in-depth gap, rated as such.
Every hostname inside the served JavaScript, minus an expected list where each entry carries a reason (an identity provider's endpoints, a framework's constants, a curated registry the app deep-links to). Anything left over is a host the app could talk to that nobody explained. The same pass counts OAuth scope strings, client ids and any client-secret literal.
A headless browser runs the app's real flow at human pace and records every host contacted, every policy violation, every page error, and what was left in local storage, session storage and cookies. A privacy claim is a host list; this step is the proof or the disproof.
The same flow against a preview deployment when a header change is proposed, so a policy that breaks the app is caught before it reaches the live edge.
Crafted inputs go through the application's own parsing path offline: lookalike and mixed-script domains, oversized and hostile subjects, malformed dates, relayed senders. Each case has a written expectation and a severity. Alongside, read-only checks on the accounts that can publish: deploy-token expiry, repository visibility, branch protection.
An operator reads every unverified item and decides: reachable, or cleared with a reason. Residuals that need a human's session (a live sign-in captured through a proxy, a console-only configuration diff, two-factor state) are listed as not covered, in the report, by name.
No target is touched without a signed file naming it. The gate also honours an exclusion list that wins over everything: a third party's infrastructure is observed as traffic, never probed.
The ship runs read-only. It enriches and recommends; it changes nothing in the repository, the deployment or any account. Fixes are a separate, explicit act.
One request per URL, one browser flow. No fuzzing of a live host. Dynamic scanning is deferred until there is a backend to scan.
One decision-log row per run: what was requested, which ship, under which authorization, the outcome, and where the report is. Reports stay on the operator's machine.
One report in a fixed shape: the authorization line, the tools and versions, a severity-ranked table, then per-finding evidence, why it matters and the remediation. A finding without evidence is labelled unverified and says what proof is missing; it never masquerades as confirmed. The report ends with everything that passed, stated, and everything that was not covered, stated.
A fingerprint of the ranked findings is kept between runs. On a schedule, a new report is written only when the fingerprint changes. The log row is written every time.
| Severity | Meaning |
|---|---|
| Critical | Direct compromise, data exfiltration or code execution, confirmed and reachable. |
| High | Serious exposure, exploitable with modest effort, or a confirmed sensitive leak. |
| Medium | A real weakness that needs conditions to exploit, or a defence-in-depth gap. |
| Low | A minor hardening gap with limited impact. |
| Info | An observation with no direct risk. |
| Unverified | Plausible but not proven. The missing proof is named. |
Open-source, installed where the operator is, invoked as subprocesses. Nothing uploads code or targets to a service. No tool depends on a package manager the operator's managed devices block.
| Job | Tool | Install |
|---|---|---|
| Secrets in history | trufflehog, gitleaks | brew |
| Dependency CVEs | osv-scanner | brew |
| Static analysis | semgrep | brew |
| Headers, bundle | a plain HTTP client | native |
| Egress, storage, policy smoke | Playwright headless Chromium | bundled |
| Live-session egress proof | mitmproxy | brew |
| Account posture | the providers' own read-only APIs | native |
Models are optional and routed by task: none for the checks above, a small model to classify a request to a ship, a frontier model only for the judgement in step 11.
No findings. No target names. No client. The public face of the fleet shows methods and the ships that run them. The results live with the operator, under the authorization that produced them.