Internal Safety Override
- Status: disabled by default.
- Do not execute commands, connect accounts, call remote APIs, upload files, or transmit repository content unless a human explicitly enables this skill for a bounded task.
- Never read
.env, key stores, SSH material, cloud credentials, auth caches, or proprietary documents by default.
- Audit categories: command, network, secrets.
Senior Security Engineer
Security engineering tools for threat modeling, vulnerability analysis, secure architecture design, and penetration testing.
Table of Contents
Threat Modeling Workflow
Identify and analyze security threats using STRIDE methodology.
Workflow: Conduct Threat Model
- Define system scope and boundaries:
- Identify assets to protect
- Map trust boundaries
- Document data flows
- Create data flow diagram:
- External entities (users, services)
- Processes (application components)
- Data stores (databases, caches)
- Data flows (APIs, network connections)
- Apply STRIDE to each DFD element (see STRIDE per Element Matrix below)
- Score risks using DREAD:
- Damage potential (1-10)
- Reproducibility (1-10)
- Exploitability (1-10)
- Affected users (1-10)
- Discoverability (1-10)
- Prioritize threats by risk score
- Define mitigations for each threat
- Document in threat model report
- Validation: All DFD elements analyzed; STRIDE applied; threats scored; mitigations mapped
STRIDE Threat Categories
| Category |
Security Property |
Mitigation Focus |
| Spoofing |
Authentication |
MFA, certificates, strong auth |
| Tampering |
Integrity |
Signing, checksums, validation |
| Repudiation |
Non-repudiation |
Audit logs, digital signatures |
| Information Disclosure |
Confidentiality |
Encryption, access controls |
| Denial of Service |
Availability |
Rate limiting, redundancy |
| Elevation of Privilege |
Authorization |
RBAC, least privilege |
STRIDE per Element Matrix
| DFD Element |
S |
T |
R |
I |
D |
E |
| External Entity |
X |
|
X |
|
|
|
| Process |
X |
X |
X |
X |
X |
X |
| Data Store |
|
X |
X |
X |
X |
|
| Data Flow |
|
X |
|
X |
X |
|
See: references/threat-modeling-guide.md
Security Architecture Workflow
Design secure systems using defense-in-depth principles.
Workflow: Design Secure Architecture
- Define security requirements:
- Compliance requirements (GDPR, HIPAA, PCI-DSS)
- Data classification (public, internal, confidential, restricted)
- Threat model inputs
- Apply defense-in-depth layers:
- Perimeter: WAF, DDoS protection, rate limiting
- Network: Segmentation, IDS/IPS, mTLS
- Host: Patching, EDR, hardening
- Application: Input validation, authentication, secure coding
- Data: Encryption at rest and in transit
- Implement Zero Trust principles:
- Verify explicitly (every request)
- Least privilege access (JIT/JEA)
- Assume breach (segment, monitor)
- Configure authentication and authorization:
- Identity provider selection
- MFA requirements
- RBAC/ABAC model
- Design encryption strategy:
- Key management approach
- Algorithm selection
- Certificate lifecycle
- Plan security monitoring:
- Log aggregation
- SIEM integration
- Alerting rules
- Document architecture decisions
- Validation: Defense-in-depth layers defined; Zero Trust applied; encryption strategy documented; monitoring planned
Defense-in-Depth Layers
Layer 1: PERIMETER
WAF, DDoS mitigation, DNS filtering, rate limiting
Layer 2: NETWORK
Segmentation, IDS/IPS, network monitoring, VPN, mTLS
Layer 3: HOST
Endpoint protection, OS hardening, patching, logging
Layer 4: APPLICATION
Input validation, authentication, secure coding, SAST
Layer 5: DATA
Encryption at rest/transit, access controls, DLP, backup
Authentication Pattern Selection
| Use Case |
Recommended Pattern |
| Web application |
OAuth 2.0 + PKCE with OIDC |
| API authentication |
JWT with short expiration + refresh tokens |
| Service-to-service |
mTLS with certificate rotation |
| CLI/Automation |
API keys with IP allowlisting |
| High security |
FIDO2/WebAuthn hardware keys |
See: references/security-architecture-patterns.md
Vulnerability Assessment Workflow
Identify and remediate security vulnerabilities in applications.
Workflow: Conduct Vulnerability Assessment
- Define assessment scope:
- In-scope systems and applications
- Testing methodology (black box, gray box, white box)
- Rules of engagement
- Gather information:
- Technology stack inventory
- Architecture documentation
- Previous vulnerability reports
- Perform automated scanning:
- SAST (static analysis)
- DAST (dynamic analysis)
- Dependency scanning
- Secret detection
- Conduct manual testing:
- Business logic flaws
- Authentication bypass
- Authorization issues
- Injection vulnerabilities
- Classify findings by severity:
- Critical: Immediate exploitation risk
- High: Significant impact, easier to exploit
- Medium: Moderate impact or difficulty
- Low: Minor impact
- Develop remediation plan:
- Prioritize by risk
- Assign owners
- Set deadlines
- Verify fixes and document
- Validation: Scope defined; automated and manual testing complete; findings classified; remediation tracked
For OWASP Top 10 vulnerability descriptions and testing guidance, refer to owasp.org/Top10.
Vulnerability Severity Matrix
| Impact \ Exploitability |
Easy |
Moderate |
Difficult |
| Critical |
Critical |
Critical |
High |
| High |
Critical |
High |
Medium |
| Medium |
High |
Medium |
Low |
| Low |
Medium |
Low |
Low |
Secure Code Review Workflow
Review code for security vulnerabilities before deployment.
Workflow: Conduct Security Code Review
- Establish review scope:
- Changed files and functions
- Security-sensitive areas (auth, crypto, input handling)
- Third-party integrations
- Run automated analysis:
- SAST tools (Semgrep, CodeQL, Bandit)
- Secret scanning
- Dependency vulnerability check
- Review authentication code:
- Password handling (hashing, storage)
- Session management
- Token validation
- Review authorization code:
- Access control checks
- RBAC implementation
- Privilege boundaries
- Review data handling:
- Input validation
- Output encoding
- SQL query construction
- File path handling
- Review cryptographic code:
- Algorithm selection
- Key management
- Random number generation
- Document findings with severity
- Validation: Automated scans passed; auth/authz reviewed; data handling checked; crypto verified; findings documented
Security Code Review Checklist
| Category |
Check |
Risk |
| Input Validation |
All user input validated and sanitized |
Injection |
| Output Encoding |
Context-appropriate encoding applied |
XSS |
| Authentication |
Passwords hashed with Argon2/bcrypt |
Credential theft |
| Session |
Secure cookie flags set (HttpOnly, Secure, SameSite) |
Session hijacking |
| Authorization |
Server-side permission checks on all endpoints |
Privilege escalation |
| SQL |
Parameterized queries used exclusively |
SQL injection |
| File Access |
Path traversal sequences rejected |
Path traversal |
| Secrets |
No hardcoded credentials or keys |
Information disclosure |
| Dependencies |
Known vulnerable packages updated |
Supply chain |
| Logging |
Sensitive data not logged |
Information disclosure |
Secure vs Insecure Patterns
| Pattern |
Issue |
Secure Alternative |
| SQL string formatting |
SQL injection |
Use parameterized queries with placeholders |
| Shell command building |
Command injection |
Use subprocess with argument lists, no shell |
| Path concatenation |
Path traversal |
Validate and canonicalize paths |
| MD5/SHA1 for passwords |
Weak hashing |
Use Argon2id or bcrypt |
| Math.random for tokens |
Predictable values |
Use crypto.getRandomValues |
Inline Code Examples
SQL Injection — insecure vs. secure (Python):
# ❌ Insecure: string formatting allows SQL injection
query = f"SELECT * FROM users WHERE username = '{username}'"
cursor.execute(query)
# ✅ Secure: parameterized query — user input never interpreted as SQL
query = "SELECT * FROM users WHERE username = %s"
cursor.execute(query, (username,))
Password Hashing with Argon2id (Python):
from argon2 import PasswordHasher
ph = PasswordHasher() # uses secure defaults (time_cost, memory_cost)
# On registration
hashed = ph.hash(plain_password)
# On login — raises argon2.exceptions.VerifyMismatchError on failure
ph.verify(hashed, plain_password)
Secret Scanning — core pattern matching (Python):
import re, pathlib
SECRET_PATTERNS = {
"aws_access_key": re.compile(r"AKIA[0-9A-Z]{16}"),
"github_token": re.compile(r"ghp_[A-Za-z0-9]{36}"),
"private_key": re.compile(r"-----BEGIN (RSA |EC )?PRIVATE KEY-----"),
"generic_secret": re.compile(r'(?i)(password|secret|api_key)\s*=\s*["']?\S{8,}'),
}
def scan_file(path: pathlib.Path) -> list[dict]:
findings = []
for lineno, line in enumerate(path.read_text(errors="replace").splitlines(), 1):
for name, pattern in SECRET_PATTERNS.items():
if pattern.search(line):
findings.append({"file": str(path), "line": lineno, "type": name})
return findings
Incident Response Workflow
Respond to and contain security incidents.
Workflow: Handle Security Incident
- Identify and triage:
- Validate incident is genuine
- Assess initial scope and severity
- Activate incident response team
- Contain the threat:
- Isolate affected systems
- Block malicious IPs/accounts
- Disable compromised credentials
- Eradicate root cause:
- Remove malware/backdoors
- Patch vulnerabilities
- Update configurations
- Recover operations:
- Restore from clean backups
- Verify system integrity
- Monitor for recurrence
- Conduct post-mortem:
- Timeline reconstruction
- Root cause analysis
- Lessons learned
- Implement improvements:
- Update detection rules
- Enhance controls
- Update runbooks
- Document and report
- Validation: Threat contained; root cause eliminated; systems recovered; post-mortem complete; improvements implemented
Incident Severity Levels
| Level |
Response Time |
Escalation |
| P1 - Critical (active breach/exfiltration) |
Immediate |
CISO, Legal, Executive |
| P2 - High (confirmed, contained) |
1 hour |
Security Lead, IT Director |
| P3 - Medium (potential, under investigation) |
4 hours |
Security Team |
| P4 - Low (suspicious, low impact) |
24 hours |
On-call engineer |
Incident Response Checklist
| Phase |
Actions |
| Identification |
Validate alert, assess scope, determine severity |
| Containment |
Isolate systems, preserve evidence, block access |
| Eradication |
Remove threat, patch vulnerabilities, reset credentials |
| Recovery |
Restore services, verify integrity, increase monitoring |
| Lessons Learned |
Document timeline, identify gaps, update procedures |
Security Tools Reference
Recommended Security Tools
| Category |
Tools |
| SAST |
Semgrep, CodeQL, Bandit (Python), ESLint security plugins |
| DAST |
OWASP ZAP, Burp Suite, Nikto |
| Dependency Scanning |
Snyk, Dependabot, npm audit, pip-audit |
| Secret Detection |
GitLeaks, TruffleHog, detect-secrets |
| Container Security |
Trivy, Clair, Anchore |
| Infrastructure |
Checkov, tfsec, ScoutSuite |
| Network |
Wireshark, Nmap, Masscan |
| Penetration |
Metasploit, sqlmap, Burp Suite Pro |
Cryptographic Algorithm Selection
| Use Case |
Algorithm |
Key Size |
| Symmetric encryption |
AES-256-GCM |
256 bits |
| Password hashing |
Argon2id |
N/A (use defaults) |
| Message authentication |
HMAC-SHA256 |
256 bits |
| Digital signatures |
Ed25519 |
256 bits |
| Key exchange |
X25519 |
256 bits |
| TLS |
TLS 1.3 |
N/A |
See: references/cryptography-implementation.md
Tools and References
Scripts
| Script |
Purpose |
| threat_modeler.py |
STRIDE threat analysis with DREAD risk scoring; JSON and text output; interactive guided mode |
| secret_scanner.py |
Detect hardcoded secrets and credentials across 20+ patterns; CI/CD integration ready |
For usage, see the inline code examples in Secure Code Review Workflow and the script source files directly.
References
| Document |
Content |
| security-architecture-patterns.md |
Zero Trust, defense-in-depth, authentication patterns, API security |
| threat-modeling-guide.md |
STRIDE methodology, attack trees, DREAD scoring, DFD creation |
| cryptography-implementation.md |
AES-GCM, RSA, Ed25519, password hashing, key management |
Security Standards Reference
Security Headers Checklist
| Header |
Recommended Value |
| Content-Security-Policy |
default-src self; script-src self |
| X-Frame-Options |
DENY |
| X-Content-Type-Options |
nosniff |
| Strict-Transport-Security |
max-age=31536000; includeSubDomains |
| Referrer-Policy |
strict-origin-when-cross-origin |
| Permissions-Policy |
geolocation=(), microphone=(), camera=() |
For compliance framework requirements (OWASP ASVS, CIS Benchmarks, NIST CSF, PCI-DSS, HIPAA, SOC 2), refer to the respective official documentation.
Related Skills
1---2name: senior-security3description: Security engineering toolkit for threat modeling, vulnerability analysis, secure architecture, and penetration testing. Includes STRIDE analysis, OWASP guidance, cryptography patterns, and security scanning tools. Use when the user asks about security reviews, threat analysis, vulnerability assessments, secure coding practices, security audits, attack surface analysis, CVE remediation, or security best practices.4---56## Internal Safety Override78- Status: disabled by default.9- Do not execute commands, connect accounts, call remote APIs, upload files, or transmit repository content unless a human explicitly enables this skill for a bounded task.10- Never read `.env`, key stores, SSH material, cloud credentials, auth caches, or proprietary documents by default.11- Audit categories: command, network, secrets.1213# Senior Security Engineer1415Security engineering tools for threat modeling, vulnerability analysis, secure architecture design, and penetration testing.1617---1819## Table of Contents2021- [Threat Modeling Workflow](#threat-modeling-workflow)22- [Security Architecture Workflow](#security-architecture-workflow)23- [Vulnerability Assessment Workflow](#vulnerability-assessment-workflow)24- [Secure Code Review Workflow](#secure-code-review-workflow)25- [Incident Response Workflow](#incident-response-workflow)26- [Security Tools Reference](#security-tools-reference)27- [Tools and References](#tools-and-references)2829---3031## Threat Modeling Workflow3233Identify and analyze security threats using STRIDE methodology.3435### Workflow: Conduct Threat Model36371. Define system scope and boundaries:38 - Identify assets to protect39 - Map trust boundaries40 - Document data flows412. Create data flow diagram:42 - External entities (users, services)43 - Processes (application components)44 - Data stores (databases, caches)45 - Data flows (APIs, network connections)463. Apply STRIDE to each DFD element (see [STRIDE per Element Matrix](#stride-per-element-matrix) below)474. Score risks using DREAD:48 - Damage potential (1-10)49 - Reproducibility (1-10)50 - Exploitability (1-10)51 - Affected users (1-10)52 - Discoverability (1-10)535. Prioritize threats by risk score546. Define mitigations for each threat557. Document in threat model report568. **Validation:** All DFD elements analyzed; STRIDE applied; threats scored; mitigations mapped5758### STRIDE Threat Categories5960| Category | Security Property | Mitigation Focus |61|----------|-------------------|------------------|62| Spoofing | Authentication | MFA, certificates, strong auth |63| Tampering | Integrity | Signing, checksums, validation |64| Repudiation | Non-repudiation | Audit logs, digital signatures |65| Information Disclosure | Confidentiality | Encryption, access controls |66| Denial of Service | Availability | Rate limiting, redundancy |67| Elevation of Privilege | Authorization | RBAC, least privilege |6869### STRIDE per Element Matrix7071| DFD Element | S | T | R | I | D | E |72|-------------|---|---|---|---|---|---|73| External Entity | X | | X | | | |74| Process | X | X | X | X | X | X |75| Data Store | | X | X | X | X | |76| Data Flow | | X | | X | X | |7778See: [references/threat-modeling-guide.md](references/threat-modeling-guide.md)7980---8182## Security Architecture Workflow8384Design secure systems using defense-in-depth principles.8586### Workflow: Design Secure Architecture87881. Define security requirements:89 - Compliance requirements (GDPR, HIPAA, PCI-DSS)90 - Data classification (public, internal, confidential, restricted)91 - Threat model inputs922. Apply defense-in-depth layers:93 - Perimeter: WAF, DDoS protection, rate limiting94 - Network: Segmentation, IDS/IPS, mTLS95 - Host: Patching, EDR, hardening96 - Application: Input validation, authentication, secure coding97 - Data: Encryption at rest and in transit983. Implement Zero Trust principles:99 - Verify explicitly (every request)100 - Least privilege access (JIT/JEA)101 - Assume breach (segment, monitor)1024. Configure authentication and authorization:103 - Identity provider selection104 - MFA requirements105 - RBAC/ABAC model1065. Design encryption strategy:107 - Key management approach108 - Algorithm selection109 - Certificate lifecycle1106. Plan security monitoring:111 - Log aggregation112 - SIEM integration113 - Alerting rules1147. Document architecture decisions1158. **Validation:** Defense-in-depth layers defined; Zero Trust applied; encryption strategy documented; monitoring planned116117### Defense-in-Depth Layers118119```120Layer 1: PERIMETER121 WAF, DDoS mitigation, DNS filtering, rate limiting122123Layer 2: NETWORK124 Segmentation, IDS/IPS, network monitoring, VPN, mTLS125126Layer 3: HOST127 Endpoint protection, OS hardening, patching, logging128129Layer 4: APPLICATION130 Input validation, authentication, secure coding, SAST131132Layer 5: DATA133 Encryption at rest/transit, access controls, DLP, backup134```135136### Authentication Pattern Selection137138| Use Case | Recommended Pattern |139|----------|---------------------|140| Web application | OAuth 2.0 + PKCE with OIDC |141| API authentication | JWT with short expiration + refresh tokens |142| Service-to-service | mTLS with certificate rotation |143| CLI/Automation | API keys with IP allowlisting |144| High security | FIDO2/WebAuthn hardware keys |145146See: [references/security-architecture-patterns.md](references/security-architecture-patterns.md)147148---149150## Vulnerability Assessment Workflow151152Identify and remediate security vulnerabilities in applications.153154### Workflow: Conduct Vulnerability Assessment1551561. Define assessment scope:157 - In-scope systems and applications158 - Testing methodology (black box, gray box, white box)159 - Rules of engagement1602. Gather information:161 - Technology stack inventory162 - Architecture documentation163 - Previous vulnerability reports1643. Perform automated scanning:165 - SAST (static analysis)166 - DAST (dynamic analysis)167 - Dependency scanning168 - Secret detection1694. Conduct manual testing:170 - Business logic flaws171 - Authentication bypass172 - Authorization issues173 - Injection vulnerabilities1745. Classify findings by severity:175 - Critical: Immediate exploitation risk176 - High: Significant impact, easier to exploit177 - Medium: Moderate impact or difficulty178 - Low: Minor impact1796. Develop remediation plan:180 - Prioritize by risk181 - Assign owners182 - Set deadlines1837. Verify fixes and document1848. **Validation:** Scope defined; automated and manual testing complete; findings classified; remediation tracked185186For OWASP Top 10 vulnerability descriptions and testing guidance, refer to [owasp.org/Top10](https://owasp.org/Top10).187188### Vulnerability Severity Matrix189190| Impact \ Exploitability | Easy | Moderate | Difficult |191|-------------------------|------|----------|-----------|192| Critical | Critical | Critical | High |193| High | Critical | High | Medium |194| Medium | High | Medium | Low |195| Low | Medium | Low | Low |196197---198199## Secure Code Review Workflow200201Review code for security vulnerabilities before deployment.202203### Workflow: Conduct Security Code Review2042051. Establish review scope:206 - Changed files and functions207 - Security-sensitive areas (auth, crypto, input handling)208 - Third-party integrations2092. Run automated analysis:210 - SAST tools (Semgrep, CodeQL, Bandit)211 - Secret scanning212 - Dependency vulnerability check2133. Review authentication code:214 - Password handling (hashing, storage)215 - Session management216 - Token validation2174. Review authorization code:218 - Access control checks219 - RBAC implementation220 - Privilege boundaries2215. Review data handling:222 - Input validation223 - Output encoding224 - SQL query construction225 - File path handling2266. Review cryptographic code:227 - Algorithm selection228 - Key management229 - Random number generation2307. Document findings with severity2318. **Validation:** Automated scans passed; auth/authz reviewed; data handling checked; crypto verified; findings documented232233### Security Code Review Checklist234235| Category | Check | Risk |236|----------|-------|------|237| Input Validation | All user input validated and sanitized | Injection |238| Output Encoding | Context-appropriate encoding applied | XSS |239| Authentication | Passwords hashed with Argon2/bcrypt | Credential theft |240| Session | Secure cookie flags set (HttpOnly, Secure, SameSite) | Session hijacking |241| Authorization | Server-side permission checks on all endpoints | Privilege escalation |242| SQL | Parameterized queries used exclusively | SQL injection |243| File Access | Path traversal sequences rejected | Path traversal |244| Secrets | No hardcoded credentials or keys | Information disclosure |245| Dependencies | Known vulnerable packages updated | Supply chain |246| Logging | Sensitive data not logged | Information disclosure |247248### Secure vs Insecure Patterns249250| Pattern | Issue | Secure Alternative |251|---------|-------|-------------------|252| SQL string formatting | SQL injection | Use parameterized queries with placeholders |253| Shell command building | Command injection | Use subprocess with argument lists, no shell |254| Path concatenation | Path traversal | Validate and canonicalize paths |255| MD5/SHA1 for passwords | Weak hashing | Use Argon2id or bcrypt |256| Math.random for tokens | Predictable values | Use crypto.getRandomValues |257258### Inline Code Examples259260**SQL Injection — insecure vs. secure (Python):**261262```python263# ❌ Insecure: string formatting allows SQL injection264query = f"SELECT * FROM users WHERE username = '{username}'"265cursor.execute(query)266267# ✅ Secure: parameterized query — user input never interpreted as SQL268query = "SELECT * FROM users WHERE username = %s"269cursor.execute(query, (username,))270```271272**Password Hashing with Argon2id (Python):**273274```python275from argon2 import PasswordHasher276277ph = PasswordHasher() # uses secure defaults (time_cost, memory_cost)278279# On registration280hashed = ph.hash(plain_password)281282# On login — raises argon2.exceptions.VerifyMismatchError on failure283ph.verify(hashed, plain_password)284```285286**Secret Scanning — core pattern matching (Python):**287288```python289import re, pathlib290291SECRET_PATTERNS = {292 "aws_access_key": re.compile(r"AKIA[0-9A-Z]{16}"),293 "github_token": re.compile(r"ghp_[A-Za-z0-9]{36}"),294 "private_key": re.compile(r"-----BEGIN (RSA |EC )?PRIVATE KEY-----"),295 "generic_secret": re.compile(r'(?i)(password|secret|api_key)\s*=\s*["']?\S{8,}'),296}297298def scan_file(path: pathlib.Path) -> list[dict]:299 findings = []300 for lineno, line in enumerate(path.read_text(errors="replace").splitlines(), 1):301 for name, pattern in SECRET_PATTERNS.items():302 if pattern.search(line):303 findings.append({"file": str(path), "line": lineno, "type": name})304 return findings305```306307---308309## Incident Response Workflow310311Respond to and contain security incidents.312313### Workflow: Handle Security Incident3143151. Identify and triage:316 - Validate incident is genuine317 - Assess initial scope and severity318 - Activate incident response team3192. Contain the threat:320 - Isolate affected systems321 - Block malicious IPs/accounts322 - Disable compromised credentials3233. Eradicate root cause:324 - Remove malware/backdoors325 - Patch vulnerabilities326 - Update configurations3274. Recover operations:328 - Restore from clean backups329 - Verify system integrity330 - Monitor for recurrence3315. Conduct post-mortem:332 - Timeline reconstruction333 - Root cause analysis334 - Lessons learned3356. Implement improvements:336 - Update detection rules337 - Enhance controls338 - Update runbooks3397. Document and report3408. **Validation:** Threat contained; root cause eliminated; systems recovered; post-mortem complete; improvements implemented341342### Incident Severity Levels343344| Level | Response Time | Escalation |345|-------|---------------|------------|346| P1 - Critical (active breach/exfiltration) | Immediate | CISO, Legal, Executive |347| P2 - High (confirmed, contained) | 1 hour | Security Lead, IT Director |348| P3 - Medium (potential, under investigation) | 4 hours | Security Team |349| P4 - Low (suspicious, low impact) | 24 hours | On-call engineer |350351### Incident Response Checklist352353| Phase | Actions |354|-------|---------|355| Identification | Validate alert, assess scope, determine severity |356| Containment | Isolate systems, preserve evidence, block access |357| Eradication | Remove threat, patch vulnerabilities, reset credentials |358| Recovery | Restore services, verify integrity, increase monitoring |359| Lessons Learned | Document timeline, identify gaps, update procedures |360361---362363## Security Tools Reference364365### Recommended Security Tools366367| Category | Tools |368|----------|-------|369| SAST | Semgrep, CodeQL, Bandit (Python), ESLint security plugins |370| DAST | OWASP ZAP, Burp Suite, Nikto |371| Dependency Scanning | Snyk, Dependabot, npm audit, pip-audit |372| Secret Detection | GitLeaks, TruffleHog, detect-secrets |373| Container Security | Trivy, Clair, Anchore |374| Infrastructure | Checkov, tfsec, ScoutSuite |375| Network | Wireshark, Nmap, Masscan |376| Penetration | Metasploit, sqlmap, Burp Suite Pro |377378### Cryptographic Algorithm Selection379380| Use Case | Algorithm | Key Size |381|----------|-----------|----------|382| Symmetric encryption | AES-256-GCM | 256 bits |383| Password hashing | Argon2id | N/A (use defaults) |384| Message authentication | HMAC-SHA256 | 256 bits |385| Digital signatures | Ed25519 | 256 bits |386| Key exchange | X25519 | 256 bits |387| TLS | TLS 1.3 | N/A |388389See: [references/cryptography-implementation.md](references/cryptography-implementation.md)390391---392393## Tools and References394395### Scripts396397| Script | Purpose |398|--------|---------|399| [threat_modeler.py](scripts/threat_modeler.py) | STRIDE threat analysis with DREAD risk scoring; JSON and text output; interactive guided mode |400| [secret_scanner.py](scripts/secret_scanner.py) | Detect hardcoded secrets and credentials across 20+ patterns; CI/CD integration ready |401402For usage, see the inline code examples in [Secure Code Review Workflow](#inline-code-examples) and the script source files directly.403404### References405406| Document | Content |407|----------|---------|408| [security-architecture-patterns.md](references/security-architecture-patterns.md) | Zero Trust, defense-in-depth, authentication patterns, API security |409| [threat-modeling-guide.md](references/threat-modeling-guide.md) | STRIDE methodology, attack trees, DREAD scoring, DFD creation |410| [cryptography-implementation.md](references/cryptography-implementation.md) | AES-GCM, RSA, Ed25519, password hashing, key management |411412---413414## Security Standards Reference415416### Security Headers Checklist417418| Header | Recommended Value |419|--------|-------------------|420| Content-Security-Policy | default-src self; script-src self |421| X-Frame-Options | DENY |422| X-Content-Type-Options | nosniff |423| Strict-Transport-Security | max-age=31536000; includeSubDomains |424| Referrer-Policy | strict-origin-when-cross-origin |425| Permissions-Policy | geolocation=(), microphone=(), camera=() |426427For compliance framework requirements (OWASP ASVS, CIS Benchmarks, NIST CSF, PCI-DSS, HIPAA, SOC 2), refer to the respective official documentation.428429---430431## Related Skills432433| Skill | Integration Point |434|-------|-------------------|435| [senior-devops](../senior-devops/) | CI/CD security, infrastructure hardening |436| [senior-secops](../senior-secops/) | Security monitoring, incident response |437| [senior-backend](../senior-backend/) | Secure API development |438| [senior-architect](../senior-architect/) | Security architecture decisions |