engineering-security-engineer

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: engineering-security-engineer
description: "Secure applications, infrastructure, and pipelines through threat modeling, vulnerability assessment, and security architecture. Use when you need OWASP Top 10 remediation, threat modeling (STRIDE/DREAD), penetration testing methodology, secrets management, dependency vulnerability scanning, authentication/authorization architecture, CSP and security headers, API security, supply chain security, compliance frameworks (SOC 2, GDPR, HIPAA), incident response, or security-focused code review."
metadata:
  version: "1.1.1"
---

# Security Engineering Guide

## Overview
This guide covers application security, infrastructure hardening, threat modeling, vulnerability management, and security operations. Use it when designing auth systems, reviewing code for security issues, setting up security scanning in CI/CD, responding to incidents, managing secrets, or ensuring compliance with security frameworks.

## First 10 Minutes

- Map the attack surface before suggesting fixes: public routes, auth entrypoints, admin paths, file upload/download flows, third-party callbacks, and secrets-loading paths.
- Run the bundled scripts from the skill directory first, not the repo under review: `engineering-security-engineer/scripts/scan_secrets.sh` and `engineering-security-engineer/scripts/audit_auth_surface.py`.
- For large mobile/web repos, start with high-signal trees such as `src`, `app`, `server`, `api`, `config`, and `scripts`; only scan the full repo if needed.
- Use `scripts/scan_secrets.sh` first. Secret exposure changes priority immediately.
- Use `scripts/audit_auth_surface.py` next to inventory auth-related files and session/token patterns before reviewing login or authorization changes.
- Identify the highest-risk trust boundary in the task: browser to API, API to service, service to database, or CI to cloud.

## Refuse or Escalate

- Refuse to approve security-sensitive changes that skip authorization checks, input validation, or audit logging "for later."
- Escalate immediately when the task involves credential exposure, insecure direct object access in production, or suspected compromise.
- Do not recommend weakening CSP, CORS, or cookie settings without documenting the exact breakage and the narrowest safe exception.
- Escalate if the requested solution conflicts with legal or compliance obligations already named in the system.

## Threat Modeling

### When to Threat Model
- Before building any new feature that handles user data, authentication, authorization, payments, or file uploads.
- When adding a new external dependency, third-party integration, or API endpoint.
- When changing data flow (new database, new cache, new queue) or access patterns.
- Quarterly review of existing threat models for systems handling PII, financial data, or health data.

### STRIDE Framework
For every component in the system, evaluate:
- **Spoofing**: Can an attacker impersonate a legitimate user or service? Mitigation: strong authentication (MFA, mutual TLS, API keys with rotation).
- **Tampering**: Can data be modified in transit or at rest? Mitigation: TLS 1.2+ for transit, AES-256/KMS for rest, HMAC signatures for integrity verification.
- **Repudiation**: Can a user deny performing an action? Mitigation: immutable audit logs with timestamp, user ID, action, and IP. Ship to a separate log store that the application cannot modify.
- **Information Disclosure**: Can sensitive data leak through logs, error messages, API responses, or side channels? Mitigation: scrub PII from logs, return generic error messages to clients, use constant-time comparison for secrets.
- **Denial of Service**: Can the system be overwhelmed? Mitigation: rate limiting, request size limits, timeout enforcement, auto-scaling with cost caps.
- **Elevation of Privilege**: Can a user gain unauthorized access? Mitigation: RBAC/ABAC at every layer, principle of least privilege, input validation on all trust boundaries.

### DREAD