with one click
scrutineer
scrutineer contains 22 collected skills from alexandre-daubois, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
Identify the real maintainers of a repository and the best way to contact them about a security issue. Distinguishes active leads from occasional contributors and bots, using commit history, issue activity, and registry ownership. Use when preparing a disclosure and needing to know who to reach.
Index dependencies reported by git-pkgs for the repository's manifest and lockfile files (package.json, Gemfile, go.mod, requirements.txt, etc.) and record each one with its manifest path, ecosystem, and requirement string. Use to populate the Dependencies tab.
Check whether known sinks in this application's dependencies are reachable from its own trust boundaries. Scrutineer already holds findings against the libraries this app uses; this skill traces each one from the app's entry points to the library call and reports the ones an attacker can reach. Use on applications (Gemfile.lock / package-lock.json present), not on libraries.
Generate a CycloneDX Software Bill of Materials for the repository. Use when you want a standard-format inventory of components for downstream tooling, compliance, or archival. Stored verbatim on the scan.
Fetch the published security advisories that affect any package produced by this repository. Use to populate the Advisories tab with existing GHSA and CVE records so analysts can see what is already public before triaging new findings.
For each published package of this repository, fetch the top runtime dependents so later exposure-analysis skills have a ranked shortlist to work against. Use after the packages skill has populated which packages exist.
For one (finding, dependent) pair, decide whether the dependent's published code actually reaches the upstream library finding. Emit one CSAF 2.0 product_status verdict so scrutineer can record affected vs not_affected and stamp the right VEX justification.
Fork the scanned repository into the configured GitHub organisation, enable private vulnerability reporting on the fork, record the scan as a git note, and file each finding as a draft security advisory on the fork with a relevant org team invited as collaborator. Run after a scan has produced findings; the fork is the staging area for disclosure work.
Fetch high-level repository metadata (description, default branch, languages, license, stars, forks, archived status, icon) and save it against the scan's repository row. Use as the first scan on a new repository or to refresh after upstream changes.
Look up every published package that corresponds to a repository, across all registries, and record download counts, dependent counts, latest version, and registry URL. Use to populate the Packages tab.
File a finding on the upstream repository through GitHub's private vulnerability reporting, request the temporary private fork, and push the proposed patch to it when available. Use after disclose has produced a draft and (optionally) patch has produced a gated diff. This is the step that crosses the line to the maintainer; everything before it is internal.
Run semgrep static analysis with the security-audit and secrets rulesets, then map each hit into scrutineer's findings shape so it surfaces alongside model-driven audits. Use as a fast deterministic pass before or alongside deeper skills.
Audit the repository's GitHub Actions workflows for common security issues (credential mishandling, untrusted inputs, template injection, overly permissive tokens) and convert findings to scrutineer's shape. Use on any repo with a .github/workflows directory.
Audit first-party source for security vulnerabilities using an inventory-first, six-step per-sink methodology. Use when you want a thorough scan that distinguishes real findings from pattern matches and records both in a machine-readable report. The target is this codebase's own code, not its dependencies.
Draft the disclosure content for a finding in GitHub Security Advisory shape. Produces a title, markdown description, affected package block, CVSS vector, CWE list, and references, then writes them back to the finding so the analyst can paste them into the GHSA form (or POST to GitHub's repository-advisories REST endpoint) rather than composing from scratch.
Derive a project's security contract from its source and docs, then emit it as structured data other skills can cite. Records what the project assumes about callers and inputs, what properties it claims and disclaims, which code is out of scope, and which recurring tool findings are known-safe. This is not a vulnerability scan; it produces the trust map that security-deep-dive loads instead of re-deriving boundaries per run.
Default pipeline scrutineer runs when a repository is added. Triggers a standard set of other skills in parallel, then writes a short summary of what was enqueued. Edit the list below to change the default scan coverage without touching scrutineer's Go code.
Produce a structured plain-language overview of what a repository does, who maintains it, its activity level, and the shape of its codebase. Use when you want a quick orientation before deeper analysis.
Determine which CVE Numbering Authority (if any) covers this repository, so disclosures can be routed to the CNA's security contact rather than only the maintainer. Reads scrutineer's cached CNA list and matches the repo's owner, project name, and published packages against each CNA's published scope.
Propose a code patch for a finding. Produces a unified diff against the current HEAD plus a short rationale, written back as a finding note so the analyst can review, adjust, and open a PR themselves. The skill never pushes to the remote.
Assess a repository's security posture and its readiness to receive a vulnerability report. Checks for a security policy, private vulnerability reporting, security.txt, prior advisories, scanning workflows, and other hygiene signals, then rates the project ready / partial / unprepared. Use before disclosure to decide how much hand-holding the maintainer will need, or as a standalone health check.
Independently verify a specific finding by re-running its reproduction against the current repository state. Records whether the finding still reproduces, was fixed upstream, or could not be reproduced. Use on a finding before investing analyst time in disclosure.