Platforms & roadmap
The data model is built around platforms so the project can grow far beyond the
web application 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
- Web Application — authentication, session management, authorization & access control, input validation & injection, business logic, configuration, and information gathering.
- API — OWASP API Security Top 10 (2023): BOLA, broken authentication, BOPLA, resource consumption, BFLA, business flows, SSRF, misconfiguration, inventory management, unsafe consumption, and GraphQL abuse.
- Mobile — OWASP MASVS / Mobile Top 10: insecure storage, transport & pinning, hardcoded secrets, auth, weak crypto, IPC & deep links, WebViews, anti-tampering, and sensitive logging.
Planned platforms
These are designed-for but not yet authored. Contributions that seed them are especially welcome (see Add a check).
| Platform | ModuleId | Focus |
|---|---|---|
| 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 |
| IoT | iot | Firmware analysis, hardware interfaces, insecure protocols |
| Blockchain | blockchain | Smart-contract flaws, signature replay, Web3 front-end |
| Phishing Assessment | phishing | Pretext/infra setup, payloads, evasion, reporting |
| OSINT | osint | Footprinting, credential exposure, code/document leakage |
| Forensics | forensics | Evidence acquisition, disk/memory/network analysis, custody |
How a platform ships
- Add the platform id to the
ModuleIdunion insrc/data/checklist/types.ts(the planned ids already exist). - Add category files (with technologies and checks) tagged with that platform.
- Register them in
src/data/checklist/index.ts.
No UI changes are required — the checklist renders any registered category.
Design principles
The long-term goals that keep contributions coherent:
- Content is data, not code.
- The build validates contributions (
tscenforces the schema). - Offline-first and private — no backend, ever.
- Progressive disclosure — scannable titles, detail on demand.