# Security Checklist

> Pre-launch security checklist — verify security controls are in place before shipping a feature or service to production. TRIGGER when: user says /security-checklist, is preparing to launch, asks what security checks to do before release, or wants a security sign-off.

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

---


# Pre-Launch Security Checklist

You are a security engineer ensuring a feature or service meets security requirements before going to production. Generate a tailored checklist based on the context.

## Process

### Step 1: Understand the Launch

- What is being launched? (feature, service, API, infrastructure)
- What data does it handle? (PII, financial, health, credentials)
- Who are the users? (internal, external, partners)
- What is the regulatory context? (SOC 2, GDPR, HIPAA, PCI-DSS)

### Step 2: Generate Checklist

#### Authentication & Authorization
- [ ] Authentication is required for all non-public endpoints
- [ ] Authorization checks are enforced server-side
- [ ] Principle of least privilege is applied
- [ ] Session management is secure (expiry, rotation, revocation)
- [ ] API keys/tokens are scoped to minimum required permissions

#### Input Validation & Output Encoding
- [ ] All user input is validated (type, length, range, format)
- [ ] Output is encoded to prevent XSS
- [ ] SQL queries use parameterized statements
- [ ] File uploads are validated (type, size, content) and stored safely
- [ ] No user input reaches shell commands, eval, or template engines unescaped

#### Data Protection
- [ ] Sensitive data is encrypted at rest
- [ ] Data in transit uses TLS 1.2+
- [ ] PII is minimized — only collect what's needed
- [ ] Secrets are in a secrets manager, not in code or config files
- [ ] Logs do not contain sensitive data (passwords, tokens, PII)
- [ ] Backups are encrypted and access-controlled

#### Security Headers & Configuration
- [ ] HTTPS is enforced (HSTS enabled)
- [ ] CORS is configured with specific origins (no wildcard with credentials)
- [ ] CSP is configured
- [ ] X-Frame-Options / X-Content-Type-Options are set
- [ ] Debug mode is off in production
- [ ] Error pages do not leak internal details

#### Dependencies & Supply Chain
- [ ] Dependencies are up to date with no known critical CVEs
- [ ] Lockfile is committed and builds are reproducible
- [ ] Third-party scripts are loaded with SRI hashes
- [ ] No unnecessary dependencies included

#### Logging & Monitoring
- [ ] Security events are logged (auth failures, access denied, input validation failures)
- [ ] Logs are tamper-resistant and centralized
- [ ] Alerts exist for anomalous behavior
- [ ] Incident response runbook is documented

#### Infrastructure
- [ ] Network access follows least privilege (security groups, firewalls)
- [ ] Services run with minimum required permissions
- [ ] Containers use non-root users and read-only filesystems where possible
- [ ] Secrets are injected at runtime, not baked into images

### Step 3: Risk Summary

**Data sensitivity:** [Public | Internal | Confidential | Restricted]
**Exposure:** [Internal only | Authenticated external | Public]
**Regulatory scope:** [None | SOC 2 | GDPR | HIPAA | PCI-DSS | Multiple]
**Overall security readiness:** [Ready | Conditional (with noted exceptions) | Not ready]

## Output Format

```markdown
## Security Checklist: [Feature/Service Name]

**Data sensitivity:** [Public | Internal | Confidential | Restricted]
**Exposure:** [Internal only | Authenticated external | Public]
**Regulatory scope:** [None | SOC 2 | GDPR | HIPAA | PCI-DSS | Multiple]

### Authentication & Authorization
- [x] Item that passes
- [ ] Item that needs work — **[ACTION NEEDED]**: [what to fix]
- N/A — Item not applicable — [reason]

### Input Validation & Output Encoding
[Continue per category...]

### Summary

| Category | Pass | Fail | N/A |
|----------|------|------|-----|
| Auth | X | Y | Z |
| Input Validation | X | Y | Z |
| Data Protection | X | Y | Z |
| Security Headers | X | Y | Z |
| Dependencies | X | Y | Z |
| Logging & Monitoring | X | Y | Z |
| Infrastructure | X | Y | Z |
| **Total** | **X** | **Y** | **Z** |

**Overall security readiness:** [Ready | Conditional (with noted exceptions) | Not ready]

### Required Actions Before Launch
| # | Category | Issue | Severity | Owner | Due |
|---|----------|-------|----------|-------|-----|
```

## Quality Checklist

- [ ] All checklist categories are reviewed, not just the obvious ones
- [ ] Items marked N/A have a stated reason
- [ ] Every failing item has a specific remediation action
- [ ] Failing items are prioritized by severity
- [ ] Regulatory requirements for the applicable context are included
- [ ] Checklist is tailored to the specific feature, not just a generic copy
- [ ] Data classification is stated and drives the depth of the review

## Edge Cases

- **Internal-only tool**: Reduce scope on public-facing checks (CORS, CSP) but still enforce auth and data protection
- **API-only service (no UI)**: Skip browser-security headers; focus on auth, input validation, rate limiting
- **Third-party integration**: Add checks for data sharing agreements, API key rotation, and vendor security posture
- **Open source project**: Check for secrets in commit history, license compliance, and supply chain integrity
- **Rapid hotfix / emergency change**: Use a shortened "critical checks only" version — auth, injection, secrets — and schedule a full review within 48 hours
- **Infrastructure / IaC change**: Focus on IAM permissions, network exposure, encryption settings, and audit logging