ghost-report
Ghost Security — combined security report. Aggregates findings from all scan skills (scan-deps, scan-secrets, scan-code) into a single prioritized report focused on the highest risk, highest confidence issues. Use when the user requests a security overview, vulnerability summary, full security audit, or combined scan results.
Packaged view
This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.
Install command
npx @skill-hub/cli install ghostsecurity-skills-report
Repository
Skill path: plugins/ghost/skills/report
Ghost Security — combined security report. Aggregates findings from all scan skills (scan-deps, scan-secrets, scan-code) into a single prioritized report focused on the highest risk, highest confidence issues. Use when the user requests a security overview, vulnerability summary, full security audit, or combined scan results.
Open repositoryBest for
Primary workflow: Run DevOps.
Technical facets: Full Stack, Security.
Target audience: everyone.
License: apache-2.0.
Original source
Catalog source: SkillHub Club.
Repository owner: ghostsecurity.
This is still a mirrored public skill entry. Review the repository before installing into production workflows.
What it helps with
- Install ghost-report into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
- Review https://github.com/ghostsecurity/skills before adding ghost-report to shared team environments
- Use ghost-report for development workflows
Works across
Favorites: 0.
Sub-skills: 0.
Aggregator: No.
Original source / Raw SKILL.md
---
name: "ghost-report"
description: "Ghost Security — combined security report. Aggregates findings from all scan skills (scan-deps, scan-secrets, scan-code) into a single prioritized report focused on the highest risk, highest confidence issues. Use when the user requests a security overview, vulnerability summary, full security audit, or combined scan results."
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
license: apache-2.0
metadata:
version: 1.1.0
---
# Combined Security Report
You aggregate findings from all scan skills (scan-deps, scan-secrets, scan-code) into a single prioritized report. Do all work yourself — do not spawn subagents or delegate.
$ARGUMENTS
---
## Step 0: Setup
Run this Bash command to compute paths:
```bash
repo_name=$(basename "$(pwd)") && remote_url=$(git remote get-url origin 2>/dev/null || pwd) && short_hash=$(printf '%s' "$remote_url" | git hash-object --stdin | cut -c1-8) && repo_id="${repo_name}-${short_hash}" && short_sha=$(git rev-parse --short HEAD 2>/dev/null || date +%Y%m%d) && ghost_repo_dir="$HOME/.ghost/repos/${repo_id}" && scans_dir="${ghost_repo_dir}/scans/${short_sha}" && cache_dir="${ghost_repo_dir}/cache" && skill_dir=$(find . -path '*/skills/report/SKILL.md' 2>/dev/null | head -1 | xargs dirname) && echo "scans_dir=$scans_dir cache_dir=$cache_dir skill_dir=$skill_dir"
```
Store `scans_dir` (commit-level scan directory), `cache_dir`, and `skill_dir`.
---
## Cache Check
If `<scans_dir>/report.md` already exists, show:
```
Combined security report is at: <scans_dir>/report.md
```
And stop. Do not regenerate it.
---
## Step 1: Read Repo Context
Read `<cache_dir>/repo.md` if it exists. Extract:
- Business criticality
- Sensitive data types
- Component map
If it does not exist, continue without it — this is not an error.
---
## Step 2: Discover Scan Results
List the contents of `<scans_dir>` to see which scan-type directories exist. Recognized types:
- `deps/` — SCA / dependency vulnerability scan
- `secrets/` — secrets and credentials scan
- `code/` — code security scan (SAST)
If none of these directories exist, report an error:
```
No scan results found in <scans_dir>. Run one or more scan skills first:
/ghost-scan-deps
/ghost-scan-secrets
/ghost-scan-code
```
And stop.
---
## Step 3: Collect Findings
For each scan type that exists, glob `<scans_dir>/<type>/findings/*.md` and read each finding file **in full**. Retain the complete markdown body of every finding — the report will inline this content directly so readers never need to open individual finding files.
From each finding, also extract these metadata fields for filtering and sorting:
- **ID** — from `## Metadata` → `ID`
- **Type** — the scan type (`deps`, `secrets`, or `code`)
- **Severity** — from `## Metadata` → `Severity` (high, medium, low)
- **Status** — from `## Metadata` → `Status` (e.g., confirmed-exploitable, unverified, verified, rejected, clean)
---
## Step 4: Filter and Sort
**Filter:** Keep only high-confidence findings:
- For `deps` findings: status is `confirmed-exploitable`
- For `secrets` findings: status is NOT `clean` and NOT `rejected`
- For `code` findings: status is `verified` or `unverified` (NOT `rejected`)
**Exclude** any finding with status `clean`, `rejected`, or `false-positive`.
**Sort** the remaining findings:
1. By severity: high first, then medium, then low
2. Within same severity: deps before secrets before code
---
## Step 5: Read Per-Scan Reports
For `deps` and `secrets` scan types, read `<scans_dir>/<type>/report.md` if present. Extract:
- Statistics (candidates scanned, confirmed findings, false positives filtered)
- Executive summary highlights
Note: `code` does not produce a `report.md`. For code scan coverage, count the finding files in `<scans_dir>/code/findings/` directly. The "Candidates Scanned" count is the total number of finding files (all statuses). "Confirmed Findings" is the count with status `verified`, `confirmed`, or `unverified`. "False Positives Filtered" is the count with status `rejected`. Do NOT count clean file analyses from the nomination/analysis funnel — those never became findings.
If a per-scan report does not exist for deps or secrets, note it as unavailable.
---
## Step 6: Generate Report
1. Read `<skill_dir>/report-template.md`
2. Populate the template with collected data:
- Fill Scan Information with repository name, commit SHA, date, and which scans ran
- Write Executive Summary using repo context and aggregated findings
- For all writing elements in this security-focused, objective and fact based report, use a neutral, human tone that balances expertise with ease of reading. Do not use emojis, em-dashes, etc.
- For Critical & High findings (severity = high): inline the substantive content from each finding file directly into the report — include code snippets, assessment tables, remediation commands, and all relevant detail so the report is fully self-contained
- For Medium findings: write a full subsection per finding with description, location, code context, and remediation (not a condensed table)
- Omit low-severity findings (they remain in per-scan finding files only)
- Fill Scan Coverage table from per-scan report statistics (for code, use finding file counts from Step 5)
- Add a brief methodology note per scan type that ran (1-2 sentences drawn from per-scan reports)
- Do NOT include links to per-scan reports or individual finding files — all content is inlined
3. Write the report to `<scans_dir>/report.md`
---
## Step 7: Show Output
```
Combined security report is at: <scans_dir>/report.md
```