security-snapshot
Automates security analysis and trend tracking dashboard generation.
Install
mkdir -p .claude/skills/security-snapshot && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17388" && unzip -o skill.zip -d .claude/skills/security-snapshot && rm skill.zipInstalls to .claude/skills/security-snapshot
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Run the full security analysis pipeline — AWS Inspector V2 + GitHub security alerts → correlation → dashboard. Saves dated snapshots for trend tracking. Run monthly or on demand. Optional --deploy flag pushes the dashboard to Google Apps Script at the end.Key capabilities
- →Collect security findings from AWS Inspector V2
- →Collect security findings from GitHub security alerts
- →Correlate findings from AWS and GitHub
- →Generate an interactive security dashboard
- →Save dated snapshots for trend tracking
- →Optionally deploy the dashboard to Google Apps Script
How it works
The skill collects security data from AWS Inspector V2 and GitHub, correlates the findings, and then generates an interactive dashboard, saving dated snapshots for historical trend tracking.
Inputs & outputs
When to use security-snapshot
- →Run monthly security scan
- →Generate security dashboard
- →Correlate security alerts
About this skill
Security Snapshot
Model Selection
See .claude/skills/_shared/MODEL_SELECTION.md (in your workspace) for full policy.
- Default model: Haiku — the pipeline is four scripts run in sequence with pass/fail gates; the scripts do the work
- Promote to Sonnet when: first-run configuration (prompting and validating org/profile/region), diagnosing a failed step, or interpreting an unusual delta
- Promote to Opus when: never
You are running the security analysis pipeline. This collects data from AWS Inspector V2 and GitHub, correlates findings, and regenerates the interactive dashboard.
Outputs land in per-date subfolders under $REPORTS_DIR/<YYYYMMDD>/. Running more than once on
the same day overwrites that folder's contents. Running on a new day creates a new dated folder
while preserving all previous ones. Always-current files (rendered dashboard, clasp deploy state)
sit at the top of $REPORTS_DIR/.
Past dated folders are immutable history. Correlation outputs co-locate with their inputs and refuse to save when the latest inputs are from a previous day (run the collectors first — analysis never refreshes a past folder, and never creates a dated folder with no collection behind it). Rebuilding the dashboard against an older correlation reuses that day's existing snapshot untouched.
Do NOT run build_dashboard.py before the other three scripts complete — it depends on their output.
Adapting this skill to a different workspace
All org-specific values live in scripts/config.local.json (gitignored; it overlays the committed scripts/config.json template, local keys winning): github_org, aws_profile, aws_region (required — Step 0 prompts for them when missing), plus owner_project / default_scope (where snapshots and the dashboard land — point both at a project slug that exists in your workspace, check ls projects/; both normally hold the same value). config.json itself stays a value-free template so /setup-workspace sync can refresh it without touching your settings.
You'll know if a value is wrong on first run: every script errors with a clear message naming the missing or invalid setting. There is no silent misrouting — wrong values fail fast.
Setup — resolve SCRIPT_DIR and REPORTS_DIR (do this first, reuse throughout)
The pipeline source lives in this skill folder; output goes under
artifacts/security-snapshot/ in the scope resolved from --scope (default from config.json).
Resolve both once:
# Locate workspace from this skill's base directory (never from PWD — cwd
# drifts mid-session). Base dir is <workspace>/.claude/skills/security-snapshot/;
# the workspace is three levels up, validated by its marker file.
WS="$(cd "<skill-base-dir>/../../.." && pwd)"
[ ! -f "$WS/.claude/.workspace" ] && { echo "Workspace marker not found at $WS"; exit 1; }
SCRIPT_DIR="$WS/.claude/skills/security-snapshot/scripts"
# Resolve scope via the shared loader (config.json overlaid by config.local.json) unless --scope was passed
SCOPE="$(python3 -c "import sys; sys.path.insert(0,'$SCRIPT_DIR'); from config_util import load_config; print(load_config()['default_scope'])")"
# (apply user's --scope override here if invoked with one)
if [ "$SCOPE" = "workspace" ]; then
REPORTS_DIR="$WS/artifacts/security-snapshot"
else
REPORTS_DIR="$WS/projects/$SCOPE/artifacts/security-snapshot"
fi
mkdir -p "$REPORTS_DIR"
export SECURITY_SNAPSHOT_REPORTS_DIR="$REPORTS_DIR"
Use "$SCRIPT_DIR" for script invocations and "$REPORTS_DIR" for output paths (status
messages, the "Next step" line, the deploy invocation). Do NOT hardcode absolute paths.
Alternative for one-shot use: bash "$SCRIPT_DIR/run_analysis.sh" [--scope <name>] does
all of the above plus runs the pipeline end-to-end.
Step 0 — First-run configuration
Config loads in two layers: config.json is the committed template (defaults + docs,
no real values); config.local.json is gitignored and overlays it with this deployment's
real values (local keys win). This split is what lets /setup-workspace sync refresh
config.json without ever clobbering your settings — so always write real values to
config.local.json, never to config.json.
Read the effective config (the scripts merge both layers). Three values are required:
github_org, aws_profile, aws_region. If any is empty or missing, this is a first run —
prompt the user for them:
- github_org — the GitHub organization to scan (all repos are enumerated)
- aws_profile — an AWS profile with Inspector2 + STS read access (read-only recommended)
- aws_region — the region where Inspector V2 runs
Also offer the optional values while you're there: owner_project / default_scope (where
outputs land — a project slug or workspace), dashboard_title (defaults to
"Security Dashboard"), and annotations (event markers on the Trend tab — fine to leave empty).
Validate before saving: gh api orgs/<org> --jq .login resolves, and
aws sts get-caller-identity --profile <profile> succeeds. Write the confirmed values to
$SCRIPT_DIR/config.local.json (create it if absent — a flat JSON object of just the keys
you're setting; the rest fall through to the template). The Python scripts and
run_analysis.sh both fail fast with a clear message if a required value is missing, so a
skipped Step 0 cannot silently misroute — but prompting here beats a mid-pipeline error.
If all three values already resolve, skip silently.
Step 1 — Prerequisite check
The skill installs what it can; only authentication is delegated to the user.
Read aws_profile via the shared loader (config.json overlaid by config.local.json), then run in parallel:
AWS_PROFILE="$(python3 -c "import sys; sys.path.insert(0,'$SCRIPT_DIR'); from config_util import load_config; print(load_config()['aws_profile'])")"
python3 -c "import boto3; print('boto3 ok')"
gh auth status
aws sts get-caller-identity --profile "$AWS_PROFILE"
Evaluate results:
- boto3 missing → install it directly:
pip3 install boto3 --break-system-packages. Re-check after install. - aws CLI missing → install it directly (macOS:
brew install awscli; Linux: the platform package manager). Re-check after install. - gh CLI missing → install it directly (macOS:
brew install gh). Re-check after install. - gh not authenticated or wrong account → genuinely interactive. Tell the user to run
! gh auth login(or! gh auth switch --user <their-github-handle>if they have multiple accounts) in the prompt, then re-check. - AWS profile fails → credentials are the user's to fix: the profile may be missing from
~/.aws/configor its credentials expired. Show the exact error and wait — do not create or modify AWS profiles yourself.
If any check still fails after these remedies, stop here. Do not proceed with stale or missing auth.
Step 2 — Inspector V2 snapshot (~3 min)
python3 "$SCRIPT_DIR/posture_snapshot.py" --save --raw
Each python script reads $SECURITY_SNAPSHOT_REPORTS_DIR to know where to write. If the
env var isn't set in your shell, pass --reports-dir "$REPORTS_DIR" explicitly.
Watch for errors. If it exits non-zero, show the last 20 lines of output and stop.
Step 3 — GitHub security snapshot (~2 min)
python3 "$SCRIPT_DIR/github_security_snapshot.py" --save --raw
Watch for errors. If it exits non-zero, show the last 20 lines of output and stop.
Step 4 — Correlation analysis (~5 sec)
python3 "$SCRIPT_DIR/correlation.py" --save --raw
Reads the latest raw-YYYYMMDD.json and github-raw-YYYYMMDD.json from $REPORTS_DIR,
writes correlation-YYYYMMDD.{md,json} back to the same dir.
Step 5 — Build dashboard (~1 sec)
python3 "$SCRIPT_DIR/build_dashboard.py"
Also writes $REPORTS_DIR/<YYYYMMDD>/snapshot.json — a slim per-day archive (~23KB) that
the dashboard embeds for its date picker, and that Step 6 reads to compute the delta vs the
previous run. The rendered security-dashboard.html always lands at the top of $REPORTS_DIR/.
Step 6 — Delta comparison
Load the two most recent <YYYYMMDD>/snapshot.json files from $REPORTS_DIR
(globbing $REPORTS_DIR/*/snapshot.json, sorted by folder name descending).
Compare these metrics between previous and current:
| Metric | Direction | Meaning |
|---|---|---|
github.secrets_total | ↓ good, ↑ bad | Open credential exposures |
github.vuln_critical | ↓ good | Critical Dependabot alerts |
github.vuln_total | ↓ good | Total Dependabot alerts |
github.code_total | ↓ good | Code scanning errors |
inspector.critical + inspector.high | ↓ good | Inspector C+H (fan-out inflated) |
correlation.zone_a_pkgs | ↓ good | Packages confirmed in both sources |
If only one snapshot exists (first run): note "First run — no previous snapshot to compare."
Present as a compact delta table:
Delta vs YYYY-MM-DD
───────────────────────────────
Secrets 148 → 148 (no change)
GH CRITICAL 191 → 185 ↓ 6
GH total 3,077 → 3,020 ↓ 57
Code scanning 470 → 470 (no change)
Inspector C+H 715K → 715K (no change)
Zone A pkgs 203 → 198 ↓ 5
Step 7 — Report
Print a final summary using "$REPORTS_DIR" for any paths:
Security Snapshot — YYYY-MM-DD
==============================
Scope: <name>
Outputs at: $REPORTS_DIR/YYYYMMDD/
Inspector V2: ✓ posture.md + raw.json
GitHub: ✓ github.md + github-raw.json
Correlation: ✓ correlation.md + correlation.json
Dashboard: ✓ security-dashboard.html (N snapshots embedded, top-level)
[delta table]
Dashboard: open $REPORTS_DIR/security-dashboard.html
Next step: /google-script-deploy deploy "$REPORTS_DIR"
(or pass --deploy to /security-snapshot next time to do it automatically)
Report the count of snapshots embedded in the dashboard (from build_dashbo
Content truncated.
When not to use it
- →When only a local dashboard is needed and deployment to Apps Script is not desired
- →When `build_dashboard.py` needs to be run before other scripts complete
- →When the dashboard access level is `ANYONE_ANONYMOUS`
Limitations
- →The dashboard is sensitive and its deploy access must be `DOMAIN` or stricter, never `ANYONE_ANONYMOUS`
- →Past dated folders are immutable history and analysis never refreshes them
- →The skill stops and reports failure if any step fails
How it compares
This skill automates the entire security analysis pipeline, including data collection, correlation, and dashboard generation with historical snapshots, which is more efficient than manually gathering and combining data from disparate source
Compared to similar skills
security-snapshot side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| security-snapshot (this skill) | 0 | 1mo | Review | Intermediate |
| building-vulnerability-aging-and-sla-tracking | 0 | 2mo | No flags | Advanced |
| senior-security | 31 | 7mo | Review | Advanced |
| fix-security-vulnerability | 7 | 1mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
building-vulnerability-aging-and-sla-tracking
MustafaKemal0146
Implement a vulnerability aging dashboard and SLA tracking system to measure remediation performance against severity-based timelines and drive accountability.
senior-security
davila7
Comprehensive security engineering skill for application security, penetration testing, security architecture, and compliance auditing. Includes security assessment tools, threat modeling, crypto implementation, and security automation. Use when designing security architecture, conducting penetration tests, implementing cryptography, or performing security audits.
fix-security-vulnerability
getsentry
Analyze and propose fixes for Dependabot security alerts
codebase-cleanup-deps-audit
sickn33
You are a dependency security expert specializing in vulnerability scanning, license compliance, and supply chain security. Analyze project dependencies for known vulnerabilities, licensing issues, outdated packages, and provide actionable remediation strategies.
dependency-auditor
alirezarezvani
Check dependencies for known vulnerabilities using npm audit, pip-audit, etc. Use when package.json or requirements.txt changes, or before deployments. Alerts on vulnerable dependencies. Triggers on dependency file changes, deployment prep, security mentions.
security-scanning-security-dependencies
sickn33
You are a security expert specializing in dependency vulnerability analysis, SBOM generation, and supply chain security. Scan project dependencies across ecosystems to identify vulnerabilities, assess risks, and recommend remediation.