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:
- Spoofing: Can identity be faked?
- Tampering: Can data be modified?
- Repudiation: Can actions be denied?
- Information Disclosure: Can data leak?
- Denial of Service: Can availability be affected?
- Elevation of Privilege: Can access be escalated?
- 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 |
Description |
Security Property |
Mitigation Focus |
| Spoofing |
Impersonating users or systems |
Authentication |
MFA, certificates, strong auth |
| Tampering |
Modifying data or code |
Integrity |
Signing, checksums, validation |
| Repudiation |
Denying actions |
Non-repudiation |
Audit logs, digital signatures |
| Information Disclosure |
Exposing data |
Confidentiality |
Encryption, access controls |
| Denial of Service |
Disrupting availability |
Availability |
Rate limiting, redundancy |
| Elevation of Privilege |
Gaining unauthorized access |
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
OWASP Top 10 Mapping
| Rank |
Vulnerability |
Testing Approach |
| A01 |
Broken Access Control |
Manual IDOR testing, authorization checks |
| A02 |
Cryptographic Failures |
Algorithm review, key management audit |
| A03 |
Injection |
SAST + manual payload testing |
| A04 |
Insecure Design |
Threat modeling, architecture review |
| A05 |
Security Misconfiguration |
Configuration audit, CIS benchmarks |
| A06 |
Vulnerable Components |
Dependency scanning, CVE monitoring |
| A07 |
Authentication Failures |
Password policy, session management review |
| A08 |
Software/Data Integrity |
CI/CD security, code signing verification |
| A09 |
Logging Failures |
Log review, SIEM configuration check |
| A10 |
SSRF |
Manual URL manipulation testing |
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 |
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 |
Description |
Response Time |
Escalation |
| P1 - Critical |
Active breach, data exfiltration |
Immediate |
CISO, Legal, Executive |
| P2 - High |
Confirmed compromise, contained |
1 hour |
Security Lead, IT Director |
| P3 - Medium |
Potential compromise, under investigation |
4 hours |
Security Team |
| P4 - Low |
Suspicious activity, 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 |
Usage |
| threat_modeler.py |
STRIDE threat analysis with risk scoring |
python threat_modeler.py --component "Authentication" |
| secret_scanner.py |
Detect hardcoded secrets and credentials |
python secret_scanner.py /path/to/project |
Threat Modeler Features:
- STRIDE analysis for any system component
- DREAD risk scoring
- Mitigation recommendations
- JSON and text output formats
- Interactive mode for guided analysis
Secret Scanner Features:
- Detects AWS, GCP, Azure credentials
- Finds API keys and tokens (GitHub, Slack, Stripe)
- Identifies private keys and passwords
- Supports 20+ secret patterns
- CI/CD integration ready
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
Compliance Frameworks
| Framework |
Focus |
Applicable To |
| OWASP ASVS |
Application security |
Web applications |
| CIS Benchmarks |
System hardening |
Servers, containers, cloud |
| NIST CSF |
Risk management |
Enterprise security programs |
| PCI-DSS |
Payment card data |
Payment processing |
| HIPAA |
Healthcare data |
Healthcare applications |
| SOC 2 |
Service organization controls |
SaaS providers |
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=() |
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.4---5
6# Senior Security Engineer
7
8Security engineering tools for threat modeling, vulnerability analysis, secure architecture design, and penetration testing.
9
10---
11
12## Table of Contents
13
14- [Threat Modeling Workflow](#threat-modeling-workflow)
15- [Security Architecture Workflow](#security-architecture-workflow)
16- [Vulnerability Assessment Workflow](#vulnerability-assessment-workflow)
17- [Secure Code Review Workflow](#secure-code-review-workflow)
18- [Incident Response Workflow](#incident-response-workflow)
19- [Security Tools Reference](#security-tools-reference)
20- [Tools and References](#tools-and-references)
21
22---
23
24## Threat Modeling Workflow
25
26Identify and analyze security threats using STRIDE methodology.
27
28### Workflow: Conduct Threat Model
29
301. Define system scope and boundaries:
31 - Identify assets to protect
32 - Map trust boundaries
33 - Document data flows
342. Create data flow diagram:
35 - External entities (users, services)
36 - Processes (application components)
37 - Data stores (databases, caches)
38 - Data flows (APIs, network connections)
393. Apply STRIDE to each DFD element:
40 - Spoofing: Can identity be faked?
41 - Tampering: Can data be modified?
42 - Repudiation: Can actions be denied?
43 - Information Disclosure: Can data leak?
44 - Denial of Service: Can availability be affected?
45 - Elevation of Privilege: Can access be escalated?
464. Score risks using DREAD:
47 - Damage potential (1-10)
48 - Reproducibility (1-10)
49 - Exploitability (1-10)
50 - Affected users (1-10)
51 - Discoverability (1-10)
525. Prioritize threats by risk score
536. Define mitigations for each threat
547. Document in threat model report
558. **Validation:** All DFD elements analyzed; STRIDE applied; threats scored; mitigations mapped
56
57### STRIDE Threat Categories
58
59| Category | Description | Security Property | Mitigation Focus |
60|----------|-------------|-------------------|------------------|
61| Spoofing | Impersonating users or systems | Authentication | MFA, certificates, strong auth |
62| Tampering | Modifying data or code | Integrity | Signing, checksums, validation |
63| Repudiation | Denying actions | Non-repudiation | Audit logs, digital signatures |
64| Information Disclosure | Exposing data | Confidentiality | Encryption, access controls |
65| Denial of Service | Disrupting availability | Availability | Rate limiting, redundancy |
66| Elevation of Privilege | Gaining unauthorized access | Authorization | RBAC, least privilege |
67
68### STRIDE per Element Matrix
69
70| DFD Element | S | T | R | I | D | E |
71|-------------|---|---|---|---|---|---|
72| External Entity | X | | X | | | |
73| Process | X | X | X | X | X | X |
74| Data Store | | X | X | X | X | |
75| Data Flow | | X | | X | X | |
76
77See: [references/threat-modeling-guide.md](references/threat-modeling-guide.md)
78
79---
80
81## Security Architecture Workflow
82
83Design secure systems using defense-in-depth principles.
84
85### Workflow: Design Secure Architecture
86
871. Define security requirements:
88 - Compliance requirements (GDPR, HIPAA, PCI-DSS)
89 - Data classification (public, internal, confidential, restricted)
90 - Threat model inputs
912. Apply defense-in-depth layers:
92 - Perimeter: WAF, DDoS protection, rate limiting
93 - Network: Segmentation, IDS/IPS, mTLS
94 - Host: Patching, EDR, hardening
95 - Application: Input validation, authentication, secure coding
96 - Data: Encryption at rest and in transit
973. Implement Zero Trust principles:
98 - Verify explicitly (every request)
99 - Least privilege access (JIT/JEA)
100 - Assume breach (segment, monitor)
1014. Configure authentication and authorization:
102 - Identity provider selection
103 - MFA requirements
104 - RBAC/ABAC model
1055. Design encryption strategy:
106 - Key management approach
107 - Algorithm selection
108 - Certificate lifecycle
1096. Plan security monitoring:
110 - Log aggregation
111 - SIEM integration
112 - Alerting rules
1137. Document architecture decisions
1148. **Validation:** Defense-in-depth layers defined; Zero Trust applied; encryption strategy documented; monitoring planned
115
116### Defense-in-Depth Layers
117
118```
119Layer 1: PERIMETER
120 WAF, DDoS mitigation, DNS filtering, rate limiting
121
122Layer 2: NETWORK
123 Segmentation, IDS/IPS, network monitoring, VPN, mTLS
124
125Layer 3: HOST
126 Endpoint protection, OS hardening, patching, logging
127
128Layer 4: APPLICATION
129 Input validation, authentication, secure coding, SAST
130
131Layer 5: DATA
132 Encryption at rest/transit, access controls, DLP, backup
133```
134
135### Authentication Pattern Selection
136
137| Use Case | Recommended Pattern |
138|----------|---------------------|
139| Web application | OAuth 2.0 + PKCE with OIDC |
140| API authentication | JWT with short expiration + refresh tokens |
141| Service-to-service | mTLS with certificate rotation |
142| CLI/Automation | API keys with IP allowlisting |
143| High security | FIDO2/WebAuthn hardware keys |
144
145See: [references/security-architecture-patterns.md](references/security-architecture-patterns.md)
146
147---
148
149## Vulnerability Assessment Workflow
150
151Identify and remediate security vulnerabilities in applications.
152
153### Workflow: Conduct Vulnerability Assessment
154
1551. Define assessment scope:
156 - In-scope systems and applications
157 - Testing methodology (black box, gray box, white box)
158 - Rules of engagement
1592. Gather information:
160 - Technology stack inventory
161 - Architecture documentation
162 - Previous vulnerability reports
1633. Perform automated scanning:
164 - SAST (static analysis)
165 - DAST (dynamic analysis)
166 - Dependency scanning
167 - Secret detection
1684. Conduct manual testing:
169 - Business logic flaws
170 - Authentication bypass
171 - Authorization issues
172 - Injection vulnerabilities
1735. Classify findings by severity:
174 - Critical: Immediate exploitation risk
175 - High: Significant impact, easier to exploit
176 - Medium: Moderate impact or difficulty
177 - Low: Minor impact
1786. Develop remediation plan:
179 - Prioritize by risk
180 - Assign owners
181 - Set deadlines
1827. Verify fixes and document
1838. **Validation:** Scope defined; automated and manual testing complete; findings classified; remediation tracked
184
185### OWASP Top 10 Mapping
186
187| Rank | Vulnerability | Testing Approach |
188|------|---------------|------------------|
189| A01 | Broken Access Control | Manual IDOR testing, authorization checks |
190| A02 | Cryptographic Failures | Algorithm review, key management audit |
191| A03 | Injection | SAST + manual payload testing |
192| A04 | Insecure Design | Threat modeling, architecture review |
193| A05 | Security Misconfiguration | Configuration audit, CIS benchmarks |
194| A06 | Vulnerable Components | Dependency scanning, CVE monitoring |
195| A07 | Authentication Failures | Password policy, session management review |
196| A08 | Software/Data Integrity | CI/CD security, code signing verification |
197| A09 | Logging Failures | Log review, SIEM configuration check |
198| A10 | SSRF | Manual URL manipulation testing |
199
200### Vulnerability Severity Matrix
201
202| Impact / Exploitability | Easy | Moderate | Difficult |
203|-------------------------|------|----------|-----------|
204| Critical | Critical | Critical | High |
205| High | Critical | High | Medium |
206| Medium | High | Medium | Low |
207| Low | Medium | Low | Low |
208
209---
210
211## Secure Code Review Workflow
212
213Review code for security vulnerabilities before deployment.
214
215### Workflow: Conduct Security Code Review
216
2171. Establish review scope:
218 - Changed files and functions
219 - Security-sensitive areas (auth, crypto, input handling)
220 - Third-party integrations
2212. Run automated analysis:
222 - SAST tools (Semgrep, CodeQL, Bandit)
223 - Secret scanning
224 - Dependency vulnerability check
2253. Review authentication code:
226 - Password handling (hashing, storage)
227 - Session management
228 - Token validation
2294. Review authorization code:
230 - Access control checks
231 - RBAC implementation
232 - Privilege boundaries
2335. Review data handling:
234 - Input validation
235 - Output encoding
236 - SQL query construction
237 - File path handling
2386. Review cryptographic code:
239 - Algorithm selection
240 - Key management
241 - Random number generation
2427. Document findings with severity
2438. **Validation:** Automated scans passed; auth/authz reviewed; data handling checked; crypto verified; findings documented
244
245### Security Code Review Checklist
246
247| Category | Check | Risk |
248|----------|-------|------|
249| Input Validation | All user input validated and sanitized | Injection |
250| Output Encoding | Context-appropriate encoding applied | XSS |
251| Authentication | Passwords hashed with Argon2/bcrypt | Credential theft |
252| Session | Secure cookie flags set (HttpOnly, Secure, SameSite) | Session hijacking |
253| Authorization | Server-side permission checks on all endpoints | Privilege escalation |
254| SQL | Parameterized queries used exclusively | SQL injection |
255| File Access | Path traversal sequences rejected | Path traversal |
256| Secrets | No hardcoded credentials or keys | Information disclosure |
257| Dependencies | Known vulnerable packages updated | Supply chain |
258| Logging | Sensitive data not logged | Information disclosure |
259
260### Secure vs Insecure Patterns
261
262| Pattern | Issue | Secure Alternative |
263|---------|-------|-------------------|
264| SQL string formatting | SQL injection | Use parameterized queries with placeholders |
265| Shell command building | Command injection | Use subprocess with argument lists, no shell |
266| Path concatenation | Path traversal | Validate and canonicalize paths |
267| MD5/SHA1 for passwords | Weak hashing | Use Argon2id or bcrypt |
268| Math.random for tokens | Predictable values | Use crypto.getRandomValues |
269
270---
271
272## Incident Response Workflow
273
274Respond to and contain security incidents.
275
276### Workflow: Handle Security Incident
277
2781. Identify and triage:
279 - Validate incident is genuine
280 - Assess initial scope and severity
281 - Activate incident response team
2822. Contain the threat:
283 - Isolate affected systems
284 - Block malicious IPs/accounts
285 - Disable compromised credentials
2863. Eradicate root cause:
287 - Remove malware/backdoors
288 - Patch vulnerabilities
289 - Update configurations
2904. Recover operations:
291 - Restore from clean backups
292 - Verify system integrity
293 - Monitor for recurrence
2945. Conduct post-mortem:
295 - Timeline reconstruction
296 - Root cause analysis
297 - Lessons learned
2986. Implement improvements:
299 - Update detection rules
300 - Enhance controls
301 - Update runbooks
3027. Document and report
3038. **Validation:** Threat contained; root cause eliminated; systems recovered; post-mortem complete; improvements implemented
304
305### Incident Severity Levels
306
307| Level | Description | Response Time | Escalation |
308|-------|-------------|---------------|------------|
309| P1 - Critical | Active breach, data exfiltration | Immediate | CISO, Legal, Executive |
310| P2 - High | Confirmed compromise, contained | 1 hour | Security Lead, IT Director |
311| P3 - Medium | Potential compromise, under investigation | 4 hours | Security Team |
312| P4 - Low | Suspicious activity, low impact | 24 hours | On-call engineer |
313
314### Incident Response Checklist
315
316| Phase | Actions |
317|-------|---------|
318| Identification | Validate alert, assess scope, determine severity |
319| Containment | Isolate systems, preserve evidence, block access |
320| Eradication | Remove threat, patch vulnerabilities, reset credentials |
321| Recovery | Restore services, verify integrity, increase monitoring |
322| Lessons Learned | Document timeline, identify gaps, update procedures |
323
324---
325
326## Security Tools Reference
327
328### Recommended Security Tools
329
330| Category | Tools |
331|----------|-------|
332| SAST | Semgrep, CodeQL, Bandit (Python), ESLint security plugins |
333| DAST | OWASP ZAP, Burp Suite, Nikto |
334| Dependency Scanning | Snyk, Dependabot, npm audit, pip-audit |
335| Secret Detection | GitLeaks, TruffleHog, detect-secrets |
336| Container Security | Trivy, Clair, Anchore |
337| Infrastructure | Checkov, tfsec, ScoutSuite |
338| Network | Wireshark, Nmap, Masscan |
339| Penetration | Metasploit, sqlmap, Burp Suite Pro |
340
341### Cryptographic Algorithm Selection
342
343| Use Case | Algorithm | Key Size |
344|----------|-----------|----------|
345| Symmetric encryption | AES-256-GCM | 256 bits |
346| Password hashing | Argon2id | N/A (use defaults) |
347| Message authentication | HMAC-SHA256 | 256 bits |
348| Digital signatures | Ed25519 | 256 bits |
349| Key exchange | X25519 | 256 bits |
350| TLS | TLS 1.3 | N/A |
351
352See: [references/cryptography-implementation.md](references/cryptography-implementation.md)
353
354---
355
356## Tools and References
357
358### Scripts
359
360| Script | Purpose | Usage |
361|--------|---------|-------|
362| [threat_modeler.py](scripts/threat_modeler.py) | STRIDE threat analysis with risk scoring | `python threat_modeler.py --component "Authentication"` |
363| [secret_scanner.py](scripts/secret_scanner.py) | Detect hardcoded secrets and credentials | `python secret_scanner.py /path/to/project` |
364
365**Threat Modeler Features:**
366- STRIDE analysis for any system component
367- DREAD risk scoring
368- Mitigation recommendations
369- JSON and text output formats
370- Interactive mode for guided analysis
371
372**Secret Scanner Features:**
373- Detects AWS, GCP, Azure credentials
374- Finds API keys and tokens (GitHub, Slack, Stripe)
375- Identifies private keys and passwords
376- Supports 20+ secret patterns
377- CI/CD integration ready
378
379### References
380
381| Document | Content |
382|----------|---------|
383| [security-architecture-patterns.md](references/security-architecture-patterns.md) | Zero Trust, defense-in-depth, authentication patterns, API security |
384| [threat-modeling-guide.md](references/threat-modeling-guide.md) | STRIDE methodology, attack trees, DREAD scoring, DFD creation |
385| [cryptography-implementation.md](references/cryptography-implementation.md) | AES-GCM, RSA, Ed25519, password hashing, key management |
386
387---
388
389## Security Standards Reference
390
391### Compliance Frameworks
392
393| Framework | Focus | Applicable To |
394|-----------|-------|---------------|
395| OWASP ASVS | Application security | Web applications |
396| CIS Benchmarks | System hardening | Servers, containers, cloud |
397| NIST CSF | Risk management | Enterprise security programs |
398| PCI-DSS | Payment card data | Payment processing |
399| HIPAA | Healthcare data | Healthcare applications |
400| SOC 2 | Service organization controls | SaaS providers |
401
402### Security Headers Checklist
403
404| Header | Recommended Value |
405|--------|-------------------|
406| Content-Security-Policy | default-src self; script-src self |
407| X-Frame-Options | DENY |
408| X-Content-Type-Options | nosniff |
409| Strict-Transport-Security | max-age=31536000; includeSubDomains |
410| Referrer-Policy | strict-origin-when-cross-origin |
411| Permissions-Policy | geolocation=(), microphone=(), camera=() |
412
413---
414
415## Related Skills
416
417| Skill | Integration Point |
418|-------|-------------------|
419| [senior-devops](../senior-devops/) | CI/CD security, infrastructure hardening |
420| [senior-secops](../senior-secops/) | Security monitoring, incident response |
421| [senior-backend](../senior-backend/) | Secure API development |
422| [senior-architect](../senior-architect/) | Security architecture decisions |