mirror of
https://github.com/azaion/autopilot.git
synced 2026-04-22 11:16:34 +00:00
add python scaffold folder and autodevelopment system
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,347 @@
|
||||
---
|
||||
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 Audit
|
||||
|
||||
Analyze the codebase for security vulnerabilities using OWASP principles. Produces a structured report with severity-ranked findings, remediation suggestions, and a security checklist verdict.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **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
|
||||
|
||||
## Context Resolution
|
||||
|
||||
**Project mode** (default):
|
||||
- PROBLEM_DIR: `_docs/00_problem/`
|
||||
- SOLUTION_DIR: `_docs/01_solution/`
|
||||
- DOCUMENT_DIR: `_docs/02_document/`
|
||||
- SECURITY_DIR: `_docs/05_security/`
|
||||
|
||||
**Standalone mode** (explicit target provided, e.g. `/security @src/api/`):
|
||||
- TARGET: the provided path
|
||||
- SECURITY_DIR: `_standalone/security/`
|
||||
|
||||
Announce the detected mode and resolved paths to the user before proceeding.
|
||||
|
||||
## 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`
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Static Analysis (SAST)
|
||||
|
||||
**Role**: Security engineer
|
||||
**Goal**: Identify code-level vulnerabilities through static analysis
|
||||
**Constraints**: Analysis only — no code changes
|
||||
|
||||
Scan the codebase for these vulnerability patterns:
|
||||
|
||||
**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
|
||||
|
||||
**Authentication & Authorization**:
|
||||
- Hardcoded credentials, API keys, passwords, tokens
|
||||
- Missing authentication checks on endpoints
|
||||
- Missing authorization checks (horizontal/vertical escalation paths)
|
||||
- Weak password validation rules
|
||||
|
||||
**Cryptographic Failures**:
|
||||
- Plaintext password storage (no hashing)
|
||||
- Weak hashing algorithms (MD5, SHA1 for passwords)
|
||||
- Hardcoded encryption keys or salts
|
||||
- Missing TLS/HTTPS enforcement
|
||||
|
||||
**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)
|
||||
|
||||
**Insecure Deserialization**:
|
||||
- Pickle/marshal deserialization of untrusted data
|
||||
- JSON/XML parsing without size limits
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All source directories scanned
|
||||
- [ ] Each finding has file path and line number
|
||||
- [ ] No false positives from test files or comments
|
||||
|
||||
**Save action**: Write `SECURITY_DIR/static_analysis.md`
|
||||
|
||||
---
|
||||
|
||||
### 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 timeout and rotation
|
||||
|
||||
### Authorization
|
||||
- [ ] Check authorization on every request
|
||||
- [ ] Least privilege principle
|
||||
- [ ] No horizontal/vertical escalation paths
|
||||
|
||||
### Data Protection
|
||||
- [ ] HTTPS everywhere
|
||||
- [ ] Encrypted at rest
|
||||
- [ ] Secrets not in code/logs/version control
|
||||
- [ ] PII compliance (GDPR)
|
||||
|
||||
### Input Validation
|
||||
- [ ] Server-side validation on all inputs
|
||||
- [ ] Parameterized queries (no SQL injection)
|
||||
- [ ] Output encoding (no XSS)
|
||||
- [ ] 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
|
||||
|
||||
## Escalation Rules
|
||||
|
||||
| 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 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
|
||||
|
||||
## Trigger Conditions
|
||||
|
||||
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`
|
||||
|
||||
**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)
|
||||
|
||||
## Methodology Quick Reference
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ 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