Documentation and Artifacts

Lists fit the available viewport. Filters scroll independently from rows, while search, column headers and pagination stay visible. Threats, Audit record and Coverage keep their graphics visible across the top of the list. Entry points and System show their charts at full size above the list and scroll as one page, so no chart or row is cut off. Every list ends with Show (the rows per page) and the pager. Graphics and rows scroll independently.

An assessment gives you two views beside its findings. Documentation describes your application's security shape. Artifacts shows what the audit examined and how deeply it reviewed your code. Open either from the assessment's Insights & Tools panel.

Both open full width, with headers aligned to the other assessment views and tabs directly above the dashboard. Counts come from the same assessment as the rows you open.

Code audits show source review depth. Black-box and white-box assessments also show recorded HTTP activity: captured request totals, observed method/URL addresses, methods, response status groups and the most requested application addresses. Static assets are grouped from recorded response content types and can be selected separately. Each capture is counted once if its stored record was replayed. Open an address to inspect its captured traffic. Your assessment permissions determine whether traffic is visible. Views omit dimensions the run cannot support.

Documentation

Overview shows the service map, entry points, services, data stores, actors, trust boundaries and threats. The surrounding widgets show entry points by scope and kind, entry points with issues, and issues by attack class. Click a map node or an entry point to open its details. The map opens on connected subjects; All nodes, zoom and fit controls let you inspect the broader inventory. Rings show the highest linked issue severity. Ranked entry-point bars show issue links and scope; their header counts the links displayed, so an issue linked to two entry points contributes to both rows.

Attack surface draws every checked entry point as one dot, grouped by kind. HTTP routes, pages and sockets sit on the outer ring. A dot's colour says whether the entry point has an issue (a class the audit found, or a finding that cites its code, as in the Entry points list's With issues), the attack classes checked came out clean, or only classes that do not apply were recorded. Its area grows with the classes checked. Hover a dot for its address and counts, and click it to open the entry point.

Entry points lists HTTP routes, pages, commands, scheduled jobs, sockets and library calls. A map above the list has one view for each kind the audit found, with HTTP first. The HTTP and page views draw the paths as a tree, with each path's methods together and a dot for the highest issue severity; the command line view groups commands by their first word, the library view groups calls by package or module, and sockets and scheduled jobs are a list. The tree splits addresses only where they already have a separator, such as / in a path. A group of more than six entries starts collapsed unless one of them has an issue. A long map shows its first rows with Show all below them instead of hiding the rest. Choosing a view also chooses that kind's tab in the list, and clicking a node filters the list to it.

The list has a tab for all entry points, one for each kind and one for entry points with issues, each with its count. A row shows a severity dot, the HTTP method, the address with its path parameters highlighted and the purpose underneath, the inputs as location name chips, and the number of issues. For a live application assessment, the list includes observed routes and routes named by the application. ANY means the application named a route without a method. Once a concrete method is known for the same origin and path template, the list and map show the concrete methods and retain the route's discovery evidence. A purpose appears only when the assessment recorded one. Path placeholders are listed as path inputs. Hover clipped text to read it in full. Select rows to export them, or export the current filter or the whole list, as CSV or JSON.

Type a query to narrow the list. A query is made of field:value terms and plain words, and every term must match. OR between terms matches either side, - or NOT before a term excludes it, and quotes keep spaces in a value. The fields are kind, method, address (or path, where * matches any text), scope, purpose, in (where an input arrives), input (an input's name), issues (>0, 0 or a number), severity and class (an attack class with an issue). For example, method:POST in:body issues:>0 lists the POST routes that take a body and have an issue. The query bar suggests fields and the values the audit recorded, with how many entry points have each, and names a field it does not know. The query is part of the page address, so a copied link opens the same list. An open row starts with how the entry point is called: a request line such as GET /callback?code=…&state=…, a command, a function call or a socket address. The panel then lists the inputs grouped by where they arrive (body, query, header, cookie and so on), with types written in Python notation for every language: str, list[str], dict[str, int], str | None, Literal["list", "execute"]. A record lists its fields under it, and a body that takes one of several shapes lists each shape under it. Unknown marks a part of a type the audit could not read. The row also shows handler lines, recorded controls, calls, related audit objectives and findings. Code proofs appear inline with their real line numbers. The header of each code block shows the file, the lines shown and, when only part of the cited lines fits, the whole cited range (Showing 505–533 of 479–568); Show more reads all of the cited lines and a few around them without leaving the panel.

For live operations, the panel shows inputs by location, response outcomes and counts per test user or Anonymous, attack classes with their outcomes, linked threats and recorded requests. Documentation and Artifacts use the same operation details and activity reader. Recorded requests belong to the operation whose drawer is open. A response that merely named the route is kept as discovery evidence. Requests without a recorded test-user session show Anonymous with no role.

For audits run after this was added, the panel also shows what the audit recorded about how a non-HTTP entry point is called. A command lists its positional arguments under Arguments and its options under Options, with each option's real spelling (--allow-insecure-http) and value placeholder (--env NAME=VALUE), and its call line reads like --help output: vibe mcp add NAME [--transport …] [--env NAME=VALUE]…. A scheduled job's call line is its schedule (every 20 s, or its cron expression), and a socket's call line notes how it frames messages ("one message per line"). An input shows its default (= "stdio", = False) only when the default cannot be a secret: no default, a true or false switch, a number, or one of the input's own allowed values. Any other default is not copied into the Documentation.

The default order groups HTTP, Page, Socket, Command line, Scheduled and Library entries in that order, then sorts each group by its displayed address or name. Unreadable rows follow the readable entries. A column header replaces that default; the first Issues click shows the highest counts, and the next click shows the lowest. Sort choices remain in the page address with filters.

A control appears only when the audit recorded code evidence that enforces it. Request checks shows the checks the audit recorded on an entry point's request. A missing control label does not mean that your code lacks that control. An issue that matters appears in Findings.

Newer audits also record how callers reach an endpoint. Their panels show the caller paths and the layers that apply checks. A conditional check states when it applies and its default. No outside caller and Called by other code identify the recorded reachability. Called functions appear under the entry point that reaches them.

Repeated sightings of the same endpoint are merged. /users/{id} and /users/:user_id describe one route, while different dispatch commands or routes owned by different application scopes remain separate rows. A browser page stays a page; its client-side guards do not count as server controls.

System shows spatial clusters of architecture subjects, its kind distribution, recorded connections, trust boundaries and trust zones. On a phone the charts stack in one column. The charts always show the whole audit, whatever the list below is filtered to. When a run has more subjects than the map draws, the landscape says how many of them it shows. Data store writers shows the first six stores; Show all lists the rest. Its list works like the Entry points list: tabs for all subjects, those with issues and each kind, a query bar, selection and export. A row shows the subject's severity dot, name and purpose, its kind, up to two subjects it connects to, its number of locations and its issues. The query fields are kind, name and connects (where * matches any text, and a plain value matches part of the name), issues, severity and locations (>5, 0 or a number). Open a subject to read its purpose, code references and related findings. Data store writers links each data store to the subjects recorded writing to it. Hover either side to highlight its links. The connected service map stays on Overview.

Threats summarizes the recorded scenarios, accepted risks, trust boundaries and trust zones. A severity distribution and ranked bars show the issue-linked scenarios of the whole assessment. Click a scenario to open its description, cited source locations and linked issues in the side panel. Each cited file is one row with its line ranges; open a row to read the cited lines. A scenario links to a boundary when that relationship was recorded. Confirmed issues appear in Findings.

Artifacts

Overview shows a compact repository sunburst, the directory list, triage counts and a work summary. Its evidence categories are Source context, Review context and Security signals. They group files by source records, review-objective references and candidate or finding evidence. File counts use file units; chart weights state whether they measure bytes or files.

Repository directories shows the recorded nested folder hierarchy. Folder counts include files below that folder. Use a folder's browse arrow to load a deeper view, or its name to open Coverage. The Repository button returns to the initial hierarchy. The list shows eight folders at a time, with page controls under the last one.

Coverage shows a treemap or sunburst beside evidence-distribution bars above the file list. You can switch charts and drill into a directory. In the treemap, each top-level folder has a labelled frame, and a box with open issues has an outline in the colour of its highest severity. Hover a box to see its path, size, the share of each evidence category and its issue count. Open a file to see its evidence category, source, audit objectives and related findings. Hover a clipped file name to read its full path. When observed source-read ranges are available, the file lists those recorded line ranges; open the file's row to read them. These ranges describe reads and do not change review depth. Out-of-scope files are excluded from the chart and counted in a short note.

Audit record shows attack-class distribution and how many files and entry points each objective names, above its objective list. Click a class bar to filter, or search by objective or file. The file and entry-point totals count every objective of the assessment. Click an objective to open its saved text, files and related entry points in the side panel. Open a file to read its first lines. Newer runs also show what each auditor concluded, with its cited source locations. Open the cited lines without leaving the objective. Older runs keep the objective and its files.

Methodology shows the attack classes applied and the checks the audit tested or analyzed in each checklist pack. For each class, Objectives and Files count the audit objectives that name it. Entry points counts the entry points checked for the class, and With issues and Checked clean divide those entry points. An assessment that recorded no per-entry-point checks leaves those three columns out. Above the table, Verdicts by entry point kind splits the same checks by kind: a cell's number counts the entry points checked, its shade grows with the entry points checked clean, a ring marks a found issue, and hovering a cell shows its counts. An assessment without per-entry-point checks shows no grid. Click an attack class to open the audit record filtered to that class. The report carries the complete checklist, including its inapplicable checks and their recorded reasons.

These views show only facts the audit recorded. Older assessments can therefore show fewer fields. A stored row that cannot be read appears as an error without removing the rest of the list.

Live application assessments

Black-box assessments publish Documentation overview, System, Threats and Entry points. Open an entry point to see its inputs, recorded access and coverage.

Artifacts Coverage lists the tested operations with an outcome for each recorded attack class. Audit record shows the checklist objectives and their outcome counts. A tester that found no injection point or owned object marks that objective Not applicable. An unreachable operation or an objective with no recorded reason stays Not checked. Methodology contains rounds, agents, validators and test sessions. Outcome counts use checklist objectives; the Validators table counts individual validator runs.

HTTP activity identifies requests by test user, or Anonymous when a request has no recorded session. Blocked out-of-scope connections have their own count, separate from HTTP requests and response charts. Baseline requests remain part of the recorded HTTP activity.

Sharing a page

Every tab, item and coverage path has its own address. Search, filters, sort and page stay in the address too:

/assessments/{code}/documentation/entry-points/{entry-point}
/assessments/{code}/artifacts/coverage/{path}
/assessments/{code}/artifacts/audit-record/{objective}

A side panel has Copy link and Copy as Markdown. Markdown includes the item's facts, code references and link so that you can paste it into an issue. Closing a panel opened from a list returns to that list with its filters. Older tab links still open the current tab that replaced them.

Links to the retired Documentation Notes and Artifacts Ruled out pages open the relevant overview.

When an audit recorded its conclusions, Audit record shows each auditor’s reason with links to the cited source lines. A file’s Coverage details can also show the line ranges agents opened. These ranges describe reads and do not change the file’s review depth. Older runs show only the information they recorded.