Security Review Skill

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

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:

SFI Six Pillars

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

Threat Modeling (STRIDE)

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

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

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

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.

Synapses

See synapses.json for connections.

Consolidated: 2026-02-19 Sources: security-review (2026-02-01) + microsoft-sfi