How the data is organized

Five records carry most of Red Clippy: organizations, pentests, assets, observations and findings. This page explains what each one holds and where the boundary between them sits.

Organizations

An organization owns pentests, and each pentest owns the assets, findings and evidence for that engagement. One organization can see nothing belonging to another, so two clients’ engagements never mix.

If you test for one company, a single organization is all you need. If you consult for several clients, give each client its own.

An organization has two names:

• the display name (“Northwind Retail”), shown in the panel, changeable at any time
• the slug (northwind), a short lowercase identifier that cannot be changed once set, and that names the organization’s folder on disk

You can belong to several organizations and switch between them without signing out. In each one you are either an owner, who can add and remove people and rename or delete the organization, or a member, who works the engagements. See Organizations and members.

API keys are org-scoped: a key issued in Northwind can only ever read or write Northwind data. This is how one client’s data stays out of another client’s agent session.

Pentests

A pentest is one round of testing: a quarterly assessment, an annual review, a retest of last round’s findings. A client you test on a cycle accumulates one pentest per round, each with its own scope, dates and findings.

It carries a code, a name, a free-text scope description, start and end dates, a status and a notes field.

The code (PT-2026-Q3-NORTHWIND) identifies the engagement and cannot be changed once created. Leave it blank and the server generates one from the name and today’s date.

Status is one of planned, in_progress, completed or archived.

Creating a pentest seeds two things automatically:

• five engagement phases (scoping, recon, testing, reporting, retest), which track the pulse of the engagement as a whole
• the check catalogue, 135 built-in checks. Each asset gets its own copy of the ones that apply to it, the first time you open its methodology tab

Assets and observations

An asset is a unit you actually test. It has one of five kinds:

Each asset carries its own methodology checklist, its own file area, an in-scope or out-of-scope flag, and a reachability marking (up, down, blocked, or unmarked).

An observation is something you noticed about an asset: a discovered path, a technology fingerprint, a DNS record, a certificate, a leaked credential, an open port, a wayback URL, an employee name. Observations attach to an asset rather than joining the scope list, and their kind is free text. The panel offers the conventional ones (port, service, dns_record, tech, cert, whois, email, employee, credential_leak, secret, screenshot, asn, takeover_candidate, default_cred_portal, wayback_url, js_endpoint, other) and accepts anything else you type.

The split matters because of volume. A single content-discovery run produces thousands of URLs. If each one became an asset, the asset list would be worthless and every one of them would drag in its own 100-plus item checklist. As observations they sit under the asset they came from, searchable and out of the way, and you promote the handful that deserve their own testing surface into real assets.

Two more things live alongside assets:

• IP ranges: the CIDRs the customer declared, marked in-scope or out-of-scope. Marking a range fans the decision out to every IP asset inside it. See The network view.
• API endpoints: for an api asset, a structured list of operations (method, path, headers, request and response bodies) with copy-as-cURL and OpenAPI export.

An asset can also be an alias of another. Mark www.northwind.test as an alias of northwind.test and the second one becomes the canonical: the row that carries the testing. The alias inherits its scope and reachability, and testing the canonical covers both.

Coverage: phases and checks

Coverage is tracked at two levels.

Engagement phases are the five seeded steps, plus any you add. They answer “where are we in this engagement”, and there are only a handful of them so the answer stays readable. Each has a status (pending, in_progress, done, na, blocked) and a notes field.

Checks are per asset. The catalogue holds 135 entries drawn from the OWASP Web Security Testing Guide (95 of them), the OWASP API Security Top 10, CIS quick wins and PTES, grouped into categories such as recon, config, input, auth, authz, session, crypto, client, business_logic and cloud. Each entry lists which asset kinds it applies to, so a mobile asset does not inherit web-only checks.

A check on an asset is not_tested, in_progress, tested, not_applicable or blocked, and carries its own notes. Marking not_applicable counts as resolved for coverage purposes. “We looked and it does not apply here” is a real answer, and it should not sit in the untested pile forever.

Findings

A finding is something you are prepared to put in the report. It has a title, severity, status, the affected asset and URL, a CVSS 3.1 vector and score, CWE and CVE identifiers, and four bodies of text: details, impact, proof of concept, and remediation.

Severity is critical, high, medium, low or info. Status is open, confirmed, remediated, accepted or false_positive.

Findings also carry tags, a comma-separated list. Two conventions matter because the panel filters on them:

• asset:<value> ties the finding to an asset, so it appears on that asset’s Findings tab
• check:<code> ties it to a catalogue check, so it appears under that check in the workspace

Files attach to findings as evidence: screenshots render inline, everything else downloads.

Supporting records

• Files: each pentest has a file area, and so does each asset. Ordinary folders and uploads, for scan output and anything else you want kept with the engagement.
• Notes: a free-text scratchpad on the pentest, plus notes on every phase, check and asset.
• Attack graph: any two nodes (asset, observation or finding) can be linked with a free-form relation. You can then walk neighbours or compute the shortest path between two nodes.
• Scans: an optional built-in runner for subfinder, nmap, masscan and naabu, with resumable per-target coverage. See Ports and the scan engine.
• Red Team Instructions: the operating doctrine handed to an agent. It resolves most-specific-first, from a per-engagement override, to an organization default, to the document built into the binary. See Red Team Instructions.