1---
  2name: auditing-repositories
  3description: 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.
  4user-invocable: true
  5license: LicenseRef-MutuaL-1.2
  6metadata:
  7  author: Amolith <amolith@secluded.site>
  8---
  9
 10Be 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.
 11
 12## Guardrails
 13
 14- **Prefer static inspection.** Don't execute untrusted artifacts. If running anything (linters, `npm audit`, `cargo audit`), document exactly what and why.
 15- **Avoid speculative findings.** Each issue needs concrete evidence, not hypotheticals.
 16
 17## Workflow
 18
 191. **Understand the project**: Read README, docs, and config to learn what the software claims to do
 202. **Identify the stack**: Languages, frameworks, build systems, deployment targets
 213. **Map attack surface**: Locate entry points and trust boundaries — CLI args, HTTP routes, RPC handlers, webhooks, config/env, file format parsers, plugins, deserialization
 224. **Analyze systematically**: Work through each analysis area below, starting with highest risk
 235. **Check dependencies**: Review dependency manifests for known vulnerabilities and supply chain risk
 246. **Review build and release pipeline**: Install scripts, CI workflows, build-time downloads, release signing
 257. **LLM-specific checks**: If the project involves LLMs, AI assistants, or MCP servers, DO NOT FORGET to apply [references/llm-security.md](references/llm-security.md)
 268. **Write the report**: Use the output format below; rate each finding
 27
 28Assess from both an external attacker and malicious insider perspective. Focus on practical, realistic threats — not theoretical edge cases requiring unrealistic exploitation scenarios.
 29
 30## Analysis Areas
 31
 32### Correctness / Unexpected Behavior
 33
 34- Does the software function as described? Any undocumented behaviors?
 35- Verify claims in README/docs against actual implementation
 36
 37### Security
 38
 39- Authentication/authorization weaknesses
 40- Input validation and injection (SQL, command, XSS, CSRF, SSRF, path traversal)
 41- Insecure cryptographic implementations or misuse
 42- Unsafe deserialization (YAML, JSON, pickle), archive extraction (zip-slip), template engines
 43- Race conditions and concurrency issues
 44- Hardcoded credentials or secrets
 45- Insecure default configurations
 46- Memory safety concerns (C/C++/Rust unsafe blocks): bounds checks, use-after-free, unsafe FFI
 47
 48### Privacy
 49
 50- What data is collected, how it's stored, and where it's sent
 51- Data retention policies and third-party sharing
 52- Tracking mechanisms: cookies, persistent identifiers, telemetry, analytics SDKs
 53- Whether data collection is disclosed to users and proportionate to functionality
 54
 55### Network Communications
 56
 57- All endpoints contacted during operation
 58- Authentication and encryption of connections
 59- Types of data transmitted; interception risk
 60- Whether each communication is necessary for core functionality
 61- Unexpected or suspicious outbound connections
 62
 63### Permissions and Sandboxing
 64
 65- System permissions requested (filesystem, network, hardware)
 66- Whether permissions align with stated functionality
 67- API scopes and integration breadth
 68- Running as root, setuid, container escape potential
 69- Background services, startup hooks, file permission modes
 70- Temp directory safety, symlink attacks
 71
 72### Code Quality (Security-Relevant)
 73
 74- Error handling: fail-open vs fail-closed
 75- Logging of sensitive data; secret leakage in logs or crash dumps
 76- Debug endpoints exposing config or secrets
 77- Input sanitization at boundaries
 78- Secure coding patterns (or lack thereof)
 79
 80### Dependencies
 81
 82- Known vulnerabilities in direct and transitive dependencies
 83- Supply chain risks (unmaintained, single-maintainer, typosquat)
 84- Unnecessary dependencies increasing attack surface
 85- Dependency pinning and verification practices
 86
 87### Build, Release, and Maintenance
 88
 89- Install scripts (`postinstall`, `Makefile`, `setup.py`, cargo build scripts, GitHub Actions)
 90- Downloading binaries at build time
 91- Signed releases, checksums, provenance
 92- Versioning policy, security patch cadence, dependency update automation
 93
 94## Risk Rating
 95
 96For each finding, provide:
 97
 98- **Severity**: Critical / High / Medium / Low / Informational
 99- **Impact**: What breaks or leaks if exploited
100- **Likelihood**: How plausible is exploitation in practice
101- **Complexity**: How difficult is exploitation (Low / Medium / High)
102- **Affected components**: File paths with short code snippets as evidence
103
104## Output Format
105
106```markdown
107# Due diligence for [Project Name]
108
109## Executive summary
110
111[2–3 sentences: overall posture, most significant findings]
112
113## Scope and methodology
114
115[What was analyzed, what approach was taken]
116
117## Findings
118
119### 🔴 Critical / High
120
121#### [Finding title]
122
123**Severity:** Critical | **Likelihood:** High | **Complexity:** Low
124**Location:** `path/to/file:42`
125
126**Description**
127
128[What the issue is, with evidence]
129
130**Impact**
131
132[What an attacker could achieve]
133
134**Recommendation**
135
136[Specific fix]
137
138### 🟠 Medium
139
140[Same structure]
141
142### 🟡 Low / Informational
143
144[Same structure]
145
146## Dependency summary
147
148| Dependency  | Version | Known CVEs    | Risk   |
149| ----------- | ------- | ------------- | ------ |
150| example-lib | 1.2.3   | CVE-XXXX-YYYY | Medium |
151
152## Recommendations
153
154[Prioritized list of actions]
155
156## Strengths
157
158[What's done well — acknowledge good security practices]
159
160## Not assessed
161
162[Areas outside the scope of this audit or not reachable via static analysis]
163```
164
165Omit empty severity sections. If the project is well-built and secure, say so clearly.