Drive every assessment through a defined methodology, track completion item by item, and tag findings to ATT&CK so coverage is provable instead of assumed.
A checklist gives security teams a structured, trackable task list that lives inside a project. It runs on two entities: Templates, the reusable company-wide or system-provided methodologies, and Project Checklists, the instances attached to a specific project. Together they let analysts drive a pentest through a defined standard and track completion step by step.
Templates ship as system methodologies or are authored as custom company standards, each carrying a JSON array of items with a title, a category, notes, and a completion flag. When a template is attached to a project the items are copied at creation time, so the instance is decoupled from later template edits and the project record stays stable through an engagement.
The hard problem is not listing test steps. It is proving that a methodology was followed end to end, with progress that reflects real completion rather than a stale snapshot.
At a glance
- Two entities: Reusable Templates plus per-project Checklist instances that copy items at creation
- Template types: owasp_web, pci_dss, internal_pentest, custom; type is a free string, defaults to custom
- System templates: is_system templates ship with the platform and cannot be deleted through the API
- Copy-on-create: A template_id with no items copies the methodology once, then the instance is independent
- Progress: Integer 0 to 100, computed server-side on every write, stored and never stale
- Item replace: PUT items replaces the whole array atomically and recomputes progress in one statement
- ATT&CK catalogue: Enterprise v14, about 180 techniques across 12 tactics, idempotent upsert on seed
How it works
A methodology is authored once as a reusable template, copied into each project as an independent instance, tracked item by item with server-computed progress, and mapped to ATT&CK techniques so coverage is provable rather than assumed.
Spinning up a methodology on a project should be one action, not a manual rebuild. When a project checklist is created with a template_id and an empty item array, the service fetches the template and copies its items, so one click stands up a full OWASP or PCI DSS checklist that is thereafter independent of the source template.
A methodology built once should serve every project, and the coverage it produces should be a number teams can trust. Per-project instances carry copied items so each engagement is stable, while progress and ATT&CK tagging turn day-to-day work into a coverage record that reporting and the navigator heatmap can render.
Key capabilities
- Author once, reuse everywhere. A template carries the full methodology as a JSON item array authored in a single call, so a complete OWASP or PCI DSS set is defined once. System templates ship with the platform and are protected from deletion, and custom company standards are created, edited, and searched alongside them.
- Progress you can trust. Progress is recomputed server-side on every create and every item update as done count times one hundred over total count, returning zero for an empty list. It is stored on the row and never left stale, so a progress bar reflects real completion at the moment of the last write.
- Findings mapped to ATT&CK. Findings store an array of MITRE technique IDs that reference the canonical v14 catalogue. Analysts tag techniques directly through a typeahead picker, and when a vuln template is applied its technique array backfills onto a finding whose own array is still empty.
- Coverage rendered, not claimed. The ATT&CK navigator groups techniques by tactic for a heatmap view, and bulk ID resolution turns technique arrays into full objects for report enrichment. Multi-tactic techniques carry all their tactic IDs, so a single technique appears under each tactic it spans.
Use cases
- Stand up an OWASP engagement. A pentest lead opens a new project, picks the system OWASP Web template, and creates a project checklist with no items. The service copies the full methodology in one call, and the instance is independent so a later template edit never disturbs the running engagement.
- Author a company standard. A security manager authors a custom internal_pentest template, writing the entire item list with categories and notes in a single create call. The template joins the library system-first ordering and is reused across every future project without rebuilding from scratch.
- Track day-to-day completion. An analyst works through the checklist, toggling items done as each test passes. The full-replace items call rewrites the array atomically and recomputes progress, so the project progress ring reflects real completion the moment the change lands.
Methodology authored once, tracked item by item, mapped to ATT&CK and provable.
