ai-security-harness

Use when the user asks for an executive summary, leadership roll-up, or cross-portfolio dashboard of security-audit findings — e.g. "summarise all findings", "how many criticals do we have", "credential leaks across the campaign", "findings by language", or "rebuild the executive summary". Aggregates every *security-audit.{json,md} report under analysis-results/ into a one-page Markdown brief and a self-contained HTML dashboard.

Use when the user asks to generate a shareable findings folder, executive summary, or team-specific security audit report for one or more products from the findings directory.

Use when the user asks to add one or more GitHub/GitLab repositories or an entire GitHub organization to the hybrid-platforms-inputs inventory. Adds entries to the appropriate segment CSV files and generates matching owners.csv rows.

Use when the user provides a previous secure-code-audit report and a patched version of the scanned repository, and asks to verify that findings have been resolved. Performs a targeted re-audit of each original finding against the patched code using the same frameworks, criteria, and evidence standards as the original secure-code-audit, then emits a structured verification report.

Triage a batch of raw security findings. Verify each is real, collapse duplicates, re-rank by derived exploitability, and tag with an owner. Takes a directory or file of scanner output and writes TRIAGE.json + TRIAGE.md sorted by what actually needs engineering attention. Use when asked to "triage findings", "validate scanner output", "prioritize vulns", or "review the backlog". Runs interactively by default; pass --auto to skip the interview.

Use when the user asks for pitch-deck metrics, funding/leadership talking points, a campaign scoreboard, or to (re)build/refresh progress-tracker/pitch-deck-metrics.md. Deterministically harvests headline numbers from the campaign's derived artifacts (executive summary, validation/fuzz dashboard, threat register, progress-tracker control files) and the harness's own tree/git metadata into one consistently-updatable Markdown scoreboard.

Use when the user wants to record human triage feedback or machine validation results against the findings of a *-security-audit report and produce a cumulative status report — ingesting merge-request comments, commits, Jira tickets, interactive human triage, live-validation reports, and remediation-verification reports into an append-only disposition layer, then generating a schema-conformant *-findings-current.{json,md} showing the current validity and resolution of every finding.

Run browser-based security validations (CSRF, XSS, clickjacking) against containerized labs using Playwright. Separate from validate-findings which targets K8s operators/containers.

Use when adding or editing a skill, script, schema, or pipeline stage in the ai-security-harness repo, or before committing any change to its docs — runs scripts/check_docs_consistency.py to verify the harness's own documentation (README.md, AGENTS.md, PROCESS.md, docs/) has not drifted from the tree. Checks that "N skills / N commands / N Python scripts / N-stage" count claims match the actual tree counts, that every repo-relative Markdown link and in-repo backtick path still resolves, and — when the gitlab-profile sibling is checked out — that the GitLab group README's harness-version and skill/command-count claims match too. Use when asked to "check the harness docs", "did I break the docs", "verify doc consistency", or "is anything stale after this change".

Generate candidate fixes for verified security findings. Consumes TRIAGE.json (preferred), a <repo>-security-audit.json report, *-vuln-findings.json (or legacy VULN-FINDINGS.json), or an external vuln-pipeline results directory. Pipeline input is delegated to the execution-verified `vuln-pipeline patch` ladder; static-analysis input gets a per-finding patch subagent + independent reviewer and is written as inert diffs for human review. Writes PATCHES/bug_NN/{patch.diff,patch_result.json}, PATCHES.md, and PATCHES.json. Use when asked to "fix the findings", "patch these vulns", "generate fixes", or "close the loop on triage".

Static source-code vulnerability scan. Reads a target directory (and its threat model — <repo>-threat-model.md, or legacy THREAT_MODEL.md — if present), spawns parallel review subagents per focus area, and writes <repo>-vuln-findings.{json,md} with campaign finding IDs ({REPO_SLUG}-{SHORTSHA}-{NNN}) and the shared severity enum, for /triage to consume. When a <repo>-security-audit.json baseline exists, the scan supplements it: known findings are deduped against the baseline and new verified findings flow back into it via triage and the disposition ledger — /secure-code-audit remains the preferred baseline and /verify-remediation the way to update it after fixes. Read-only — no building, running, or network. Use when asked to "scan for vulns", "review this code for security issues", "find bugs in <dir>", "re-sweep an audited repo", or as the step between /threat-model and /triage.

Build and maintain a threat model for a target codebase. Six modes: "interview" walks an application owner through the four-question framework; "bootstrap" derives a model from code plus past vulnerabilities (CVEs, git history, pentest reports, --context docs) when no owner is available; "bootstrap-then-interview" chains the two; "review" measures an existing threat model's drift against the current code and offers to apply fixes; "update" applies targeted feedback without regenerating; "pr" threat-models a diff and returns an approve/request-changes assessment. Output is always named after the target (<repo>-threat-model.md); legacy THREAT_MODEL.md files are still read and are migrated on write. Emissions share one schema gated by lint_threat_model.py. Use when asked to "threat model", "map the attack surface", "is the threat model still current", "threat model this MR/PR/diff", or "what should we be worried about in this codebase".

Use when the user asks for a fleet-wide or portfolio-wide view of threats (not findings) — "how many unmitigated critical threats do we have", "threat register", "which products carry the most open threat exposure", "what class-closing mitigations would pay off fleet-wide" — or asks to (re)build the threat register. Deterministically aggregates every *-threat-model.md (and legacy THREAT_MODEL.md) under analysis-results into threat-register/threat-register.{json,md,html}, keyed by the stable compound key <model-slug>:<Tn>.

Use when the user asks to install, deploy, or stand up an OLM operator (or a logical product from VALIDATION-PRIORITY-LIST.md) onto an OpenShift/Kubernetes cluster AND bring its operand to a Ready state — resolving the OLM package, creating the Subscription, waiting for CSV Succeeded, then reading the operator's documentation/samples to discover operand prerequisites, creating dummy Secrets/ConfigMaps to satisfy them, applying the operand CR, iterating on its status conditions until Ready, and recording every dummy credential in credentials-needed.json for a later real-credential pass.

Use when the user asks to write, scaffold, run, or extend a Go-native fuzz harness for a parser/decoder/templater identified in a security-audit report — adding a target to targets.json, authoring a *_fuzz_test.go dropped into the audited repo's package, driving `make clone install build fuzz-<id>`, and triaging any crashers into follow-up findings. Offline only: no cluster, cloud creds, or service mocks.

Build or refresh the Hybrid Platforms portfolio repository graph. Reads hybrid-platforms-inputs/{openshift,operator-catalog,services} CSV inventories (ansible/ excluded by default), cross-references every repo against analysis-results/findings/ coverage (audit/triage/threat-model + severity), and emits repo-graph.{json,dot,gexf,html} + repo-graph-stats.md into analysis-results/graph/. Use when asked to "build the repo graph", "update the portfolio graph", "map repos to findings", "which repos have no coverage", or "what ships kube-rbac-proxy".

Use when the user asks to live-validate, reproduce, or red-team security findings for a CORE OpenShift payload component (a ClusterOperator such as console, ingress, monitoring, kube-apiserver, etcd) against a pre-provisioned isolated lab cluster — resolving the CO's namespaces and payload repos, generating a per-CO explicit-namespace targets.yaml from blast_radius.yaml, and running the validate-findings engine. NO cluster provisioning, NO OLM install, NO teardown — the component already runs in the payload. One invocation == one ClusterOperator on one long-lived lab cluster.

Review and sign off pending human decisions in the findings disposition ledger — machine-refuted false positives awaiting an LDAP-verified countersignature, and queued needs-review items. Renders each pending decision as a self-contained card (claim + refutation + evidence) so nothing needs to be remembered from the original reports, records decisions through the countersign workbench, and rebuilds the cumulative reports. Use when asked to "countersign findings", "sign off false positives", "review pending refutations", "what's waiting for my signature", or "clear the disposition queue".

Use when the user wants to file a Jira ticket for a security vulnerability found in an audit report — populating the defect from the audit finding with full description, affected code, and remediation, and setting the Security Level to Embargoed Security Issue.

Use when the user asks whether portfolio security findings are trending up or down, wants a burndown, remediation velocity, MTTR, risk-index, or accepted-risk trend, or asks to (re)build the findings-trends dashboard — e.g. "are we getting better", "findings over time", "how fast are we remediating", "what risk have we accepted". Replays every repo's track-findings disposition ledger against time buckets and emits findings-trends.{json,md,html} with direction arrows per metric.

Use when the user asks to perform a security audit, security review, vulnerability assessment, or code analysis of a GitHub repository, operator, or batch of repositories using OWASP ASVS, OWASP Kubernetes Top 10, CIS Kubernetes Benchmark, DISA STIG, SLSA, OpenSSF Scorecard, or PEACH tenant-isolation frameworks.

Use when the user asks to perform a security audit, security review, or vulnerability assessment of an RPM packaging repository (CentOS Stream / Fedora / RHEL dist-git) — a repo containing a .spec file, downstream patches, and a sources lookaside manifest — using OWASP ASVS, the SEI CERT C/C++ Coding Standards, Fedora Packaging Guidelines, SLSA, and OpenSSF Scorecard.

Use when the user asks to validate, reproduce, exploit, red-team, or live-test security findings against a Kubernetes/OpenShift cluster, operator, WASM module, container, pod, or cluster component. Ingests *-security-audit, *-threat-model, and *-triage reports, builds an attack plan (replay + chained + novel), executes it against an authorized live target under a hard scope guard, and emits a schema-validated *-validation.{json,md} report.

Use when the user asks which insecure coding patterns recur across the portfolio, wants findings grouped/ranked by CWE or OWASP ASVS category, asks "what are our top vulnerabilities by pattern", "which repos share CWE-X", or asks to (re)build the insecure-patterns dashboard. Walks every *-security-audit.json under analysis-results/findings/, keeps only source-code findings (drops YAML/Dockerfile/Helm config gaps), buckets by primary CWE mapped to ASVS 5.0, and writes insecure-patterns/{top25.md, detailed.md, dashboard.html, .json}.

Use when the user asks for a live-validation dashboard, fuzzing-results dashboard, validation coverage roll-up, or "how many findings were confirmed exploitable / refuted" — e.g. "build the validation dashboard", "combine validation and fuzz results", "what did live validation confirm", "validation false-positive rate". Aggregates every validations/*/*validation*.json report plus FUZZ-CAMPAIGN-SUMMARY.md into one self-contained HTML dashboard.

Use when the user asks to re-route, reassign, or change the owners for one or more findings packages in progress-tracker/processed-results/. Validates new owners as active Red Hat employees via LDAP, updates all local control files, updates Google Drive folder permissions via the gws CLI, and updates the Glasswing Ownership Tracker Google Doc.

Multi-phase, human-in-the-loop security code audit — Phase 1 reconnaissance, Phase 2 prior-vuln pattern analysis, Phase 3 systematic CWE-taxonomy weakness hunt (including PEACH tenant isolation), Phase 4 cross-cutting analysis and final report, Phase 6 reproducer generation, plus review/CVSS/follow-up-seed helpers. Each phase is a separate slash command that reads the previous phase's JSON and writes its own.

Use when the user asks to remediate, patch, fix, or produce a code fix for a security finding from the audit campaign — creating a minimal reviewable patch on a private fork, running the repo's own build/test suite, and emitting a schema-validated remediation report.

Use when the user asks how many lines of code have been scanned/audited, wants a LoC breakdown by language or repo across the security-audit campaign, or asks to (re)build the LoC dashboard. Produces gh-languages-cache.jsonl and a self-contained loc-dashboard.html from the campaign manifests.

Use when the user asks to determine, assign, or verify owners for one or more result directories in progress-tracker/processed-results/. Identifies two lead developers per findings package using owners.csv mappings, org repo team structures, OpenShift CI OWNERS files, LDAP employee verification, and git commit email resolution.

Use when the user asks to live-validate, end-to-end test, or run the validation campaign for a logical product/operator from VALIDATION-PRIORITY-LIST.md against an ephemeral ROSA HCP cluster — provisioning the cluster via bonfire, installing the operator via the deploy-operator skill, generating a lab-environment targets.yaml, running the validate-findings skill with --auto --destructive, and releasing the cluster. One invocation == one cluster == one logical product.

Use when the user asks to list, discover, inventory, or extract the repositories for an OpenShift release payload, an OLM operator catalog product, or a managed service (e.g. OCM, Insights, Hive, ACS, Backplane, GCP-HCP). Produces CSV and Markdown repository inventories plus an owners.csv mapping each repo to its owning team and individual maintainers.