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