AgentStack
SKILL verified MIT Self-run

Security Review

skill-notwld-engineering-baseline-security-review · by notwld

Perform mandatory feature-level threat modeling and security verification using STRIDE, OWASP ASVS 5.0.0 Level 2, OWASP Top 10:2025, NIST CSF 2.0, and NIST SP 800-207 Zero Trust. Use for every new feature and material behavior change, and for reviews involving authentication, authorization, trust boundaries, APIs, untrusted input, sensitive data, secrets, cryptography, files, external URLs, depen…

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-notwld-engineering-baseline-security-review

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Security Review? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Security Review

Treat security as a design and verification gate. Perform the lightweight form for every feature; expand it whenever data, privileges, trust boundaries, or availability are affected.

For first-run adoption of an existing application, remain read-only until the Adopt Existing Project approval gate completes. Produce requirement-level ASVS and framework gap evidence during assessment; do not silently implement fixes.

Mandatory pre-implementation gate

Before writing implementation code:

  1. Describe the feature, assets, actors, entry points, data flows, external

dependencies, privilege levels, and trust boundaries.

  1. State data classification, retention, tenant boundaries, and abuse cases.
  2. Produce a STRIDE table covering all six categories. For each category record:

threat | applicable/N/A with reason | mitigation | planned verification.

  1. Identify applicable OWASP ASVS 5.0.0 Level 2 requirements. Use versioned IDs

such as v5.0.0-8.3.1; do not claim Level 2 compliance from chapter names alone.

  1. Map applicable OWASP Top 10:2025 risks and explicitly check SSRF even though

it is no longer a standalone 2025 category.

  1. Map the design to all six NIST CSF 2.0 functions: Govern, Identify, Protect,

Detect, Respond, and Recover.

  1. Apply Zero Trust: no implicit trust from network location, device ownership,

client state, or prior access. Authenticate and authorize access to each protected resource using server-side policy.

  1. Mention the selected mitigations before implementation. Do not continue when

a critical threat has neither a mitigation nor an explicitly accepted owner.

For a cosmetic or documentation-only change, still state that no executable behavior, trust boundary, protected asset, or sensitive data flow changed and mark the framework checks N/A with that reason.

Implementation invariants

  • Verify authorization at object and operation level on every server-side path.
  • Treat the frontend, hidden UI, cookies, headers, query parameters, path

parameters, request bodies, filenames, redirects, webhooks, queues, caches, and upstream responses as untrusted.

  • Validate type, structure, range, length, encoding, canonical form, and business

rules before use; encode output for its destination context.

  • Use parameterized interfaces and maintained platform security primitives.
  • Deny by default, grant least privilege, separate duties, and fail securely.
  • Bind security decisions to current server-side identity, tenant, resource,

action, device/workload context when available, and policy—not client claims.

  • Protect secrets and keys with managed stores; never log credentials, tokens,

sensitive payloads, or unnecessary personal data.

  • Make security events attributable and tamper-resistant without exposing data.
  • Bound CPU, memory, request size, concurrency, retries, and expensive actions.
  • Pin and review dependencies and build provenance; verify artifacts before use.

Post-implementation gate

  1. Revisit every STRIDE row and test each mitigation.
  2. Record each applicable ASVS L2 requirement as pass, fail, or N/A with

evidence. A scanner result alone is not ASVS verification.

  1. Review all OWASP Top 10:2025 categories plus the explicit SSRF gate.
  2. Execute abuse and negative tests for unauthorized, cross-tenant, malformed,

replayed, oversized, concurrent, rate-limit, timeout, and dependency-failure scenarios where applicable.

  1. Run available SAST, dependency, secret, IaC, container, and dynamic scans that

match the changed surface. Triage findings by exploitability and impact.

  1. Verify NIST Detect/Respond/Recover outcomes: useful telemetry, alert path,

containment or revocation, rollback, restoration, and lessons learned.

  1. Report residual risks, owner, severity, due date or acceptance, and evidence.

Read [references/checklist.md](references/checklist.md) for the operational framework checklist and [references/framework-crosswalk.md](references/framework-crosswalk.md) when mapping a feature across frameworks.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.