mirror of
https://github.com/azaion/detections-semantic.git
synced 2026-04-23 01:36:36 +00:00
Sync .cursor from detections
This commit is contained in:
Oleksandr Bezdieniezhnykh
+290
-243
@@ -1,300 +1,347 @@
|
||||
---
|
||||
name: security-testing
|
||||
description: "Test for security vulnerabilities using OWASP principles. Use when conducting security audits, testing auth, or implementing security practices."
|
||||
category: specialized-testing
|
||||
priority: critical
|
||||
tokenEstimate: 1200
|
||||
agents: [qe-security-scanner, qe-api-contract-validator, qe-quality-analyzer]
|
||||
implementation_status: optimized
|
||||
optimization_version: 1.0
|
||||
last_optimized: 2025-12-02
|
||||
dependencies: []
|
||||
quick_reference_card: true
|
||||
tags: [security, owasp, sast, dast, vulnerabilities, auth, injection]
|
||||
trust_tier: 3
|
||||
validation:
|
||||
schema_path: schemas/output.json
|
||||
validator_path: scripts/validate-config.json
|
||||
eval_path: evals/security-testing.yaml
|
||||
name: security
|
||||
description: |
|
||||
OWASP-based security audit skill. Analyzes codebase for vulnerabilities across dependency scanning,
|
||||
static analysis, OWASP Top 10 review, and secrets detection. Produces a structured security report
|
||||
with severity-ranked findings and remediation guidance.
|
||||
Can be invoked standalone or as part of the autopilot flow (optional step before deploy).
|
||||
Trigger phrases:
|
||||
- "security audit", "security scan", "OWASP review"
|
||||
- "vulnerability scan", "security check"
|
||||
- "check for vulnerabilities", "pentest"
|
||||
category: review
|
||||
tags: [security, owasp, sast, vulnerabilities, auth, injection, secrets]
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Security Testing
|
||||
# Security Audit
|
||||
|
||||
<default_to_action>
|
||||
When testing security or conducting audits:
|
||||
1. TEST OWASP Top 10 vulnerabilities systematically
|
||||
2. VALIDATE authentication and authorization on every endpoint
|
||||
3. SCAN dependencies for known vulnerabilities (npm audit)
|
||||
4. CHECK for injection attacks (SQL, XSS, command)
|
||||
5. VERIFY secrets aren't exposed in code/logs
|
||||
Analyze the codebase for security vulnerabilities using OWASP principles. Produces a structured report with severity-ranked findings, remediation suggestions, and a security checklist verdict.
|
||||
|
||||
**Quick Security Checks:**
|
||||
- Access control → Test horizontal/vertical privilege escalation
|
||||
- Crypto → Verify password hashing, HTTPS, no sensitive data exposed
|
||||
- Injection → Test SQL injection, XSS, command injection
|
||||
- Auth → Test weak passwords, session fixation, MFA enforcement
|
||||
- Config → Check error messages don't leak info
|
||||
## Core Principles
|
||||
|
||||
**Critical Success Factors:**
|
||||
- Think like an attacker, build like a defender
|
||||
- Security is built in, not added at the end
|
||||
- Test continuously in CI/CD, not just before release
|
||||
</default_to_action>
|
||||
- **OWASP-driven**: use the current OWASP Top 10 as the primary framework — verify the latest version at https://owasp.org/www-project-top-ten/ at audit start
|
||||
- **Evidence-based**: every finding must reference a specific file, line, or configuration
|
||||
- **Severity-ranked**: findings sorted Critical > High > Medium > Low
|
||||
- **Actionable**: every finding includes a concrete remediation suggestion
|
||||
- **Save immediately**: write artifacts to disk after each phase; never accumulate unsaved work
|
||||
- **Complement, don't duplicate**: the `/code-review` skill does a lightweight security quick-scan; this skill goes deeper
|
||||
|
||||
## Quick Reference Card
|
||||
## Context Resolution
|
||||
|
||||
### When to Use
|
||||
- Security audits and penetration testing
|
||||
- Testing authentication/authorization
|
||||
- Validating input sanitization
|
||||
- Reviewing security configuration
|
||||
**Project mode** (default):
|
||||
- PROBLEM_DIR: `_docs/00_problem/`
|
||||
- SOLUTION_DIR: `_docs/01_solution/`
|
||||
- DOCUMENT_DIR: `_docs/02_document/`
|
||||
- SECURITY_DIR: `_docs/05_security/`
|
||||
|
||||
### OWASP Top 10
|
||||
Use the most recent **stable** version of the OWASP Top 10. At the start of each security audit, research the current version at https://owasp.org/www-project-top-ten/ and test against all listed categories. Do not rely on a hardcoded list — the OWASP Top 10 is updated periodically and the current version must be verified.
|
||||
**Standalone mode** (explicit target provided, e.g. `/security @src/api/`):
|
||||
- TARGET: the provided path
|
||||
- SECURITY_DIR: `_standalone/security/`
|
||||
|
||||
### Tools
|
||||
| Type | Tool | Purpose |
|
||||
|------|------|---------|
|
||||
| SAST | SonarQube, Semgrep | Static code analysis |
|
||||
| DAST | OWASP ZAP, Burp | Dynamic scanning |
|
||||
| Deps | npm audit, Snyk | Dependency vulnerabilities |
|
||||
| Secrets | git-secrets, TruffleHog | Secret scanning |
|
||||
Announce the detected mode and resolved paths to the user before proceeding.
|
||||
|
||||
### Agent Coordination
|
||||
- `qe-security-scanner`: Multi-layer SAST/DAST scanning
|
||||
- `qe-api-contract-validator`: API security testing
|
||||
- `qe-quality-analyzer`: Security code review
|
||||
## Prerequisite Checks
|
||||
|
||||
1. Codebase must contain source code files — **STOP if empty**
|
||||
2. Create SECURITY_DIR if it does not exist
|
||||
3. If SECURITY_DIR already contains artifacts, ask user: **resume, overwrite, or skip?**
|
||||
4. If `_docs/00_problem/security_approach.md` exists, read it for project-specific security requirements
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
At the start of execution, create a TodoWrite with all phases (1 through 5). Update status as each phase completes.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Dependency Scan
|
||||
|
||||
**Role**: Security analyst
|
||||
**Goal**: Identify known vulnerabilities in project dependencies
|
||||
**Constraints**: Scan only — no code changes
|
||||
|
||||
1. Detect the project's package manager(s): `requirements.txt`, `package.json`, `Cargo.toml`, `*.csproj`, `go.mod`
|
||||
2. Run the appropriate audit tool:
|
||||
- Python: `pip audit` or `safety check`
|
||||
- Node: `npm audit`
|
||||
- Rust: `cargo audit`
|
||||
- .NET: `dotnet list package --vulnerable`
|
||||
- Go: `govulncheck`
|
||||
3. If no audit tool is available, manually inspect dependency files for known CVEs using WebSearch
|
||||
4. Record findings with CVE IDs, affected packages, severity, and recommended upgrade versions
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All package manifests scanned
|
||||
- [ ] Each finding has a CVE ID or advisory reference
|
||||
- [ ] Upgrade paths identified for Critical/High findings
|
||||
|
||||
**Save action**: Write `SECURITY_DIR/dependency_scan.md`
|
||||
|
||||
---
|
||||
|
||||
## Key Vulnerability Tests
|
||||
### Phase 2: Static Analysis (SAST)
|
||||
|
||||
### 1. Broken Access Control
|
||||
```javascript
|
||||
// Horizontal escalation - User A accessing User B's data
|
||||
test('user cannot access another user\'s order', async () => {
|
||||
const userAToken = await login('userA');
|
||||
const userBOrder = await createOrder('userB');
|
||||
**Role**: Security engineer
|
||||
**Goal**: Identify code-level vulnerabilities through static analysis
|
||||
**Constraints**: Analysis only — no code changes
|
||||
|
||||
const response = await api.get(`/orders/${userBOrder.id}`, {
|
||||
headers: { Authorization: `Bearer ${userAToken}` }
|
||||
});
|
||||
expect(response.status).toBe(403);
|
||||
});
|
||||
Scan the codebase for these vulnerability patterns:
|
||||
|
||||
// Vertical escalation - Regular user accessing admin
|
||||
test('regular user cannot access admin', async () => {
|
||||
const userToken = await login('regularUser');
|
||||
expect((await api.get('/admin/users', {
|
||||
headers: { Authorization: `Bearer ${userToken}` }
|
||||
})).status).toBe(403);
|
||||
});
|
||||
```
|
||||
**Injection**:
|
||||
- SQL injection via string interpolation or concatenation
|
||||
- Command injection (subprocess with shell=True, exec, eval, os.system)
|
||||
- XSS via unsanitized user input in HTML output
|
||||
- Template injection
|
||||
|
||||
### 2. Injection Attacks
|
||||
```javascript
|
||||
// SQL Injection
|
||||
test('prevents SQL injection', async () => {
|
||||
const malicious = "' OR '1'='1";
|
||||
const response = await api.get(`/products?search=${malicious}`);
|
||||
expect(response.body.length).toBeLessThan(100); // Not all products
|
||||
});
|
||||
**Authentication & Authorization**:
|
||||
- Hardcoded credentials, API keys, passwords, tokens
|
||||
- Missing authentication checks on endpoints
|
||||
- Missing authorization checks (horizontal/vertical escalation paths)
|
||||
- Weak password validation rules
|
||||
|
||||
// XSS
|
||||
test('sanitizes HTML output', async () => {
|
||||
const xss = '<script>alert("XSS")</script>';
|
||||
await api.post('/comments', { text: xss });
|
||||
**Cryptographic Failures**:
|
||||
- Plaintext password storage (no hashing)
|
||||
- Weak hashing algorithms (MD5, SHA1 for passwords)
|
||||
- Hardcoded encryption keys or salts
|
||||
- Missing TLS/HTTPS enforcement
|
||||
|
||||
const html = (await api.get('/comments')).body;
|
||||
expect(html).toContain('<script>');
|
||||
expect(html).not.toContain('<script>');
|
||||
});
|
||||
```
|
||||
**Data Exposure**:
|
||||
- Sensitive data in logs or error messages (passwords, tokens, PII)
|
||||
- Sensitive fields in API responses (password hashes, SSNs)
|
||||
- Debug endpoints or verbose error messages in production configs
|
||||
- Secrets in version control (.env files, config with credentials)
|
||||
|
||||
### 3. Cryptographic Failures
|
||||
```javascript
|
||||
test('passwords are hashed', async () => {
|
||||
await db.users.create({ email: 'test@example.com', password: 'MyPassword123' });
|
||||
const user = await db.users.findByEmail('test@example.com');
|
||||
**Insecure Deserialization**:
|
||||
- Pickle/marshal deserialization of untrusted data
|
||||
- JSON/XML parsing without size limits
|
||||
|
||||
expect(user.password).not.toBe('MyPassword123');
|
||||
expect(user.password).toMatch(/^\$2[aby]\$\d{2}\$/); // bcrypt
|
||||
});
|
||||
**Self-verification**:
|
||||
- [ ] All source directories scanned
|
||||
- [ ] Each finding has file path and line number
|
||||
- [ ] No false positives from test files or comments
|
||||
|
||||
test('no sensitive data in API response', async () => {
|
||||
const response = await api.get('/users/me');
|
||||
expect(response.body).not.toHaveProperty('password');
|
||||
expect(response.body).not.toHaveProperty('ssn');
|
||||
});
|
||||
```
|
||||
|
||||
### 4. Security Misconfiguration
|
||||
```javascript
|
||||
test('errors don\'t leak sensitive info', async () => {
|
||||
const response = await api.post('/login', { email: 'nonexistent@test.com', password: 'wrong' });
|
||||
expect(response.body.error).toBe('Invalid credentials'); // Generic message
|
||||
});
|
||||
|
||||
test('sensitive endpoints not exposed', async () => {
|
||||
const endpoints = ['/debug', '/.env', '/.git', '/admin'];
|
||||
for (let ep of endpoints) {
|
||||
expect((await fetch(`https://example.com${ep}`)).status).not.toBe(200);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
### 5. Rate Limiting
|
||||
```javascript
|
||||
test('rate limiting prevents brute force', async () => {
|
||||
const responses = [];
|
||||
for (let i = 0; i < 20; i++) {
|
||||
responses.push(await api.post('/login', { email: 'test@example.com', password: 'wrong' }));
|
||||
}
|
||||
expect(responses.filter(r => r.status === 429).length).toBeGreaterThan(0);
|
||||
});
|
||||
```
|
||||
**Save action**: Write `SECURITY_DIR/static_analysis.md`
|
||||
|
||||
---
|
||||
|
||||
## Security Checklist
|
||||
### Phase 3: OWASP Top 10 Review
|
||||
|
||||
**Role**: Penetration tester
|
||||
**Goal**: Systematically review the codebase against current OWASP Top 10 categories
|
||||
**Constraints**: Review and document — no code changes
|
||||
|
||||
1. Research the current OWASP Top 10 version at https://owasp.org/www-project-top-ten/
|
||||
2. For each OWASP category, assess the codebase:
|
||||
|
||||
| Check | What to Look For |
|
||||
|-------|-----------------|
|
||||
| Broken Access Control | Missing auth middleware, IDOR vulnerabilities, CORS misconfiguration, directory traversal |
|
||||
| Cryptographic Failures | Weak algorithms, plaintext transmission, missing encryption at rest |
|
||||
| Injection | SQL, NoSQL, OS command, LDAP injection paths |
|
||||
| Insecure Design | Missing rate limiting, no input validation strategy, trust boundary violations |
|
||||
| Security Misconfiguration | Default credentials, unnecessary features enabled, missing security headers |
|
||||
| Vulnerable Components | Outdated dependencies (from Phase 1), unpatched frameworks |
|
||||
| Auth Failures | Brute force paths, weak session management, missing MFA |
|
||||
| Data Integrity Failures | Missing signature verification, insecure CI/CD, auto-update without verification |
|
||||
| Logging Failures | Missing audit logs, sensitive data in logs, no alerting for security events |
|
||||
| SSRF | Unvalidated URL inputs, internal network access from user-controlled URLs |
|
||||
|
||||
3. Rate each category: PASS / FAIL / NOT_APPLICABLE
|
||||
4. If `security_approach.md` exists, cross-reference its requirements against findings
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All current OWASP Top 10 categories assessed
|
||||
- [ ] Each FAIL has at least one specific finding with evidence
|
||||
- [ ] NOT_APPLICABLE categories have justification
|
||||
|
||||
**Save action**: Write `SECURITY_DIR/owasp_review.md`
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Configuration & Infrastructure Review
|
||||
|
||||
**Role**: DevSecOps engineer
|
||||
**Goal**: Review deployment configuration for security issues
|
||||
**Constraints**: Review only — no changes
|
||||
|
||||
If Dockerfiles, CI/CD configs, or deployment configs exist:
|
||||
|
||||
1. **Container security**: non-root user, minimal base images, no secrets in build args, health checks
|
||||
2. **CI/CD security**: secrets management, no credentials in pipeline files, artifact signing
|
||||
3. **Environment configuration**: .env handling, secrets injection method, environment separation
|
||||
4. **Network security**: exposed ports, TLS configuration, CORS settings, security headers
|
||||
|
||||
If no deployment configs exist, skip this phase and note it in the report.
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All Dockerfiles reviewed
|
||||
- [ ] All CI/CD configs reviewed
|
||||
- [ ] All environment/config files reviewed
|
||||
|
||||
**Save action**: Write `SECURITY_DIR/infrastructure_review.md`
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Security Report
|
||||
|
||||
**Role**: Security analyst
|
||||
**Goal**: Produce a consolidated security audit report
|
||||
**Constraints**: Concise, actionable, severity-ranked
|
||||
|
||||
Consolidate findings from Phases 1-4 into a structured report:
|
||||
|
||||
```markdown
|
||||
# Security Audit Report
|
||||
|
||||
**Date**: [YYYY-MM-DD]
|
||||
**Scope**: [project name / target path]
|
||||
**Verdict**: PASS | PASS_WITH_WARNINGS | FAIL
|
||||
|
||||
## Summary
|
||||
|
||||
| Severity | Count |
|
||||
|----------|-------|
|
||||
| Critical | [N] |
|
||||
| High | [N] |
|
||||
| Medium | [N] |
|
||||
| Low | [N] |
|
||||
|
||||
## OWASP Top 10 Assessment
|
||||
|
||||
| Category | Status | Findings |
|
||||
|----------|--------|----------|
|
||||
| [category] | PASS / FAIL / N/A | [count or —] |
|
||||
|
||||
## Findings
|
||||
|
||||
| # | Severity | Category | Location | Title |
|
||||
|---|----------|----------|----------|-------|
|
||||
| 1 | Critical | Injection | src/api.py:42 | SQL injection via f-string |
|
||||
|
||||
### Finding Details
|
||||
|
||||
**F1: [title]** (Severity / Category)
|
||||
- Location: `[file:line]`
|
||||
- Description: [what is vulnerable]
|
||||
- Impact: [what an attacker could do]
|
||||
- Remediation: [specific fix]
|
||||
|
||||
## Dependency Vulnerabilities
|
||||
|
||||
| Package | CVE | Severity | Fix Version |
|
||||
|---------|-----|----------|-------------|
|
||||
| [name] | [CVE-ID] | [sev] | [version] |
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate (Critical/High)
|
||||
- [action items]
|
||||
|
||||
### Short-term (Medium)
|
||||
- [action items]
|
||||
|
||||
### Long-term (Low / Hardening)
|
||||
- [action items]
|
||||
```
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All findings from Phases 1-4 included
|
||||
- [ ] No duplicate findings
|
||||
- [ ] Every finding has remediation guidance
|
||||
- [ ] Verdict matches severity logic
|
||||
|
||||
**Save action**: Write `SECURITY_DIR/security_report.md`
|
||||
|
||||
**BLOCKING**: Present report summary to user.
|
||||
|
||||
## Verdict Logic
|
||||
|
||||
- **FAIL**: any Critical or High finding exists
|
||||
- **PASS_WITH_WARNINGS**: only Medium or Low findings
|
||||
- **PASS**: no findings
|
||||
|
||||
## Security Checklist (Quick Reference)
|
||||
|
||||
### Authentication
|
||||
- [ ] Strong password requirements (12+ chars)
|
||||
- [ ] Password hashing (bcrypt, scrypt, Argon2)
|
||||
- [ ] MFA for sensitive operations
|
||||
- [ ] Account lockout after failed attempts
|
||||
- [ ] Session ID changes after login
|
||||
- [ ] Session timeout
|
||||
- [ ] Session timeout and rotation
|
||||
|
||||
### Authorization
|
||||
- [ ] Check authorization on every request
|
||||
- [ ] Least privilege principle
|
||||
- [ ] No horizontal escalation
|
||||
- [ ] No vertical escalation
|
||||
- [ ] No horizontal/vertical escalation paths
|
||||
|
||||
### Data Protection
|
||||
- [ ] HTTPS everywhere
|
||||
- [ ] Encrypted at rest
|
||||
- [ ] Secrets not in code/logs
|
||||
- [ ] Secrets not in code/logs/version control
|
||||
- [ ] PII compliance (GDPR)
|
||||
|
||||
### Input Validation
|
||||
- [ ] Server-side validation
|
||||
- [ ] Server-side validation on all inputs
|
||||
- [ ] Parameterized queries (no SQL injection)
|
||||
- [ ] Output encoding (no XSS)
|
||||
- [ ] Rate limiting
|
||||
- [ ] Rate limiting on sensitive endpoints
|
||||
|
||||
---
|
||||
### CI/CD Security
|
||||
- [ ] Dependency audit in pipeline
|
||||
- [ ] Secret scanning (git-secrets, TruffleHog)
|
||||
- [ ] SAST in pipeline (Semgrep, SonarQube)
|
||||
- [ ] No secrets in pipeline config files
|
||||
|
||||
## CI/CD Integration
|
||||
## Escalation Rules
|
||||
|
||||
```yaml
|
||||
# GitHub Actions
|
||||
security-checks:
|
||||
steps:
|
||||
- name: Dependency audit
|
||||
run: npm audit --audit-level=high
|
||||
|
||||
- name: SAST scan
|
||||
run: npm run sast
|
||||
|
||||
- name: Secret scan
|
||||
uses: trufflesecurity/trufflehog@main
|
||||
|
||||
- name: DAST scan
|
||||
if: github.ref == 'refs/heads/main'
|
||||
run: docker run owasp/zap2docker-stable zap-baseline.py -t https://staging.example.com
|
||||
```
|
||||
|
||||
**Pre-commit hooks:**
|
||||
```bash
|
||||
#!/bin/sh
|
||||
git-secrets --scan
|
||||
npm run lint:security
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent-Assisted Security Testing
|
||||
|
||||
```typescript
|
||||
// Comprehensive multi-layer scan
|
||||
await Task("Security Scan", {
|
||||
target: 'src/',
|
||||
layers: { sast: true, dast: true, dependencies: true, secrets: true },
|
||||
severity: ['critical', 'high', 'medium']
|
||||
}, "qe-security-scanner");
|
||||
|
||||
// OWASP Top 10 testing
|
||||
await Task("OWASP Scan", {
|
||||
categories: ['broken-access-control', 'injection', 'cryptographic-failures'],
|
||||
depth: 'comprehensive'
|
||||
}, "qe-security-scanner");
|
||||
|
||||
// Validate fix
|
||||
await Task("Validate Fix", {
|
||||
vulnerability: 'CVE-2024-12345',
|
||||
expectedResolution: 'upgrade package to v2.0.0',
|
||||
retestAfterFix: true
|
||||
}, "qe-security-scanner");
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Coordination Hints
|
||||
|
||||
### Memory Namespace
|
||||
```
|
||||
aqe/security/
|
||||
├── scans/* - Scan results
|
||||
├── vulnerabilities/* - Found vulnerabilities
|
||||
├── fixes/* - Remediation tracking
|
||||
└── compliance/* - Compliance status
|
||||
```
|
||||
|
||||
### Fleet Coordination
|
||||
```typescript
|
||||
const securityFleet = await FleetManager.coordinate({
|
||||
strategy: 'security-testing',
|
||||
agents: [
|
||||
'qe-security-scanner',
|
||||
'qe-api-contract-validator',
|
||||
'qe-quality-analyzer',
|
||||
'qe-deployment-readiness'
|
||||
],
|
||||
topology: 'parallel'
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Critical vulnerability found | **WARN user immediately** — do not defer to report |
|
||||
| No audit tools available | Use manual code review + WebSearch for CVEs |
|
||||
| Codebase too large for full scan | **ASK user** to prioritize areas (API endpoints, auth, data access) |
|
||||
| Finding requires runtime testing (DAST) | Note as "requires DAST verification" — this skill does static analysis only |
|
||||
| Conflicting security requirements | **ASK user** to prioritize |
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
### ❌ Security by Obscurity
|
||||
Hiding admin at `/super-secret-admin` → **Use proper auth**
|
||||
- **Security by obscurity**: hiding admin at secret URLs instead of proper auth
|
||||
- **Client-side validation only**: JavaScript validation can be bypassed; always validate server-side
|
||||
- **Trusting user input**: assume all input is malicious until proven otherwise
|
||||
- **Hardcoded secrets**: use environment variables and secret management, never code
|
||||
- **Skipping dependency scan**: known CVEs in dependencies are the lowest-hanging fruit for attackers
|
||||
|
||||
### ❌ Client-Side Validation Only
|
||||
JavaScript validation can be bypassed → **Always validate server-side**
|
||||
## Trigger Conditions
|
||||
|
||||
### ❌ Trusting User Input
|
||||
Assuming input is safe → **Sanitize, validate, escape all input**
|
||||
When the user wants to:
|
||||
- Conduct a security audit of the codebase
|
||||
- Check for vulnerabilities before deployment
|
||||
- Review security posture after implementation
|
||||
- Validate security requirements from `security_approach.md`
|
||||
|
||||
### ❌ Hardcoded Secrets
|
||||
API keys in code → **Environment variables, secret management**
|
||||
**Keywords**: "security audit", "security scan", "OWASP", "vulnerability scan", "security check", "pentest"
|
||||
|
||||
---
|
||||
**Differentiation**:
|
||||
- Lightweight security checks during implementation → handled by `/code-review` Phase 4
|
||||
- Full security audit → use this skill
|
||||
- Security requirements gathering → handled by `/problem` (security dimension)
|
||||
|
||||
## Related Skills
|
||||
- [agentic-quality-engineering](../agentic-quality-engineering/) - Security with agents
|
||||
- [api-testing-patterns](../api-testing-patterns/) - API security testing
|
||||
- [compliance-testing](../compliance-testing/) - GDPR, HIPAA, SOC2
|
||||
## Methodology Quick Reference
|
||||
|
||||
---
|
||||
|
||||
## Remember
|
||||
|
||||
**Think like an attacker:** What would you try to break? Test that.
|
||||
**Build like a defender:** Assume input is malicious until proven otherwise.
|
||||
**Test continuously:** Security testing is ongoing, not one-time.
|
||||
|
||||
**With Agents:** Agents automate vulnerability scanning, track remediation, and validate fixes. Use agents to maintain security posture at scale.
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ Security Audit (5-Phase Method) │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ PREREQ: Source code exists, SECURITY_DIR created │
|
||||
│ │
|
||||
│ 1. Dependency Scan → dependency_scan.md │
|
||||
│ 2. Static Analysis → static_analysis.md │
|
||||
│ 3. OWASP Top 10 → owasp_review.md │
|
||||
│ 4. Infrastructure → infrastructure_review.md │
|
||||
│ 5. Security Report → security_report.md │
|
||||
│ [BLOCKING: user reviews report] │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Verdict: PASS / PASS_WITH_WARNINGS / FAIL │
|
||||
│ Principles: OWASP-driven · Evidence-based · Severity-ranked │
|
||||
│ Actionable · Save immediately │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user