05 — Security Checklist#

Assess confidentiality, integrity, availability, abuse resistance, and operational security proportionate to project risk.

Scope: Shared / cross-cutting. This file is one part of the 05_Security.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this template into each project's review records; keep the shared repository template unchecked.
2. Check [x] only after verifying the item with evidence. For any inapplicable item, record N/A and the reason in the project's own review notes or issue tracker using its checklist ID; do not mark it as passed.
3. Record evidence links or artifact references by checklist ID. Open an issue for every failed item, assign an owner and due date, and retest after remediation.
4. Apply the release gate below. These checklists guide review; they do not replace qualified specialist review when required.

Security scope and architecture#

• SEC-001 Assets, sensitive data, trust boundaries, external dependencies, and data flows are inventoried.

• SEC-002 A threat model covers realistic attacker goals, entry points, misuse cases, and mitigation owners.

• SEC-003 Data classification and environment-specific security requirements are documented.

• SEC-004 Security owners, risk ratings, release criteria, and exception approvals are assigned.

• SEC-040 Record API and browser attack surfaces including trust boundaries between client, identity provider, API gateway, and backend.

• SEC-042 Set risk-based verification objectives using an explicitly selected ASVS level or equivalent benchmark.

Identity and access management#

• SEC-006 Authentication uses reputable standards/libraries; multi-factor authentication protects privileged accounts.
• SEC-008 Least privilege, role separation, service-account scopes, and periodic access reviews are applied.
• SEC-009 Sessions, tokens, password resets, account recovery, and logout are securely managed.
• SEC-010 Brute-force defenses, credential-stuffing controls, and abuse limits are tested.
• SEC-011 Default, dormant, emergency, and vendor accounts are reviewed and restricted.
• SEC-043 Require reauthentication or step-up assurance for high-risk operations where appropriate.
• SEC-044 Revoke and expire compromised/rotated tokens; verify session invalidation across devices where supported.

Application, API, and supply-chain security#

• SEC-012 Inputs are validated and outputs safely encoded; injection and unsafe deserialization risks are tested.
• SEC-016 Build/release pipelines restrict permissions, verify artifact provenance where feasible, and protect signing credentials.
• SEC-017 Static analysis, secret scanning, and risk-based dynamic or penetration tests are performed.
• SEC-018 Security fixes are regression tested and documented.

Secrets, encryption, and data protection#

• SEC-020 Secrets are centrally managed, rotated when necessary, and scoped to their purpose.
• SEC-021 TLS is enforced for sensitive traffic; certificates and cryptographic settings are maintained.
• SEC-023 Data collection, retention, masking, export, deletion, and backup access follow documented policy.
• SEC-024 Logs, traces, analytics, and error reports exclude secrets and unnecessary personal data.

Infrastructure and deployment#

Operational readiness and incident response#

• SEC-031 An incident response plan defines severity, contacts, containment, recovery, notification, and evidence handling.
• SEC-032 Known vulnerabilities have remediation deadlines based on severity and exposure.
• SEC-033 Vulnerability reporting and dependency/security update ownership are defined.
• SEC-034 Business continuity, DDoS/availability protection, and disaster recovery match project risk.
• SEC-035 Security alerts are routed to responders and can be meaningfully investigated.
• SEC-054 Exercise suspected credential leak and compromised dependency response, including token rotation and customer notice decisions.
• SEC-055 Record automated security test results and residual risk approvals against the release commit.

Release gate#

• All applicable high-priority checks above pass, or an authorized decision-maker has explicitly accepted and documented each residual risk.
• Failed items have tracked remediation, owners, and deadlines; material blockers remain blocked until resolved.
• Evidence links and the reviewer, review date, and final decision are recorded.

Domain-specific approval rule: Block release for exploitable critical/high findings without approved mitigation, missing authorization boundaries, exposed secrets, or unprotected sensitive data.

Trusted references and scope#

The checks above are adapted into practical verification questions from these authoritative publications (not copied as standards text). Verify current versions and the project's scope before sign-off.

• OWASP API Security Top 10 (2023)
• OWASP Application Security Verification Standard (ASVS) 5.0
• OWASP ASVS 5.0 control families (web frontend and API)
• NIST — Generative AI Risk Management Profile
• W3C — WCAG 2.2 Quick Reference

Guidance is risk-based and project-specific; sources do not replace testing or specialist review.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: secrets, authorization, dependency vulnerabilities, attack surfaces, and validation failures; include shared/cross-team controls where applicable.
• Cross-stack: OWASP ZAP + Gitleaks + Trivy.
• Python: Bandit + pip-audit + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: ESLint + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• security-threat-model — Identify assets, trust boundaries, and abuse paths (openai/skills, 28,705 repo stars).
• sharp-edges — Assess unsafe defaults and misuse risks (trailofbits/skills, 8,150 repo stars).
• semgrep — Find review candidates using static security rules (trailofbits/skills, 8,150 repo stars).

How to check: In a project-specific copy, have the agent audit the shared / cross-cutting scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.