Platforms & roadmap
The data model is built around platforms so the project can grow far beyond any
single surface without refactoring. Each platform is just a value of the ModuleId
type and a set of category files (each holding technologies and checks) tagged with
it.
Live now
All 23 platforms below are live. Each has its own dashboard at
/checklist/<module-id>, and the all-platforms view is at /checklist.
| Platform | ModuleId | Focus |
|---|---|---|
| Web Application | webapp | Authentication, sessions, access control, injection, business logic, configuration |
| API | api | OWASP API Security Top 10 (2023): BOLA, broken auth, BOPLA, resource consumption, BFLA, SSRF, inventory, GraphQL |
| Mobile | mobile | OWASP MASVS / Mobile Top 10: storage, transport & pinning, secrets, IPC, WebViews, anti-tampering |
| Thick Client | thick-client | Local storage, IPC, traffic interception, binary protection |
| Secure Code Review | secure-code-review | Dangerous sinks, injection patterns, secrets, dependencies |
| Cloud | cloud | IAM, storage exposure, metadata SSRF, misconfig |
| DevSecOps | devsecops | SAST/DAST/SCA gates, secrets, supply chain, policy-as-code |
| Network | network | Host discovery, service enumeration, transport hardening |
| Wi-Fi | wifi | WPA2/WPA3, rogue/evil-twin APs, handshake attacks |
| Firewall | firewall | Ruleset review, egress filtering, segmentation, evasion |
| Active Directory | active-directory | Enumeration, Kerberos attacks, ACL abuse, lateral movement |
| Infrastructure | infrastructure | Host/OS hardening, patch posture, exposed services |
| MCP Security | mcp-security | Tool poisoning, prompt injection, authz scoping |
| LLM Security | llm-security | OWASP LLM Top 10: prompt injection, output handling, agency |
| Threat Modeling | threat-modeling | STRIDE, attack trees, trust boundaries, abuse cases |
| Configuration Review | configuration-review | CIS-style baselines, hardening, default credentials |
| Containers & Kubernetes | container-kubernetes | Image hygiene, escapes, RBAC, network policies, admission |
| CI/CD | cicd | Poisoned pipelines, secret exfil, runner compromise, dependency confusion |
| IoT | iot | Firmware analysis, hardware interfaces, insecure protocols |
| Blockchain | blockchain | Smart-contract flaws, signature replay, Web3 front-end |
| Phishing | phishing | Pretext/infra setup, payloads, evasion, reporting |
| OSINT | osint | Footprinting, credential exposure, code/document leakage |
| Forensics | forensics | Evidence acquisition, disk/memory/network analysis, custody |
Coverage runs to 1,000+ checks and keeps growing. The roadmap from here is depth, not breadth: more technologies and checks within each platform.
How a platform grows
The same data-only workflow that shipped these platforms keeps them growing:
- Add category files (with technologies and checks) tagged with the platform's
ModuleId, undersrc/data/checklist/categories/. - Register them in
src/data/checklist/index.ts.
No UI changes are required — the checklist renders any registered category. Adding a
brand-new platform follows the same pattern, plus one line: add its id to the
ModuleId union and an entry in src/data/checklist/modules.ts.
Design principles
The long-term goals that keep contributions coherent:
- Content is data, not code.
- The build validates contributions (
tscenforces the schema,bun testchecks unique ids and references). - Offline-first and private — no backend, ever.
- Progressive disclosure — scannable titles, detail on demand.