Repo Security Auditor
PassAudited by ClawScan on May 15, 2026.
Overview
This appears to be a legitimate repo-auditing helper, but it can download repositories, run local or external scanners, and its “safe” verdict should not be treated as a guarantee.
Use this skill if you are comfortable with it cloning the selected repo, writing local audit reports, and optionally contacting registry or scanner services. Prefer a sandbox or virtual environment, approve any package installs, verify which CLI accounts are active, and treat any PASS/FAIL result as a starting point for review rather than a final safety guarantee.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The skill can create a local clone and report files and may query package registries while scanning the selected project.
The script downloads a user-supplied repository and runs local scanning commands. This is central to the stated audit purpose, but it means the agent will perform network and tool actions against the selected repo.
git clone --depth 1 "$REPO_URL" repo ... npm audit --json 2>/dev/null > "$AUDIT_DIR/npm-audit.json" || true
Run it only on repositories you intend to audit, review shell-script execution first, and consider using a sandbox or temporary environment for untrusted code.
A runtime package install could change the user’s Python environment and depends on the integrity of the package source at the time it is run.
The instructions include installing an external Python security tool at scan time without a pinned version. This is purpose-aligned, but it still trusts the current package source and mutates the local environment.
pip install safety 2>/dev/null && safety check -r requirements.txt --json 2>/dev/null > safety-report.json
Install scanners in a virtual environment, pin trusted versions when possible, and ask for approval before installing new packages.
If the user has authenticated CLI tools configured, scans may run using those account privileges.
The workflow may invoke GitHub CLI API access if available, which can rely on the user’s existing GitHub authentication. This is expected for SBOM retrieval, but users should know their local account context may be used.
gh api repos/:owner/:repo/dependency-graph/sbom 2>/dev/null > sbom.json || echo "No SBOM available"
Confirm which account a CLI tool is using before running scans, especially on private repositories or organization-owned resources.
Private dependency names, versions, or project metadata could be sent to external services when those scanners run.
Dependency-audit tools commonly communicate package or dependency metadata to external registry/scanner services. That data flow is aligned with dependency scanning, but it matters for private repositories.
npm audit --json > "$OUTPUT_DIR/npm-audit.json" ... snyk test --json > "$OUTPUT_DIR/snyk-test.json"
Avoid running external scanners on sensitive private projects unless you accept the scanner provider’s data handling, or use offline/local-only tools where required.
A user might rely too heavily on a passing result and adopt third-party code that still needs manual security review.
The visible automation is mainly pattern matching and dependency-audit tooling, so a simple PASS/FAIL or “Safe to use” label could be over-read as stronger assurance than the artifacts support.
This skill performs comprehensive security audits ... produces a detailed security report with a PASS/FAIL verdict ... 0-3: Safe to use
Treat the report as triage, not a guarantee; manually review important findings and high-risk code paths before adopting or reimplementing a repository.