Documentation and Artifacts
A completed code audit gives you two read surfaces beside its findings. Documentation describes the application the audit worked from. Artifacts records what the run did. Both open from the assessment's Insights & Tools panel.
Documentation
How the application is built, what it protects, and where it can be reached.
Entry points
Every way into your application, and what guards each one.
For each entry point the audit answers four questions: authentication, authorization, rate limiting, and input validation. The table puts the answers side by side, because that is the comparison worth making. Eleven routes throttled and one not shows up only when every row answers the same four.
Each answer is one of four:
| Answer | Means |
|---|---|
| Enforced | A check is in place |
| None | Nothing checks this, and the audit links to where the request reaches its effect unchecked |
| Not applicable | The question does not arise here, and the audit says why |
| Not reviewed | Nobody looked |
None and Not reviewed are kept apart on purpose. "Nothing checks this" is something you can act on. "Nobody looked" means the audit has no answer for that route, so read it as an open question.
HTTP routes show their method and path. Scheduled jobs, command-line entry and browser event handlers answer on no route, so they show the surface they are reached through. A surface the audit could not establish reads "Other".
Filter by surface, search by method or path, or narrow to the entry points missing a control. Open a row in place for the values it accepts and their shapes, the reason behind each answer, and links into Code explorer.
Parameter shapes retain explicit numeric widths and fixed array lengths, such as "unsigned 8-bit integer" and "array[16] of unsigned 8-bit integer". A platform-width integer keeps its width unspecified. A symbolic length shows its expression; it does not claim a computed size or memory layout. Missing type detail stays unspecified.
Architecture, trust, and threats
- Architecture: an interactive map of the system, plus the components and operations behind your entry points.
- Trust & security: the actors that use the application, the assets it protects, its trust boundaries, and its security protocols.
- Threat model: the attack paths the audit expects. What it confirmed is in Findings.
- Notes: anything your team wrote against this assessment.
- Overview: the counts across all of the above, and where controls are missing.
Every entry links back to the source it was read from.
Artifacts
What the run did: the source it read, the testing checklist it walked, the audit work it planned and completed, how much of your code it covered, and the counts its pipeline produced.
The checklist prints every check the run owed an answer for, with its answer. Where the run judged a check inapplicable to your codebase, or could not complete it, the reason sits under the check — those are the two answers worth arguing with.
Sharing a page
Each tab has its own address, so a link opens on the tab you were reading:
/assessments/{code}/documentation/entry-points
/assessments/{code}/artifacts/coverage
Availability
Both surfaces appear once an audit completes. A section with nothing behind it is hidden. An assessment that ran before a section existed says so on that section.