| name | senior-security |
| description | Performs STRIDE threat modeling, DREAD risk scoring, secret detection, and secure architecture design. Use when conducting threat models, reviewing code for security vulnerabilities, designing defense-in-depth architectures, or scanning for hardcoded secrets and credentials.
|
| license | MIT + Commons Clause |
| metadata | {"version":"1.0.0","author":"borghei","category":"engineering","domain":"application-security","updated":"2026-03-31T00:00:00.000Z","tags":["owasp","threat-modeling","penetration-testing","application-security"]} |
Senior Security Engineer
The agent performs STRIDE threat analysis with DREAD risk scoring, designs defense-in-depth security architectures with Zero Trust principles, conducts secure code reviews against OWASP Top 10, and scans codebases for hardcoded secrets across 20+ credential patterns.
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
Anti-Patterns
- Security by obscurity -- hiding endpoints or using non-standard ports is not a control; implement authentication, authorization, and encryption
- MD5/SHA1 for password hashing -- both are broken for this purpose; use Argon2id or bcrypt with cost factor >= 12
- Math.random for tokens -- predictable values allow session hijacking; use
crypto.getRandomValues() or secrets.token_hex()
- Shell=True in subprocess -- enables command injection; use argument lists with
subprocess.run(["cmd", "arg"])
- Threat model without data flow diagram -- STRIDE analysis requires DFD elements to be systematic; skip the DFD and you miss entire attack surfaces
- Accepted risks without review cadence -- DREAD scores drift as systems evolve; re-validate accepted risks every 90 days
Troubleshooting
| Problem | Cause | Solution |
|---|
| Secret scanner reports false positives on test fixtures | Test files contain example tokens that match secret patterns | Add test directories to the exclude list or filter by --severity critical to focus on confirmed secrets |
| Threat model returns all threats instead of component-specific ones | Component name does not match any entry in the component mapping | Use a recognized component keyword (e.g., "authentication", "api", "database", "network", "storage") or a composite like "web application" |
| DREAD scores seem inflated for low-likelihood threats | DREAD factors are derived from likelihood and severity with fixed multipliers | Interpret DREAD as a relative ranking within the report, not an absolute metric; adjust risk acceptance thresholds accordingly |
| Secret scanner misses secrets in non-standard file extensions | Only files whose extensions appear in the pattern's file_extensions list are scanned | Rename config files to use a recognized extension (e.g., .conf, .env, .yml) or extend the pattern database |
| Threat model does not cover custom component types | The COMPONENT_MAPPING dictionary has a fixed set of keywords | Add new entries to COMPONENT_MAPPING in threat_modeler.py for project-specific components |
| Secret scanner exits with code 1 even after fixing secrets | Previous scan results are cached or the fix introduced a new match | Re-run the scanner after every fix; exit code 1 triggers whenever any critical or high finding remains |
| Security headers audit produces incomplete results | Application is behind a reverse proxy that strips or overrides headers | Test headers at the edge (CDN/load balancer) rather than at the application origin |
Success Criteria
- Zero critical- or high-severity secrets detected by
secret_scanner.py across the entire codebase before every release.
- Threat model coverage above 90%: every component in the data flow diagram has a completed STRIDE analysis with documented mitigations.
- All OWASP Top 10 vulnerability categories addressed in the security architecture with at least one compensating control per category.
- Mean time to remediate critical vulnerabilities under 48 hours from discovery to verified fix.
- 100% of authentication and authorization code paths reviewed with the Secure Code Review Checklist before merge.
- Incident response exercises (tabletop or simulated) conducted at least quarterly with post-mortem documentation.
- DREAD risk scores for all remaining accepted risks reviewed and re-validated every 90 days.
Scope & Limitations
This skill covers:
- Application-level security: threat modeling, secure code review, secret detection, and vulnerability assessment for web applications and APIs.
- Security architecture design: defense-in-depth layering, Zero Trust patterns, authentication/authorization model selection, and encryption strategy.
- Incident response planning: severity classification, containment procedures, post-mortem frameworks, and runbook creation.
- Compliance mapping: OWASP ASVS, CIS Benchmarks, NIST CSF, PCI-DSS, HIPAA, and SOC 2 alignment at the application layer.
This skill does NOT cover:
- Infrastructure and cloud security hardening (see senior-devops and aws-solution-architect).
- Runtime security monitoring, SIEM rule authoring, and SOC operations (see senior-secops).
- Full regulatory compliance programs, audit evidence collection, and certification processes (see ra-qm-team).
- Network penetration testing tooling, red team operations, and physical security assessments.
Integration Points
| Skill | Integration | Data Flow |
|---|
| senior-devops | CI/CD pipeline security gates | Threat model mitigations feed into pipeline hardening requirements; secret scanner runs as a pre-commit or CI step |
| senior-secops | Security monitoring and incident response | Threat model outputs define detection rules; incident severity levels align with SecOps alerting tiers |
| senior-backend | Secure API development | Secure code review checklist applied to backend PRs; authentication pattern selection guides API auth implementation |
| senior-architect | Security architecture decisions | Defense-in-depth layers and Zero Trust principles inform architecture design reviews; STRIDE results feed architecture risk register |
| senior-qa | Security testing integration | Vulnerability assessment findings become QA regression test cases; OWASP Top 10 mapping drives security test coverage |
| ra-qm-team | Compliance framework alignment | Security controls mapped to SOC 2, PCI-DSS, and HIPAA requirements; threat model documentation satisfies audit evidence needs |
Tool Reference
threat_modeler.py
Purpose: Performs STRIDE threat analysis on system components with DREAD risk scoring, mitigation recommendations, and structured reporting.
Usage:
python threat_modeler.py --component "User Authentication"
python threat_modeler.py --component "API Gateway" --assets "user_data,tokens" --json
python threat_modeler.py --component "Database" --output report.txt
python threat_modeler.py --interactive
python threat_modeler.py --list-threats
Flags:
| Flag | Short | Type | Required | Description |
|---|
--component | -c | string | Yes (unless --interactive or --list-threats) | Component to analyze (e.g., "User Authentication", "API Gateway", "Database") |
--assets | -a | string | No | Comma-separated list of assets to protect |
--json | | flag | No | Output report as JSON instead of text |
--interactive | -i | flag | No | Run guided interactive threat modeling session |
--list-threats | -l | flag | No | List all threats in the built-in database |
--output | -o | string | No | Write report to file path instead of stdout |
Example:
$ python threat_modeler.py --component "API Gateway" --json --output api-threats.json
Report written to api-threats.json
Output Formats:
- Text (default): Structured report grouped by STRIDE category with risk scores, DREAD ratings, attack vectors, and mitigations.
- JSON (
--json): Machine-readable object containing component, analysis_date, summary (counts by risk level), and threats array with full DREAD breakdown per threat.
secret_scanner.py
Purpose: Detects hardcoded secrets, API keys, credentials, and private keys in source code. Supports 20+ secret patterns across cloud providers (AWS, GCP, Azure), authentication tokens (GitHub, GitLab, Slack, Stripe, Twilio, SendGrid), cryptographic keys, and generic credential patterns. Exits with code 1 when critical or high findings are present, making it CI/CD-ready.
Usage:
python secret_scanner.py /path/to/project
python secret_scanner.py /path/to/file.py
python secret_scanner.py /path/to/project --format json --output report.json
python secret_scanner.py /path/to/project --severity critical
python secret_scanner.py --list-patterns
Flags:
| Flag | Short | Type | Required | Description |
|---|
path | | positional | Yes (unless --list-patterns) | File or directory path to scan |
--format | -f | choice: text, json | No | Output format (default: text) |
--output | -o | string | No | Write report to file path instead of stdout |
--list-patterns | -l | flag | No | List all detection patterns with IDs and severity |
--severity | -s | choice: critical, high, medium, low | No | Minimum severity threshold to report (includes all levels from critical down to the specified level) |
Example:
$ python secret_scanner.py ./src --severity high --format json
{
"target": "./src",
"scan_date": "2026-03-21T10:30:00",
"summary": { "total": 2, "by_severity": { "critical": 1, "high": 1, "medium": 0, "low": 0 } },
"findings": [ ... ]
}
Output Formats:
- Text (default): Severity-grouped report showing pattern ID, file path with line number, masked match text, and remediation recommendation.
- JSON (
--format json): Machine-readable object with target, scan_date, summary (counts by severity), and findings array. Each finding includes pattern_id, name, severity, file_path, line_number, matched_text (masked), and recommendation.
