[!IMPORTANT] This audit covers application-level security only. Production infrastructure (TLS termination, reverse proxy, network segmentation, firewall rules, DNS) is managed by a separate project and is out of scope. Do not flag missing TLS, reverse proxy configuration, network-level MITM risks, or production deployment topology as findings.

• Scope: Full codebase or specific area? (e.g.,

  apps/api/src/auth/

  ,

  apps/web/src/

  )
• Trigger: What prompted this audit? (routine, pre-release, security incident, new feature, dependency update)
• Focus areas: Authentication, API security, data protection, frontend security, or all?

/security-scanning:security-sast

• Injection: SQL injection, NoSQL injection, command injection, LDAP injection
• XSS: Reflected, stored, and DOM-based cross-site scripting
• CSRF: Missing CSRF protections on state-changing endpoints
• Authentication: Weak password policies, broken auth flows, session fixation
• Secrets: Hardcoded API keys, passwords, tokens, connection strings
• Dependencies: Known vulnerabilities in npm packages (CVEs)
• Deserialization: Insecure deserialization patterns
• Prototype pollution: JavaScript-specific object manipulation attacks

• Severity: Critical / High / Medium / Low / Info
• Category: OWASP Top 10 mapping
• Location: File path and line number
• Description: What the vulnerability is
• Evidence: The specific code pattern that triggered the finding
• Remediation: How to fix it

• Security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options)
• CORS configuration (allowed origins, methods, headers)
• Cookie security flags (HttpOnly, Secure, SameSite)

• Rate limiting on all public endpoints
• Input validation completeness (every user input validated)
• Output encoding to prevent injection
• API key and token management
• Request size limits

• Password hashing algorithm (bcrypt, argon2)
• JWT configuration (algorithm, expiration, refresh)
• Session management (timeout, invalidation, rotation)
• Role-based access control enforcement
• OAuth/OIDC configuration (if applicable)

• PII encrypted at rest
• Sensitive data encrypted in transit (TLS 1.2+)
• Logging does not include sensitive data
• Error messages do not leak internal details
• Database connection uses SSL

• No secrets hardcoded in code or logs
• Startup validation rejects weak/default secrets in production

• Can user identities be faked? (auth bypass, token theft)
• Can service identities be spoofed? (service-to-service auth)

• Can request data be modified in transit?
• Can database records be altered without authorization?
• Can client-side data (localStorage, cookies) be tampered?

• Are all security-relevant actions logged?
• Can a user deny performing an action?
• Is there an audit trail for data changes?

• Can sensitive data leak through error messages?
• Can unauthorized users access other users' data?
• Are there timing attacks or side-channel leaks?

• Can the system be overwhelmed by excessive requests?
• Are there resource-intensive endpoints without rate limiting?
• Can large payloads cause memory exhaustion?

• Can a regular user access admin functionality?
• Can horizontal privilege escalation occur (access another user's resources)?
• Are there IDOR (Insecure Direct Object Reference) vulnerabilities?

• Likelihood: High / Medium / Low
• Impact: Critical / High / Medium / Low
• Risk Score: Likelihood x Impact
• Existing Mitigations: What's already in place
• Gaps: What's missing

/security-scanning:attack-tree-construction

• Attack goal: What the attacker wants to achieve
• Attack paths: Different ways to reach the goal
• Sub-goals: Intermediate steps required
• Required resources: Attacker skill level, tools, access needed
• Existing defenses: Current mitigations along each path
• Weakest links: Where defenses are thinnest

.claude/councils/architecture-council.md

Model Selection: See the Model Selection section in README.md for mapping agent model specs to Task tool parameters.

• Validate automated findings (identify false positives)
• Prioritize remediation based on actual risk
• Assess overall security posture
• Assessment: Strong / Adequate / Needs Improvement / Critical Risk

• Assess architectural implications of required remediations
• Identify systemic patterns that create vulnerabilities
• Recommend architectural changes for defense-in-depth
• Assessment: Architecturally sound / Needs refactoring / Fundamental issues

• Evaluate backend-specific security patterns
• Assess API security implementation quality
• Review database access patterns for injection risks
• Assessment: Well-secured / Some gaps / Significant concerns

• Overall Security Posture: Strong / Adequate / Needs Improvement / Critical
• Total Findings: Count by severity (Critical, High, Medium, Low)
• Top 3 Risks: The most important issues to address
• STRIDE Coverage: Summary of threat categories with risk levels

• Severity, category, and OWASP mapping
• File and line number
• Description with evidence
• Step-by-step remediation
• Effort estimate (quick fix / moderate / significant)

• STRIDE analysis results table
• Top 3 attack trees (visual or structured text)
• Defense gap analysis

1. Immediate (Critical): Must fix before next deployment
2. This Sprint (High): Fix within current work cycle
3. Next Sprint (Medium): Schedule for upcoming work
4. Backlog (Low): Track as technical debt

1. Address findings in priority order (Critical first, then High)
2. For each fix:
   • Apply the remediation
   • Re-run the relevant SAST scan to verify the fix
   • Run tests to ensure no regressions
3. Commit each fix with:

   fix(security): remediate <finding-description>

build-ready

[!NOTE] Add the

build-ready

label to findings with a clear, scoped remediation (the fix is known and does not require architectural decisions). Omit

build-ready

for findings that need further planning via

/plan-feature

— for example, findings that require schema changes, new infrastructure, or cross-cutting architectural decisions.

1. For each approved finding, create a GitHub issue:
   bash

   ISSUE_URL=$(gh issue create \
     --title "security: <finding-description>" \
     --body "<body>" \
     --label "enhancement" \
     --label "security-audit" \
     --label "build-ready")
   
   ISSUE_NUM=$(echo "$ISSUE_URL" | grep -o '[0-9]*$')

   Omit

   --label "build-ready"

   for findings that need further planning (see NOTE above).
   The issue body should include:
   • Context: Which audit identified this finding and the audit date
   • Problem: Description with file path and line number
   • Recommended Fix: Step-by-step remediation from the audit report
   • Priority: Severity rating and recommended timeline
   • Files: Affected file paths
2. Add each created issue to the project board and set fields:
   bash

   ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$ISSUE_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>

   Set phase, size, and dates appropriate to the finding's priority and the current milestone:

   Severity	Typical Size	Schedule Priority
   Critical/High	M (3 days) or L (5 days)	Current active milestone, near the front of the queue
   Medium	S (2 days)	Current milestone, after existing scheduled items
   Low/Info	XS (1 day)	Current milestone or next, at the end of the queue

3. Report all created issue numbers (

   $ISSUE_NUM

   ) and URLs to the user.

[!IMPORTANT] Every tracked finding must have both a GitHub issue and a project board entry. Creating an issue without adding it to the project board is what causes orphaned work items that

/build-feature

cannot discover via auto-pick.

/security-audit #137

1. Check off any audit checklist items in the issue body using

   gh issue edit

2. CHECKPOINT: Ask the user whether to close the issue now that the audit is complete. Present the issue number and title for confirmation.
3. If approved, close the issue:
   bash

   gh issue close <number> --reason completed

• If code was changed (remediation applied): Run

  /review-code

  to verify fixes in context of other changes
• If no code was changed (audit-only): No further action needed — track findings as issues or technical debt
• If starting a new feature: Run

  /plan-feature

  to begin the next feature with audit findings in mind

/plan-feature

/build-feature

/build-api

/review-code

/submit-pr

/security-audit