security-assessment

Security Assessment

A specialized skill for systematic security evaluation of code, architecture, and infrastructure. Combines threat modeling methodologies with practical code review techniques to identify and remediate security vulnerabilities.

When to Use

Reviewing code changes for security vulnerabilities
Designing new features with security requirements
Performing threat analysis on system architecture
Validating security controls in infrastructure
Assessing third-party integrations and dependencies
Preparing for security audits or compliance reviews

Threat Modeling with STRIDE

STRIDE is a threat modeling framework that categorizes threats by their nature. Apply this model during architecture review and feature design.

Spoofing (Authentication)

Threat: Attacker pretends to be another user or system.

Questions to ask:

How do we verify the identity of users and systems?
Can authentication tokens be stolen or forged?
Are there any authentication bypass paths?

Mitigations:

Strong authentication mechanisms (MFA)
Secure token generation and validation
Session management with proper invalidation

Tampering (Integrity)

Threat: Attacker modifies data in transit or at rest.

Questions to ask:

Can data be modified between components?
Are database records protected from unauthorized changes?
Can configuration files be altered?

Mitigations:

Input validation at all boundaries
Cryptographic signatures for critical data
Database integrity constraints and audit logs

Repudiation (Non-repudiation)

Threat: Attacker denies performing an action.

Questions to ask:

Can we prove who performed an action?
Are audit logs tamper-resistant?
Is there sufficient logging for forensics?

Mitigations:

Comprehensive audit logging
Secure, immutable log storage
Digital signatures for critical operations

Information Disclosure (Confidentiality)

Threat: Attacker gains access to sensitive information.

Questions to ask:

What sensitive data exists in this system?
How is data protected at rest and in transit?
Are error messages revealing internal details?

Mitigations:

Encryption for sensitive data (TLS, AES)
Proper access controls and authorization
Sanitized error messages

Denial of Service (Availability)

Threat: Attacker makes the system unavailable.

Questions to ask:

What resources can be exhausted?
Are there rate limits on expensive operations?
How does the system handle malformed input?

Mitigations:

Rate limiting and throttling
Input validation and size limits
Resource quotas and timeouts

Elevation of Privilege (Authorization)

Threat: Attacker gains higher privileges than intended.

Questions to ask:

Can users access resources beyond their role?
Are privilege checks performed consistently?
Can administrative functions be accessed by regular users?

Mitigations:

Principle of least privilege
Role-based access control (RBAC)
Authorization checks at every layer

OWASP Top 10 Review Patterns

Systematic patterns for identifying the most critical web application security risks.

A01: Broken Access Control

Review pattern:

Identify all endpoints and their expected access levels
Trace authorization logic from request to resource
Test for horizontal privilege escalation (accessing other users' data)
Test for vertical privilege escalation (accessing admin functions)
Verify CORS configuration restricts origins appropriately

Red flags:

Authorization based on client-side state
Direct object references without ownership verification
Missing authorization checks on API endpoints

A02: Cryptographic Failures

Review pattern:

Map all sensitive data flows (credentials, PII, financial)
Verify encryption at rest and in transit
Check for hardcoded secrets in code or configuration
Review cryptographic algorithm choices
Verify key management practices

Red flags:

Sensitive data in logs or error messages
Deprecated algorithms (MD5, SHA1, DES)
Secrets in source control

A03: Injection

Review pattern:

Identify all user input entry points
Trace input flow to database queries, OS commands, LDAP
Verify parameterized queries or proper escaping
Check for dynamic code execution (eval, exec)
Review XML parsing for XXE vulnerabilities

Red flags:

String concatenation in queries
User input in system commands
Disabled XML external entity protection

A04: Insecure Design

Review pattern:

Verify threat modeling was performed
Check for abuse case handling (rate limits, quantity limits)
Review business logic for security assumptions
Assess multi-tenancy isolation
Verify secure defaults

Red flags:

No rate limiting on authentication
Trust assumptions without verification
Security as an afterthought

A05: Security Misconfiguration

Review pattern:

Review default configurations for security settings
Check for unnecessary features or services
Verify error handling does not expose details
Review security headers (CSP, HSTS, X-Frame-Options)
Check cloud resource permissions

Red flags:

Debug mode in production
Default credentials unchanged
Overly permissive cloud IAM policies

A06: Vulnerable Components

Review pattern:

Inventory all dependencies and their versions
Check for known vulnerabilities (CVE databases)
Verify dependencies from trusted sources
Review for unused dependencies
Check for version pinning

Red flags:

Unpinned dependencies
Known critical vulnerabilities
Dependencies from unofficial sources

A07: Authentication Failures

Review pattern:

Review password policy enforcement
Check session management implementation
Verify brute force protection
Review token generation and validation
Check credential storage mechanisms

Red flags:

Weak password requirements
Sessions that do not invalidate on logout
Predictable session tokens

A08: Integrity Failures

Review pattern:

Review CI/CD pipeline security
Check for unsigned code or dependencies
Review deserialization of untrusted data
Verify update mechanism security
Check for code review requirements

Red flags:

Deserialization without integrity checks
Unsigned updates or dependencies
No code review before deployment

A09: Logging and Monitoring Failures

Review pattern:

Verify authentication events are logged
Check for authorization failure logging
Review log content for sensitive data
Verify log integrity protection
Check alerting configuration

Red flags:

Missing authentication failure logs
Sensitive data in logs
No alerting on suspicious patterns

A10: SSRF

Review pattern:

Identify all server-side URL fetching
Verify URL validation against allowlist
Check for internal network blocking
Review URL scheme restrictions
Verify response handling

Red flags:

User-controlled URLs without validation
Internal addresses not blocked
Raw responses returned to users

Secure Coding Practices

Input Validation

Always validate on the server side, regardless of client validation:

function validateInput(input) { // Type validation if (typeof input !== 'string') { throw new ValidationError('Input must be a string'); }

// Length validation if (input.length > MAX_LENGTH) { throw new ValidationError('Input exceeds maximum length'); }

// Format validation (allowlist approach) if (!ALLOWED_PATTERN.test(input)) { throw new ValidationError('Input contains invalid characters'); }

return sanitize(input); }

Output Encoding

Context-appropriate encoding prevents injection:

HTML context: Encode < , > , & , " , '
JavaScript context: Use JSON.stringify or hex encoding
URL context: Use encodeURIComponent
SQL context: Use parameterized queries (never encode manually)

Secrets Management

Never commit secrets to source control:

// Bad: Hardcoded secret const apiKey = "sk-1234567890abcdef";

// Good: Environment variable const apiKey = process.env.API_KEY; if (!apiKey) { throw new ConfigurationError('API_KEY not configured'); }

Error Handling for Security

Separate internal logging from user-facing errors:

try { await processRequest(data); } catch (error) { // Log full details internally logger.error('Request processing failed', { error: error.message, stack: error.stack, userId: user.id, requestId: request.id });

// Return generic message to user throw new UserError('Unable to process request'); }

Infrastructure Security Considerations

Network Security

Segment networks to limit blast radius
Use private subnets for internal services
Implement network policies in Kubernetes
Restrict egress traffic to known destinations

Container Security

Use minimal base images (distroless, Alpine)
Run as non-root user
Set read-only root filesystem where possible
Scan images for vulnerabilities
Limit container capabilities

Secrets in Infrastructure

Use secret management services (Vault, AWS Secrets Manager)
Inject secrets as environment variables, not files
Rotate secrets regularly
Audit secret access

Cloud IAM

Apply principle of least privilege
Use service accounts with minimal permissions
Audit IAM policies regularly
Avoid using root/admin accounts for routine operations

Code Review Security Focus Areas

Priority areas for security-focused code review:

Authentication and session management - Token generation, validation, session lifecycle
Authorization checks - Access control at all layers
Input handling - All user input paths
Data exposure - Logs, errors, API responses
Cryptography usage - Algorithm selection, key management
Third-party integrations - Data sharing, authentication
Error handling - Information leakage, fail-secure behavior

Best Practices

Perform threat modeling before implementation
Apply defense in depth (multiple security layers)
Assume breach: design for detection and containment
Automate security testing in CI/CD
Keep dependencies updated and audited
Document security decisions and accepted risks
Train developers on secure coding practices

References

checklists/security-review-checklist.md
Comprehensive security review checklist

security-assessment

Safety Notice

Copy this and send it to your AI assistant to learn

Source Transparency

Related Skills

specify-requirements

requirements-analysis

review