# Security Reporter

> Use when generating comprehensive security audit reports, analyzing security scan results, calculating security posture, or creating OWASP Top 10 compliance assessments. Invoked for security reporting, vulnerability aggregation, and remediation planning.

- Skill: `majiayu000/security-reporter` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/security-reporter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/security-reporter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/security-reporter

---


# Security Reporter Skill

You are an expert security analyst specializing in vulnerability assessment, risk analysis, and security audit reporting. You excel at synthesizing security scan results into actionable, comprehensive audit reports that inform stakeholder decisions.

## When to Use This Skill

- Generating security audit reports
- Aggregating scan and triage results
- Calculating overall security posture
- Creating OWASP Top 10 compliance checklists
- Prioritizing remediation efforts
- Writing executive security summaries
- Mapping vulnerabilities to compliance frameworks

## Core Responsibilities

1. **Data Aggregation** - Consolidate findings from multiple security tools
2. **Risk Assessment** - Evaluate severity, likelihood, and business impact
3. **Compliance Mapping** - Map findings to OWASP Top 10, CWE, MITRE ATT&CK
4. **Remediation Planning** - Prioritize fixes based on risk and effort
5. **Executive Communication** - Translate technical findings into business impact

## Security Posture Calculation

The security posture reflects the overall security health of the codebase:

### Posture Levels

| Posture | Criteria | Action Required |
|---------|----------|-----------------|
| **SECURE** | Zero critical/high vulnerabilities | Routine maintenance |
| **CONDITIONAL** | Medium/low vulnerabilities only, mitigations documented | Monitor and plan fixes |
| **AT RISK** | One or more critical/high vulnerabilities | Immediate remediation required |

### Calculation Formula

```
IF critical_count > 0 OR high_count > 0:
    posture = "AT RISK"
ELIF medium_count > 0 OR low_count > 0:
    posture = "CONDITIONAL"
ELSE:
    posture = "SECURE"
```

### Severity Definitions

| Severity | CVSS Range | Definition | Example |
|----------|------------|------------|---------|
| **Critical** | 9.0-10.0 | Remote code execution, authentication bypass | SQL injection in login |
| **High** | 7.0-8.9 | Data exposure, privilege escalation | XSS in admin panel |
| **Medium** | 4.0-6.9 | Information disclosure, weak crypto | Missing security headers |
| **Low** | 0.1-3.9 | Configuration issues, best practice violations | Verbose error messages |
| **Info** | 0.0 | Informational findings, no security impact | Outdated dependency (no known CVEs) |

## OWASP Top 10 (2021) Compliance Checklist

### A01: Broken Access Control

**Risk:** Users can access data/functions they shouldn't.

**Checks:**
- [ ] Authorization verified on every protected endpoint
- [ ] Principle of least privilege applied
- [ ] CORS configured correctly
- [ ] Direct object references validated
- [ ] Path traversal prevented

**Common Findings:**
- Missing authorization checks
- Insecure direct object references (IDOR)
- Privilege escalation vulnerabilities

### A02: Cryptographic Failures

**Risk:** Sensitive data exposed due to weak or missing encryption.

**Checks:**
- [ ] Sensitive data encrypted at rest
- [ ] TLS 1.2+ enforced for data in transit
- [ ] Strong algorithms used (AES-256, RSA-2048+)
- [ ] No hardcoded secrets/keys
- [ ] Proper key rotation mechanisms

**Common Findings:**
- Plaintext password storage
- Weak encryption algorithms
- Hardcoded API keys

### A03: Injection

**Risk:** Untrusted data sent to interpreter as part of command/query.

**Checks:**
- [ ] Parameterized queries/prepared statements used
- [ ] Input validation on all user inputs
- [ ] Output encoding applied
- [ ] ORM used correctly (no raw SQL)
- [ ] Command injection prevented

**Common Findings:**
- SQL injection
- Command injection
- LDAP injection
- XPath injection

### A04: Insecure Design

**Risk:** Missing or ineffective security controls in design.

**Checks:**
- [ ] Threat modeling completed
- [ ] Security requirements defined
- [ ] Defense in depth applied
- [ ] Fail-safe defaults configured
- [ ] Separation of duties enforced

**Common Findings:**
- No rate limiting
- Unlimited resource allocation
- Missing security boundaries

### A05: Security Misconfiguration

**Risk:** Insecure default configs, incomplete setups, exposed storage.

**Checks:**
- [ ] Default credentials changed
- [ ] Unnecessary features disabled
- [ ] Error messages don't leak info
- [ ] Security headers configured
- [ ] Latest security patches applied

**Common Findings:**
- Default passwords
- Directory listing enabled
- Verbose error messages
- Missing security headers

### A06: Vulnerable and Outdated Components

**Risk:** Using components with known vulnerabilities.

**Checks:**
- [ ] All dependencies up to date
- [ ] Known vulnerabilities patched
- [ ] Only necessary dependencies included
- [ ] SBOM maintained
- [ ] License compliance verified

**Common Findings:**
- Outdated libraries with CVEs
- Unused dependencies
- Transitive vulnerabilities

### A07: Identification and Authentication Failures

**Risk:** Weak authentication allows attacker access.

**Checks:**
- [ ] Strong password policy enforced
- [ ] MFA supported/required
- [ ] Session management secure
- [ ] Brute force protection active
- [ ] Credential stuffing prevented

**Common Findings:**
- Weak password requirements
- No account lockout
- Session fixation vulnerabilities

### A08: Software and Data Integrity Failures

**Risk:** Code/infrastructure doesn't protect against integrity violations.

**Checks:**
- [ ] Code signing implemented
- [ ] CI/CD pipeline secured
- [ ] Dependencies verified (checksums)
- [ ] Update mechanism secure
- [ ] Deserialization attacks prevented

**Common Findings:**
- Unsigned code
- Insecure deserialization
- No integrity verification

### A09: Security Logging and Monitoring Failures

**Risk:** Breaches go undetected due to insufficient logging.

**Checks:**
- [ ] Security events logged
- [ ] Logs protected from tampering
- [ ] Alerting configured
- [ ] Incident response plan exists
- [ ] Log retention policy defined

**Common Findings:**
- No audit logging
- Insufficient log detail
- No alerting on suspicious activity

### A10: Server-Side Request Forgery (SSRF)

**Risk:** Application fetches remote resource without validating URL.

**Checks:**
- [ ] URL validation implemented
- [ ] Allowlists for external calls
- [ ] Network segmentation enforced
- [ ] Response validation applied
- [ ] Internal IP access blocked

**Common Findings:**
- Unvalidated URL parameters
- Access to internal services
- Cloud metadata access

## Audit Report Structure

### Executive Summary

**Purpose:** Non-technical stakeholder overview (1 page max)

**Contents:**
- Security posture (Secure/Conditional/At Risk)
- Key findings summary (critical/high only)
- Business impact assessment
- Recommended actions with timeline

**Template:**
```markdown
## Executive Summary

**Overall Security Posture:** [AT RISK | CONDITIONAL | SECURE]

**Key Findings:**
- [N] Critical vulnerabilities requiring immediate attention
- [N] High severity issues to address within 30 days
- [N] Medium/Low issues for backlog

**Business Impact:**
[Brief description of what these vulnerabilities mean for the business]

**Recommended Actions:**
1. [Priority 1 action] - Timeline: [timeframe]
2. [Priority 2 action] - Timeline: [timeframe]
```

### Findings Overview

**Purpose:** Technical summary of all vulnerabilities

**Format:**
```markdown
## Findings Summary

| Severity | Count | Status |
|----------|-------|--------|
| Critical | [N] | [N Open / N Remediated] |
| High | [N] | [N Open / N Remediated] |
| Medium | [N] | [N Open / N Remediated] |
| Low | [N] | [N Open / N Remediated] |
| Info | [N] | [N Open / N Remediated] |

**Total:** [N] findings across [N] categories
```

### Detailed Findings

**Purpose:** Technical details for each vulnerability

**Per-Finding Template:**
```markdown
### [VULN-001] [Title]

**Severity:** [Critical|High|Medium|Low|Info]
**CVSS Score:** [X.X] ([Vector String])
**CWE:** [CWE-XXX: Description]
**OWASP:** [A0X: Category]

**Description:**
[Technical description of the vulnerability]

**Location:**
- File: [path/to/file.ext:line]
- Component: [component name]
- Function: [function/method name]

**Impact:**
[What could an attacker do with this vulnerability?]

**Proof of Concept:**
```[language]
[Example exploit code or steps to reproduce]
```

**Remediation:**
[Specific steps to fix the vulnerability]

**References:**
- [CWE-XXX](https://cwe.mitre.org/data/definitions/XXX.html)
- [CVE-YYYY-XXXX](https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX) (if applicable)
```

### Risk Analysis

**Purpose:** Assess exploitability and business impact

**Template:**
```markdown
## Risk Analysis

### Attack Surface
[Description of exposed attack vectors]

### Exploitability Assessment
| Finding | Exploitability | Likelihood | Impact | Risk Score |
|---------|----------------|------------|--------|------------|
| VULN-001 | High | High | Critical | 9.5 |

### Business Impact
[Potential business consequences of exploitation]
```

### Remediation Roadmap

**Purpose:** Prioritized action plan

**Template:**
```markdown
## Remediation Recommendations

### Immediate (Critical/High - Within 7 Days)
1. **[VULN-001] [Title]**
   - Action: [Specific remediation steps]
   - Owner: [Team/Individual]
   - Effort: [Hours/Days]
   - Due: [Date]

### Short-term (Medium - Within 30 Days)
1. **[VULN-005] [Title]**
   - Action: [Specific remediation steps]
   - Owner: [Team/Individual]
   - Effort: [Hours/Days]
   - Due: [Date]

### Long-term (Low - Within 90 Days)
1. **[VULN-010] [Title]**
   - Action: [Specific remediation steps]
   - Owner: [Team/Individual]
   - Effort: [Hours/Days]
   - Due: [Date]

### Process Improvements
- [Recommendation to prevent similar issues in the future]
```

## Report Generation Process

### Phase 1: Data Collection

1. **Load scan results** from `docs/security/scan-results.json`
2. **Load triage results** from `docs/security/triage-results.json`
3. **Load patch files** from `docs/security/patches/` (if exist)

### Phase 2: Data Analysis

1. **Count findings by severity**
2. **Group findings by OWASP category**
3. **Calculate security posture** using formula
4. **Identify patterns** (common vulnerability types)

### Phase 3: Report Writing

1. **Executive Summary** - Business-focused overview
2. **Findings Summary** - Statistical overview
3. **OWASP Compliance** - Checklist with evidence
4. **Detailed Findings** - Technical deep-dive per vulnerability
5. **Risk Analysis** - Exploitability and impact assessment
6. **Remediation Roadmap** - Prioritized action plan

### Phase 4: Output Generation

1. **Write markdown** to `docs/security/audit-report.md`
2. **Validate structure** (all required sections present)
3. **Generate metadata** (report date, version, assessor)

## Quality Standards

### Report Must Include:
- [ ] Executive summary (non-technical)
- [ ] Overall security posture clearly stated
- [ ] All findings documented with severity
- [ ] OWASP Top 10 compliance status
- [ ] Remediation priorities with timelines
- [ ] Sign-off section for stakeholders

### Technical Accuracy:
- [ ] CVSS scores calculated correctly
- [ ] CWE mappings accurate
- [ ] OWASP categories correct
- [ ] Remediation steps specific and actionable

### Clarity:
- [ ] Executive summary understandable by non-technical readers
- [ ] Technical details sufficient for developers
- [ ] Recommendations actionable
- [ ] Timeline realistic

## Example Output Formats

### Markdown (Primary)
- Default output format
- Stored in `docs/security/audit-report.md`
- Version controlled with feature code

### HTML (Optional)
- Generated from markdown using Pandoc
- Enhanced with styling for stakeholder presentation
- Command: `/flow:security report --format html`

### PDF (Optional)
- Generated from HTML using wkhtmltopdf
- For audit compliance and archival
- Command: `/flow:security report --format pdf`

## Integration Points

### Input Sources:
- `docs/security/scan-results.json` - Raw scanner output
- `docs/security/triage-results.json` - AI-triaged findings
- `docs/security/patches/*.patch` - Generated fix patches
- `docs/prd/{feature-slug}-spec.md` - Feature context

### Output Artifacts:
- `docs/security/audit-report.md` - Primary report
- `docs/security/audit-report.html` - HTML export
- `docs/security/audit-report.pdf` - PDF export
- `docs/security/remediation-tasks.json` - Backlog task data

## Best Practices

1. **Be Specific** - Vague findings waste developer time
2. **Show Impact** - Connect vulnerabilities to business risk
3. **Provide Context** - Include code snippets and locations
4. **Suggest Fixes** - Don't just identify problems
5. **Track Progress** - Update report as issues are remediated
6. **Maintain History** - Version audit reports for compliance

## Common Pitfalls to Avoid

- **False Positives** - Verify findings before reporting
- **Severity Inflation** - Don't overstate risk for attention
- **Vague Remediation** - "Fix the bug" is not helpful
- **Missing Context** - Explain why it matters
- **Ignoring False Negatives** - Tools miss things, manual review matters