# Security Audit > > - **Type:** Skill - **Install:** `agentstack add skill-ractive-hyalo-security-audit` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [ractive](https://agentstack.voostack.com/s/ractive) - **Installs:** 0 - **Category:** [Productivity](https://agentstack.voostack.com/c/productivity) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [ractive](https://github.com/ractive) - **Source:** https://github.com/ractive/hyalo/tree/main/.claude/skills/security-audit ## Install ```sh agentstack add skill-ractive-hyalo-security-audit ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Security Audit You are performing a security audit of a Rust codebase. Your goal is to find real, actionable security issues — not to generate a long list of theoretical concerns. Prioritize findings by actual risk: a leaked API key in a fixture is more urgent than a theoretical timing attack on a string comparison. ## Audit Structure Produce a report with these sections. For each section, only include findings — skip "PASS" items unless they are genuinely surprising or counterintuitive. A lean report focused on what needs fixing is more useful than one padded with confirmations of good practices. However, always check and report on dependencies (section 2) even if they look clean — dependency vulnerabilities are silent and a "no issues found" confirmation is valuable there. ### 1. Secrets & Sensitive Data Scan This is often the highest-impact finding category because leaked secrets can be exploited immediately, unlike code vulnerabilities that require an attack vector. Scan systematically — open and read every non-binary file, don't just check whether directories are gitignored. **Where to look (read the actual files, don't just check if they exist):** - Test fixtures (JSON, YAML, TOML in `tests/` or `fixtures/` dirs) — open each one and check for real-looking values - Documentation and knowledgebase files — read every `.md` file in any `docs/`, `knowledgebase/`, or similar directory. Look for infrastructure details, account references, "production" mentions, internal project names, and internal URLs. These files are easily overlooked but often contain the most revealing information about the real infrastructure behind the project - Agent memory and config (`.claude/` directory tree) — check committed agent definitions, skill files, and memory indexes for private paths or personal details - Config files (`.env`, `.env.example`, `settings.json`, `settings.local.json`) - OpenAPI specs or API reference files — these often contain example data copied from real responses - Cargo.toml metadata (author emails, repository URLs) - CI/CD configs **Git history scan — this catches things the file tree misses:** - Run `git log --format='%ae' | sort -u` to check author emails — corporate or personal emails will be exposed when open-sourced - Run `git log --all --oneline --diff-filter=D -- '*.env' '*.key' '*.pem' '*.json'` to check if sensitive files were ever committed and then deleted (they're still in history) - Check if any commit messages reference ticket numbers, internal systems, or real account details **What to look for:** - API keys, tokens, passwords (even "test" values — `redacted-*` is fine, but `sk-live-*` or realistic UUIDs are not) - Real account IDs, user IDs, or organization IDs (vs obvious dummy values like `00000000-...`) - Email addresses, usernames, or personal information - Internal hostnames, IP addresses, or infrastructure details - URLs with embedded credentials or tokens - Private file paths (like `/Users/username/...`) that reveal system layout - References to "production", "staging", or internal environments that reveal infrastructure context **Severity guide:** - **CRITICAL**: Live credentials, real API keys, or PII that could enable account access - **HIGH**: Real-looking IDs or infrastructure details that could aid reconnaissance - **MEDIUM**: Personal info (emails in git history, local paths) that would be exposed on open-source - **LOW**: Placeholder values that technically should be more obviously fake ### 2. Rust Code Security Focus on patterns that create real vulnerabilities in this specific codebase, not generic Rust safety advice. **Input validation & injection:** - CLI arguments passed to shell commands, URLs, or file paths without sanitization - Path traversal: can user-supplied `--path`, `--file`, `--remote_path` etc. escape intended directories? (e.g., `../../etc/passwd`) - URL construction: are user inputs interpolated into URLs without encoding? Pay special attention to hostname construction — if a user-supplied value becomes part of a domain name, an attacker can redirect requests (and credentials) to their own server - Does the CLI accept `--format json` or similar that could be used for output injection? **Authentication & credential handling:** - Are API keys logged, included in error messages, or written to disk? - Could debug output (`--debug` flag) leak credentials in HTTP headers? - Are credentials held in memory longer than necessary? - Is there any credential caching that could leave secrets on disk? **Unsafe code:** - Any `unsafe` blocks — are they actually necessary? Is the safety invariant documented? **Error handling:** - Do error messages leak internal paths, server responses, or credential fragments? - Are panics possible from user input (unwrap on user-controlled data)? **Dependency concerns:** - Check `Cargo.toml` and `Cargo.lock` for known-vulnerable versions - Are there dependencies with overly broad feature flags? ### 3. CLI Misuse Vectors Think like an attacker who has access to this CLI tool. What could they do that the developer didn't intend? **Destructive operations:** - Are delete operations (purge, rm, delete) protected by confirmation prompts? - Can `--yes` / `-y` flag be used to bypass all safety checks in scripts? - Is there rate limiting or batch-size limits on destructive operations? - Does the delete confirmation distinguish between files and directories (recursive delete)? **Local file system risks:** - Can download commands write to arbitrary paths? (overwriting ~/.ssh/authorized_keys, etc.) - Can upload commands read arbitrary local files? (exfiltrating /etc/passwd to cloud storage) - Are there symlink-following risks? **Privilege escalation:** - Could a low-privilege API key be used to discover or access resources it shouldn't? **Supply chain:** - Could malicious shell completions be generated? - Are there code paths where external data (API responses) influences local file operations? ### 4. Configuration & Infrastructure - Is `.env` properly gitignored? - Are there any config files that might be committed with real values? - Does the project have appropriate `.gitignore` coverage? ## Report Format Present findings as a prioritized list. For each finding: ``` ### [CRITICAL|HIGH|MEDIUM|LOW] Brief title **File:** `path/to/file.rs:42` **Issue:** What's wrong, concretely **Risk:** What an attacker could do with this **Fix:** Specific remediation (one line if possible) ``` End the report with exactly this format: **X findings: N critical, N high, N medium, N low** Follow with a 2-3 sentence assessment of the overall security posture. ## What NOT to do - Don't list items that pass inspection — only report actual findings - Don't flag theoretical issues in safe Rust code that the type system already prevents - Don't recommend adding dependencies (like secret-scanning tools) unless there's a specific gap - Don't rewrite code — just identify the issues and suggest fixes - Don't pad the report with generic security advice (e.g., "consider using HTTPS" when the code already does) - Don't flag things as issues when they're intentional design choices (e.g., reading API key from env var is standard practice, not a vulnerability) ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [ractive](https://github.com/ractive) - **Source:** [ractive/hyalo](https://github.com/ractive/hyalo) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-ractive-hyalo-security-audit - Seller: https://agentstack.voostack.com/s/ractive - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.