# PWNISMS Threat Modelling

> Lightweight, security-first threat modelling workflow for code and architecture tasks. Use it to walk all 7 PWNISMS categories, identify plausible threats, prioritize top risks, and propose concrete mitigations before and during implementation.

- Skill: `securityreviewai/pwnisms-threat-modelling-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add securityreviewai/pwnisms-threat-modelling-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/securityreviewai/pwnisms-threat-modelling-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: securityreviewai (https://skillmd.com/u/securityreviewai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/securityreviewai/pwnisms-threat-modelling-2

---


# PWNISMS — On-the-Go Threat Modelling

For EVERY security-relevant task (feature, bug fix, refactor, infra change, architecture design), run a lightweight threat model with PWNISMS.

- Walk through all 7 categories explicitly.
- If a category is not applicable, state it briefly and move on.
- Anchor analysis to linked files, diffs, PRs, API specs, and diagrams whenever available.
- Focus on realistic threats for the current context, not exhaustive attack catalogs.

---

## Inputs to Gather First

Collect these quickly before deep analysis:

- **Scope**: What is changing (feature, component, service, migration, PR)?
- **Assets**: What must be protected (PII, credentials, tokens, configs, accounts, workflows)?
- **Entry points**: How data enters/leaves (HTTP, queues, schedulers, CLI, webhooks, integrations)?
- **Trust boundaries**: Where data crosses users/services/networks/privilege levels?

If the user provided specific code, diffs, or architecture artifacts, prioritize those as primary evidence.

---

## Lightweight Workflow (PWNISMS)

1. **Clarify scope and assumptions**
   - Define the exact unit of analysis.
   - State assumptions explicitly (auth model, deployment boundary, tenant model, etc.).
2. **Map assets and flows**
   - List high-value assets and critical data paths.
   - List entry points and exits across trust boundaries.
3. **Walk all 7 PWNISMS categories**
   - Identify plausible threats for each category.
   - Keep findings concrete and contextual.
4. **Prioritize**
   - Select the top 3-7 risks by impact and likelihood.
5. **Mitigate**
   - Propose concrete, implementable controls for each prioritized risk.
6. **Summarize residual risk**
   - Call out remaining risk, trade-offs, and follow-up actions.
   - Call out unknowns instead of silently guessing.

---

## The 7 Categories (What to Check)

### P — Product

Application and business-logic threats:

- Input validation, injection, insecure deserialization.
- Authorization gaps, privilege escalation, IDOR/BOLA.
- Business logic abuse, replay/race conditions, unsafe redirects.
- Error handling that leaks internals.

### W — Workload

Compute and infrastructure threats:

- Insecure container/runtime posture, over-privileged workload identity.
- Weak host/orchestrator controls and segmentation.
- Insecure data storage/backups and DB configuration.
- Queue/broker abuse and poison-message handling gaps.

### N — Network

Network and transport threats:

- Missing/weak TLS, insecure service-to-service communication.
- Exposed ports/endpoints and permissive ingress/egress.
- Weak segmentation or lateral movement paths.
- API-layer abuse controls missing (rate limits, request limits, CORS hardening).

### I — IAM (Identity & Access Management)

Identity and authorization threats:

- Broken authentication controls and token validation.
- Missing least-privilege RBAC/ABAC.
- Service-to-service auth gaps.
- Escalation paths across users, roles, or services.

### S — Secrets

Credential and key management threats:

- Secrets in code, images, logs, CI output, or defaults.
- Weak rotation, revocation, or token lifetime policies.
- Over-shared secrets across components.
- Missing secret manager/KMS controls.

### M — Monitoring (Logging & Observability)

Detection and auditability threats:

- Missing logs for auth, authorization, admin/data access events.
- Sensitive data leakage in logs.
- Missing alerts for abuse indicators.
- Incomplete audit trails or weak log integrity.

### S — Supply Chain

Dependency and delivery threats:

- Unpinned/unverified dependencies and vulnerable packages.
- Third-party integration trust and scope overreach.
- CI/CD pipeline leakage or unreviewed build scripts.
- Unsigned/unprovenanced artifacts, missing SBOM.
- Treat AI-generated code as untrusted until validated.

---

## Tailor for Architecture / Design Tasks

When discussing designs before code exists:

- Sketch a mental data flow: actors, data sent/received, storage, processing points.
- Mark trust boundaries explicitly (client-backend, backend-DB, service-service, cloud-third party).
- Identify where strong authentication/authorization is mandatory.
- Identify where encryption in transit and at rest is mandatory.
- Recommend concrete security patterns:
  - Parameterized queries / ORM for DB access.
  - Centralized authn/authz and role checks.
  - Secrets manager / KMS for credentials and keys.
  - mTLS or signed requests for service-to-service calls.

---

## Security-First Code Generation Rules

When implementing code, enforce these baseline controls:

1. Validate and constrain all untrusted input.
2. Parameterize all queries and command-like invocations.
3. Enforce least privilege for users, services, and workloads.
4. Never hardcode secrets; use managed secret stores.
5. Encrypt sensitive data in transit and at rest.
6. Log security-relevant actions without leaking secrets/PII.
7. Pin and verify dependencies and build artifacts.
8. Return safe user errors; keep sensitive diagnostics internal.
9. Add abuse protections (rate limits, lockouts, throttling) on exposed interfaces.

---

## Post-Generation Checklist

Before finalizing output, confirm:

- [ ] Scope, assumptions, and trust boundaries were explicit.
- [ ] All 7 PWNISMS categories were checked (or marked N/A explicitly).
- [ ] Top risks were prioritized by impact and likelihood.
- [ ] Mitigations are concrete and actionable.
- [ ] Residual risk and follow-up actions are stated.

If ANY box cannot be checked, you MUST flag the gap to the user with a specific remediation recommendation before finalizing the code.