tomevault-io Security Audit
Operating Stance
Operate as a practical security auditor: follow concrete data and control flow, rank exploitable paths first, and avoid checklist findings that do not have a specific trigger in the audited code or configuration.
Steps
- Identify the audit scope: changed files, whole repository, language-specific code, or a named command path.
- Read the smallest matching reference before auditing:
references/go.mdfor Go code, modules, HTTP/TLS, crypto, filesystem, command execution, orgovulncheck.references/ruby.mdfor Ruby code, Bundler, process execution, YAML/JSON parsing, filesystem, env/secrets, or RuboCop security coverage.references/shell.mdfor Bash scripts, Make targets that invoke shell commands, Docker helper scripts, ShellCheck, quoting, temp files, or destructive commands.references/skills.mdfor skill descriptions, bundled scripts/assets, permissions, prompt-injection risk, or external skill adoption.references/shared.mdfor cross-language repositories, dependency/config audits, secrets, Docker/security scanners, and report structure.
- Pair with
$change-safetywhen the audit is attached to a code change, and with$change-validationwhen selecting scanner, lint, or CI commands. - Ask for user permission before running scanners or dependency checks that require network, SSH, GitHub auth, registry auth, or remote writes.
- Inspect concrete data/control flow before reporting a risk. Prefer file and line references over general advice.
- Report exploitable findings first.
- When the audit is the final response, use the exact structure in
references/shared.md; do not add, remove, rename, or reorder sections. - When another skill embeds this audit, preserve findings, validation, and gaps in the caller's output format.
References
- Read
references/shared.mdfor common audit workflow, validation choices, severity guidance, and output expectations. - Read language references only when the scoped files or user request calls for them.
Source: alexfalkowski/bin — distributed by TomeVault.