security-review

name	security-review
description	Defend before attackers find the gaps - OWASP, STRIDE, and Microsoft SFI
tier	core
applyTo	**/*security*,**/*auth*,**/*password*,**/*token*,**/*credential*,**/*vulnerability*,**/*CVE*,**/*secret*

Security Review Skill

Defend before attackers find the gaps.

⚠️ Staleness Warning

Security practices evolve with new threats, vulnerabilities, and industry standards.

Refresh triggers:

• New CVEs affecting our stack
• Microsoft SFI updates
• Major security incidents (industry-wide)
• Dependency security advisories
• Compliance requirement changes

Last validated: February 2026

Check current state: Microsoft SFI, OWASP, CVE Database

---

Core Principle

Security is not a feature—it's a property. Review code with adversarial thinking.

---

Microsoft Secure Future Initiative (SFI)

Microsoft's approach to security-first development:

SFI Core Principles

Principle	Focus
Secure by Design	Security comes first when designing any product or service
Secure by Default	Protections enabled/enforced by default, require no extra effort, not optional
Secure Operations	Security controls and monitoring continuously improved for current/future threats

Satya's Mandate (May 2024): "If you're faced with the tradeoff between security and another priority, your answer is clear: Do security."

SFI Foundations

Four foundations that underpin successful security operations:

Foundation	Description
Security-first Culture	Daily behaviors reinforced through regular meetings between engineering and SFI leaders
Security Governance	Framework led by CISO, partnering with engineering teams to oversee SFI and manage risks
Continuous Improvement	Growth mindset integrating feedback and learnings from incidents into standards
Paved Paths & Standards	Best practices that optimize productivity, compliance, and security at scale

SFI Six Pillars

Pillar	Focus
Protect Identities & Secrets	Best-in-class standards for identity/secrets infrastructure, phishing-resistant MFA
Protect Tenants & Isolate Systems	Tenant isolation and production system protection
Protect Networks	Network security and segmentation
Protect Engineering Systems	Secure development infrastructure and CI/CD
Monitor & Detect Cyberthreats	Continuous threat monitoring and detection
Accelerate Response & Remediation	Fast incident response and recovery

Secure by Design Checklist

Before coding:

• Authentication method defined
• Authorization model designed
• Data classification done
• Encryption requirements clear
• Logging requirements defined
• Third-party dependencies reviewed

Secure by Default Patterns

// Bad: Optional security
createServer({ https: false, cors: '*' });

// Good: Secure by default
createServer({
    https: true,
    cors: ['https://trusted.com'],
    helmet: true
});

Principle of Least Privilege:

// Bad: Admin access by default
const user = { role: 'admin', permissions: ['*'] };

// Good: Minimum permissions
const user = { role: 'viewer', permissions: ['read:own'] };

Input Validation:

// Validate and sanitize ALL input
function processInput(input: unknown) {
    const validated = schema.parse(input); // Zod, Joi, etc.
    const sanitized = sanitize(validated);
    return sanitized;
}

---

OWASP Top 10

#	Vulnerability	What to Check	Prevention
1	Broken Access Control	Check permissions on every request	Authorization on all routes
2	Cryptographic Failures	Use strong, modern crypto	TLS 1.2+, proper key management
3	Injection	SQL, NoSQL, LDAP, OS commands	Parameterized queries, no string concat
4	Insecure Design	Threat modeling, secure patterns	STRIDE analysis pre-implementation
5	Security Misconfiguration	Secure defaults, remove unused features	Hardened configs, no default passwords
6	Vulnerable Components	Dependency scanning, updates	npm audit, regular updates
7	Auth Failures	MFA, secure session management	Strong passwords, session timeout
8	Data Integrity	Signatures, checksums	Tamper detection
9	Logging Failures	Comprehensive audit logging	Monitor security events
10	SSRF	Allowlist URLs, validate requests	Input validation, URL allowlisting

---

Threat Modeling (STRIDE)

Threat	Question	Mitigation
Spoofing	Can attacker impersonate?	Strong authentication, phishing-resistant MFA
Tampering	Can data be modified?	Integrity checks, signatures, checksums
Repudiation	Can actions be denied?	Audit logging, non-repudiation mechanisms
Information Disclosure	Can secrets leak?	Encryption at rest/transit, access control
Denial of Service	Can system be overwhelmed?	Rate limiting, quotas, redundancy
Elevation of Privilege	Can attacker gain access?	Least privilege, authorization checks

---

Code Review Security Lens

Authentication

□ Passwords hashed with bcrypt/argon2 (not MD5/SHA1)
□ No hardcoded credentials
□ Session tokens are random, rotated, and expire
□ Failed login attempts are rate-limited
□ MFA supported where appropriate

Authorization

□ Every endpoint has explicit access control
□ No security through obscurity (hidden URLs)
□ Resource ownership verified before access
□ Admin functions require elevated auth
□ Deny by default, allow explicitly

Input Validation

□ All input validated on server (not just client)
□ Allowlist validation preferred over blocklist
□ File uploads restricted by type and size
□ URL redirects validated against allowlist
□ JSON/XML parsing has size limits

Data Protection

□ Sensitive data encrypted at rest
□ TLS 1.2+ for data in transit
□ API keys/secrets in env vars, not code
□ PII minimized and retention limited
□ Logs don't contain passwords/tokens/PII

Dependencies

□ npm audit / pip audit / cargo audit clean
□ No deprecated or unmaintained packages
□ Dependabot or Renovate enabled
□ Lock files committed
□ Known CVE check before release

---

Credential Management

Never Hardcode

// NEVER
const apiKey = 'sk-1234567890abcdef';

// ALWAYS
const apiKey = process.env.API_KEY;
// Or: Azure Key Vault, AWS Secrets Manager, etc.

Rotation Policy

Credential Type	Rotation Period
API Keys	90 days
Service Passwords	90 days
Certificates	1 year
User Passwords	User discretion + breach response

Secrets in Git

If secrets accidentally committed:

1. Revoke immediately — The secret is compromised
2. Remove from history — git filter-branch or BFG
3. Rotate — Generate new credentials
4. Audit — Check for unauthorized use

---

Dependency Security

Regular Audits

# npm
npm audit
npm audit fix

# Check for outdated
npm outdated

Automated Scanning

• Dependabot (GitHub)
• Snyk
• npm audit in CI/CD

Update Strategy

Severity	Response Time
Critical	24-48 hours
High	1 week
Medium	2 weeks
Low	Next release

---

Security Code Review Checklist

Pre-Merge Gate

• No hardcoded secrets
• Input validation present
• Output encoding for XSS
• SQL uses parameterized queries
• Auth checks on all endpoints
• Sensitive data encrypted
• Errors don't leak info
• Dependencies up to date

Red Flags

🚩 eval(), exec(), dangerouslySetInnerHTML
🚩 String concatenation in queries
🚩 Disabled security features
🚩 Overly permissive CORS
🚩 Secrets in code or config files
🚩 Missing rate limiting
🚩 Verbose error messages

---

Common Vulnerabilities by Language

Language	Watch For
JavaScript	Prototype pollution, eval(), innerHTML
TypeScript	Type assertions bypassing validation
Python	pickle deserialization, format strings
SQL	String concatenation in queries
Shell	Command injection, unquoted variables

---

Security Headers Checklist

Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 0 (deprecated, use CSP)

---

Quick Security Questions

Before shipping, ask:

1. What's the worst thing an attacker could do?
2. What data could leak if this endpoint is exposed?
3. Who should NOT have access to this?
4. What happens if input is malicious?
5. Are we trusting anything we shouldn't?

---

Incident Response Connection

When vulnerability found:

1. Assess: What's the blast radius?
2. Contain: Can we disable the feature?
3. Fix: Patch the vulnerability
4. Verify: Confirm fix works
5. Learn: Update review checklist

See incident-response for full IR workflow.

---