security-review

name

security-review

description

Security assessment workflow in two modes: architectural (design) and code (implementation). Use when a security trigger is detected during planning (architectural mode) or implementation/review (code mode). Covers STRIDE, OWASP, dependency scanning, Azure compliance, and GitHub security alerts. Do not use for general code quality (use devsquad.review), for threat modeling as a standalone activity, or for compliance audits.

Security Review

Security Principles

Principle	Application
CIA Triad	Confidentiality, Integrity, Availability in every assessment
Defense in Depth	Multiple layers; never rely on a single control
Least Privilege	Minimum permissions for each component
Secure by Default	Default configurations must be secure
Zero Trust	Never trust, always verify
Shift Left	Detect issues early in design, not in production

Mode Detection

Determine the operating mode from the calling agent's context:

Architectural Mode (called from plan):

• Handoff from the plan agent after ADR creation
• Feature involves: auth, sensitive data, external APIs, payments

Code Mode (called from implement or review):

• Handoff from the implement agent after implementation
• Reference to specific files or diff

---

Architectural Mode (Design Security)

When to Execute

This mode is mandatory when the feature involves:

Trigger	Description
Authentication/Authorization	Access control, identity, permissions
Sensitive data	Information requiring protection (credentials, personal data)
External integrations	Communication with systems outside the trust boundary
Exposed endpoints	Interfaces accessible by users or external systems
Data persistence	Storage of information that crosses boundaries

Execution Flow

1. Read design artifacts:

   • plan.md - Stack and architecture
   • docs/architecture/decisions/*.md - ADRs
   • spec.md - Requirements and user stories

2. Identify attack surface:

   ## Attack Surface
   
   | Component | Exposure | Data | Initial Risk |
   |-----------|----------|------|--------------|
   | [endpoint] | [public/internal] | [data type] | [low/medium/high] |
   

3. Map trust boundaries:

   • Where does data cross trust boundaries?
   • Which components are external vs internal?
   • Where is authentication/authorization applied?

4. Apply STRIDE (simplified):

   Threat	Question	Typical Control
   Spoofing	Can someone impersonate another?	Strong authentication
   Tampering	Can data be altered?	Integrity, signatures
   Repudiation	Can actions be denied?	Logging, audit trail
   Info Disclosure	Can data leak?	Encryption, ACLs
   Denial of Service	Can the system be taken down?	Rate limiting, quotas
   Elevation	Can privileges be escalated?	Least privilege, RBAC

5. Evaluate ADRs:

   • Do technology decisions have security implications?
   • Are there known vulnerabilities in the chosen technologies?
   • Are default configurations secure?
   • For Microsoft/Azure technologies: Use microsoft_docs_search to check security best practices and known service vulnerabilities
   • Use microsoft_docs_fetch to get the complete security hardening guide when a relevant gap is identified

6. Validate Azure compliance:

   • Use the azure/policy tool to verify whether the proposed infrastructure complies with the organization's policies

---

Code Mode (Implementation Security)

Execution Flow

1. Identify scope:

   • If called from implement: review modified files
   • If called from review: review files in review scope
   • If explicit mention: review specified files/PR

2. Read relevant files:

   • Modified source code
   • Security tests (if they exist)
   • Configurations (env, secrets, configs)

3. Check vulnerability categories:

   Category	What to check
   Access Control	Authorization, privilege escalation, unauthorized access
   Data Protection	Exposed sensitive data, inadequate encryption
   Injection	Unsanitized input used in commands or queries
   Insecure Design	Missing validation, violated trust boundaries
   Configuration	Insecure defaults, debug in production
   Vulnerable Components	Dependencies with known vulnerabilities
   Authentication	Weak identity and session controls
   Integrity	Data or code can be manipulated
   Logging	Insufficient auditing or sensitive data in logs
   External Requests	URLs or resources controlled by external input

4. Code checks:

   Detect the project stack and apply relevant checks for:

   • Dynamic code execution
   • Command or data injection
   • Deserialization of untrusted data
   • File path manipulation
   • Cross-site scripting
   • Race conditions
   • Denial of service

5. Check secrets:

   • Search for hardcoded credentials in the code
   • Verify that environment files are in .gitignore
   • Verify that secrets are not exposed in configuration
   • Query for active alerts: If there are open alerts, include them as Critical findings.

---

Severity

Level	Criteria	Action
Critical	Trivial exploitation, maximum impact (RCE, massive data breach)	Blocks. Fix immediately.
High	Exploitation possible, significant impact (auth bypass, injection)	Blocks. Fix before merge.
Medium	Exploitation requires conditions, moderate impact	Non-blocking. Fix soon.
Low	Difficult exploitation, limited impact	Non-blocking. Backlog.
Info	Best practices, hardening	Informational.

Recognized Best Practices

Acknowledge when the code follows best practices:

Best practices identified:
- Parameterized queries used consistently
- Input validation with defined schema
- Secrets loaded from environment variables
- Rate limiting implemented on public endpoints

Common Rationalizations

Rationalization	Reality
"This is an internal tool, security does not matter"	Internal tools get compromised. Attackers target the weakest link in the chain.
"We will add security later"	Retrofitting security is 10x harder than building it in. Add controls now.
"The framework handles security"	Frameworks provide tools, not guarantees. You still need to use them correctly.
"No one would try to exploit this"	Automated scanners will find it. Security by obscurity is not security.
"It is just a prototype"	Prototypes become production. Security habits from day one prevent emergency retrofits.

Red Flags

• User input passed directly to database queries, shell commands, or HTML rendering
• Secrets in source code or commit history
• API endpoints without authentication or authorization checks
• Missing CORS configuration or wildcard origins
• No rate limiting on authentication endpoints
• Stack traces or internal error details exposed to users
• Dependencies with known critical vulnerabilities not addressed

Constraints

• Does NOT implement code: Provides guidance and remediation
• Does NOT create tasks: Documents findings for the developer to resolve
• Does NOT edit code: Only reviews and reports
• Balances security with usability: Risk-based approach
• Objective: Documents vulnerabilities AND best practices