cyber-audit

# cyber-audit Determine whether this machine is exposed to a specific advisory, and leave a written audit trail. **Read-only** is the whole contract: you diagnose, you never remediate. **Scope boundary.** This is host exposure against a *named external advisory*, not a general security tool. For source/appsec review of a repo use a code-security review skill; for chasing a live misbehaving bug use `debug-mode`. If the user has no specific advisory in hand, this skill is the wrong one. ## Hard rules - **Read-only on the machine.** No installs, removes, upgrades, restarts, config changes, or file writes outside the report directory. Reading the *advisory* is allowed and expected — fetch the CVE/advisory details from authoritative sources, or use the full text the user provided. The ban is on changing the machine, not on research. - **No `sudo`.** Never. - **One report per invocation.** Always end by writing the `.md` report — even a "Not affected" verdict matters as an audit trail. - If a check needs a state-changing command, **skip it and record "not checked (would require state change)"** in the table. Do not run it. ## Workflow 1. **Scope — grounded, never from memory.** Establish the affected package/binary name, affected versions, platform, and attack vector (supply chain / RCE / local / network) from the advisory itself. If the input is only a CVE ID or package name, look the advisory up (read-only) or ask for the full text *before* auditing — never infer affected v...