SKILL.md

name: auditing-repositories description: Audits open source repositories for security, privacy, and unexpected behavior. Use when asked to audit, review, or assess a repo or codebase for vulnerabilities, privacy or telemetry concerns, suspicious behavior, dependency or supply chain risk, or OSS due diligence. license: GPL-3.0-or-later metadata: author: Amolith amolith@secluded.site

Be objective and evidence-based — acknowledge what's well-designed, and don't invent issues to appear thorough. Each finding needs a source→sink path, unsafe default, or concrete misconfiguration as evidence.

Guardrails

  • Prefer static inspection. Don't execute untrusted artifacts. If running anything (linters, npm audit, cargo audit), document exactly what and why.
  • Avoid speculative findings. Each issue needs concrete evidence, not hypotheticals.

Workflow

  1. Understand the project: Read README, docs, and config to learn what the software claims to do
  2. Identify the stack: Languages, frameworks, build systems, deployment targets
  3. Map attack surface: Locate entry points and trust boundaries — CLI args, HTTP routes, RPC handlers, webhooks, config/env, file format parsers, plugins, deserialization
  4. Analyze systematically: Work through each analysis area below, starting with highest risk
  5. Check dependencies: Review dependency manifests for known vulnerabilities and supply chain risk
  6. Review build and release pipeline: Install scripts, CI workflows, build-time downloads, release signing
  7. LLM-specific checks: If the project involves LLMs, AI assistants, or MCP servers, DO NOT FORGET to apply references/llm-security.md
  8. Write the report: Use the output format below; rate each finding

Assess from both an external attacker and malicious insider perspective. Focus on practical, realistic threats — not theoretical edge cases requiring unrealistic exploitation scenarios.

Analysis Areas

Correctness / Unexpected Behavior

  • Does the software function as described? Any undocumented behaviors?
  • Verify claims in README/docs against actual implementation

Security

  • Authentication/authorization weaknesses
  • Input validation and injection (SQL, command, XSS, CSRF, SSRF, path traversal)
  • Insecure cryptographic implementations or misuse
  • Unsafe deserialization (YAML, JSON, pickle), archive extraction (zip-slip), template engines
  • Race conditions and concurrency issues
  • Hardcoded credentials or secrets
  • Insecure default configurations
  • Memory safety concerns (C/C++/Rust unsafe blocks): bounds checks, use-after-free, unsafe FFI

Privacy

  • What data is collected, how it's stored, and where it's sent
  • Data retention policies and third-party sharing
  • Tracking mechanisms: cookies, persistent identifiers, telemetry, analytics SDKs
  • Whether data collection is disclosed to users and proportionate to functionality

Network Communications

  • All endpoints contacted during operation
  • Authentication and encryption of connections
  • Types of data transmitted; interception risk
  • Whether each communication is necessary for core functionality
  • Unexpected or suspicious outbound connections

Permissions and Sandboxing

  • System permissions requested (filesystem, network, hardware)
  • Whether permissions align with stated functionality
  • API scopes and integration breadth
  • Running as root, setuid, container escape potential
  • Background services, startup hooks, file permission modes
  • Temp directory safety, symlink attacks

Code Quality (Security-Relevant)

  • Error handling: fail-open vs fail-closed
  • Logging of sensitive data; secret leakage in logs or crash dumps
  • Debug endpoints exposing config or secrets
  • Input sanitization at boundaries
  • Secure coding patterns (or lack thereof)

Dependencies

  • Known vulnerabilities in direct and transitive dependencies
  • Supply chain risks (unmaintained, single-maintainer, typosquat)
  • Unnecessary dependencies increasing attack surface
  • Dependency pinning and verification practices

Build, Release, and Maintenance

  • Install scripts (postinstall, Makefile, setup.py, cargo build scripts, GitHub Actions)
  • Downloading binaries at build time
  • Signed releases, checksums, provenance
  • Versioning policy, security patch cadence, dependency update automation

Risk Rating

For each finding, provide:

  • Severity: Critical / High / Medium / Low / Informational
  • Impact: What breaks or leaks if exploited
  • Likelihood: How plausible is exploitation in practice
  • Complexity: How difficult is exploitation (Low / Medium / High)
  • Affected components: File paths with short code snippets as evidence

Output Format

# Due diligence for [Project Name]

## Executive summary

[2–3 sentences: overall posture, most significant findings]

## Scope and methodology

[What was analyzed, what approach was taken]

## Findings

### 🔴 Critical / High

#### [Finding title]

**Severity:** Critical | **Likelihood:** High | **Complexity:** Low
**Location:** `path/to/file:42`

**Description**

[What the issue is, with evidence]

**Impact**

[What an attacker could achieve]

**Recommendation**

[Specific fix]

### 🟠 Medium

[Same structure]

### 🟡 Low / Informational

[Same structure]

## Dependency summary

| Dependency  | Version | Known CVEs    | Risk   |
| ----------- | ------- | ------------- | ------ |
| example-lib | 1.2.3   | CVE-XXXX-YYYY | Medium |

## Recommendations

[Prioritized list of actions]

## Strengths

[What's done well — acknowledge good security practices]

## Not assessed

[Areas outside the scope of this audit or not reachable via static analysis]

Omit empty severity sections. If the project is well-built and secure, say so clearly.