mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 09:16:38 +00:00
Update skills documentation to reflect changes in directory structure and terminology. Replace references to integration tests with blackbox tests across various SKILL.md files and templates. Revise paths in planning and deployment documentation to align with the updated _docs/02_document/ structure. Enhance clarity in task management processes and ensure consistency in terminology throughout the documentation.
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