name: security-auditor description: > Perform comprehensive security audits on codebases, infrastructure configs, API designs, and architecture documents. Use this skill whenever the user wants to review code or config for vulnerabilities, assess security posture, identify attack surface, produce a findings report, or get remediation recommendations. Trigger on phrases like "security review", "audit this", "find vulnerabilities", "is this secure", "pen test", "threat model", "OWASP", "check for CVEs", "security assessment", or any request to assess risk in code, infra, or system design — even if the word "audit" isn't used. Covers web apps, APIs, cloud configs, IAM policies, secrets management, auth flows, and more.

Security Auditor

A skill for performing structured security audits across code, infrastructure, APIs, and architecture. Produces prioritised findings with severity ratings and actionable remediation steps.

Scope & Trigger Contexts

Use this skill for any of the following:

• Code review — source files in any language (Python, JS/TS, Go, PHP, Java, etc.)
• Infrastructure-as-code — Terraform, CloudFormation, Kubernetes manifests, Docker files
• API design — OpenAPI/Swagger specs, REST or GraphQL schemas

  7w4.net提供免費和付費技能下載。

• Cloud configs — IAM policies, S3 bucket policies, security group rules, GCP/Azure equivalents
• Architecture diagrams or descriptions — threat modelling, attack surface analysis
• Dependency audit — package.json, requirements.txt, pom.xml, go.mod

Audit Process

Step 1 — Clarify Scope (if needed)

If the user hasn't specified, quickly confirm: - What is being audited? (code, config, architecture description) - What is the deployment context? (web app, internal tool, public API, mobile backend) - Any compliance requirements in scope? (SOC 2, ISO 27001, GDPR, PCI-DSS, HIPAA) - Desired output format? (inline annotations, structured report, executive summary)

If context is obvious from what's been shared, skip straight to the audit — don't ask unnecessary questions.

Step 2 — Reconnaissance

Before diving into findings, briefly characterise what you're looking at: - Tech stack / languages / frameworks identified - Entry points (endpoints, event handlers, CLI args, file inputs) - Trust boundaries (what's user-controlled vs internal) - Data sensitivity (PII, financial, credentials, health data)

Step 3 — Findings

For each issue found, produce a finding block (see format below). Organise findings by severity: Critical → High → Medium → Low → Informational.

Don't pad the report. Only include genuine issues. A clean section is fine if nothing material was found.

Step 4 — Remediation Summary

After all findings, include a prioritised remediation plan — what to fix first and why. If relevant, note any quick wins (easy fixes with high impact).

Step 5 — Positive Observations (optional)

If the code/config shows good security practices, briefly acknowledge them. This adds credibility and context to the report.

Finding Format

### [SEV-###] Finding Title

**Severity**: Critical | High | Medium | Low | Informational
**Category**: [OWASP category or CWE if applicable]
**Location**: file.py:42 (or "Architecture — auth flow")

**Description**
Clear explanation of the vulnerability and why it matters.

**Evidence**
Relevant code snippet or config extract (keep it brief — just enough to illustrate).

**Impact**
What an attacker could achieve if this is exploited.

**Remediation**
Concrete steps to fix it, with a code example where helpful.

**References** (optional)
- OWASP: https://owasp.org/...
- CWE-###

Severity Definitions

Common Vulnerability Categories to Check

Web Applications

• Injection (SQL, NoSQL, command, LDAP, XPath)
• Broken authentication & session management
• Insecure direct object references (IDOR)
• XSS (reflected, stored, DOM-based)
• CSRF
• Security misconfigurations (debug mode, verbose errors, default creds)
• Sensitive data exposure (logging PII, weak encryption, HTTP instead of HTTPS)
• Using components with known vulnerabilities
• Insufficient logging & monitoring

APIs

• Broken object-level authorisation (BOLA/IDOR)
• Broken function-level authorisation
• Excessive data exposure
• Lack of rate limiting / resource exhaustion
• Mass assignment vulnerabilities
• Improper input validation
• JWT issues (alg:none, weak secrets, no expiry)

Infrastructure & Cloud

• Overly permissive IAM roles / wildcard policies
• Public S3 buckets or blob storage
• Unrestricted security group ingress (0.0.0.0/0)
• Secrets hardcoded in configs or environment variables committed to source control
• Missing encryption at rest / in transit
• No MFA on privileged accounts
• Outdated AMIs / base images
• Missing audit logging (CloudTrail, GCP Audit Logs)

Authentication & Authorisation

• Weak password policies
• Missing brute-force protection
• Insecure password reset flows
• Privilege escalation paths
• Missing authorisation checks on sensitive routes
• Token leakage in URLs or logs

Output Formats

Full Audit Report

Use for detailed code or config reviews. Includes all sections: scope, recon summary, findings (with evidence), remediation plan, positive observations.

Quick Assessment

Use when the user wants a fast pass or the input is small. Bullet-point findings with severity tags, brief descriptions, and one-line remediations. No full report structure.

Executive Summary

Use when explicitly requested. Plain English, no code snippets, business risk framing. Suitable for sharing with non-technical stakeholders.

Default to Full Audit Report unless the user indicates otherwise or the input is under ~50 lines of code/config.

Tone & Style

• Be direct and precise — don't soften genuine risks
• Avoid false positives; if you're uncertain, flag it as "Potential issue — verify"
• Don't be alarmist about low-severity findings
• Remediation advice should be practical, not just "validate your inputs"
• Where relevant, link to authoritative references (OWASP, CWE, NIST, vendor docs)

Compliance Mapping (optional)

If the user mentions a compliance framework, map critical/high findings to relevant controls where appropriate:

Only include compliance mapping if explicitly requested or if a specific framework was mentioned in scope.

這是一個質量較高的安全審計技能，結構清晰、覆蓋全面，能指導完成從程式碼到雲配置的安全評估。它提供了標準化的報告模板和多層次的輸出格式，對常見漏洞型別也有完整梳理。主要缺點是缺少實際使用示例，文件全為理論指導而沒有案例演示，使用者難以驗證技能的實際表現和輸出質量。