Como usar
- Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
- Consulte no original as ferramentas, credenciais e ambientes necessários.
- Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.
npx skills add https://github.com/hcaiano/skills --skill cyber-auditAntes de começar
- A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
- Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.
Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.
cyber-audit
Determine whether this machine is exposed to one named advisory, and leave a written audit trail.
Hard rules
- Read-only on the machine. You diagnose; the user remediates. No installs,
removes, upgrades, restarts, config changes, or file writes outside ~/security-audits/. Reading the advisory is expected: fetch it from authoritative sources, or use the full text the user provided.
- No `sudo`.
- Record a check that needs a state-changing command as "not checked (would
require state change)" instead of running it.
- One report per invocation, even for "Not affected": it is the audit
trail.
Workflow
- Scope from the advisory. Establish the affected package or binary,
affected versions, platform, and attack vector (supply chain / RCE / local / network) from the advisory itself. Given only a CVE ID or package name, look the advisory up or ask for its full text before auditing; an ungrounded verdict is worse than none. Done when the affected versions cite the advisory.
- Check. Read
uname -s, then read
references/checks.md and pick the checks for this advisory's ecosystem and this OS. Run independent checks in parallel.
- Build the table as you go: one row per check with its concrete result
(version, path, "None", "N/A", or "not checked" with the reason). Done when every picked check has a row and every gap needed for the verdict is named.
- Write the report. Run
mkdir -p ~/security-audits, then write
~/security-audits/YYYY-MM-DD-<short-kebab-slug>.md from the template below, with today's date from the environment. When the verdict is Affected, put the remediation command under Follow-ups for the user to run.
- Report the verdict to the user in one line plus the report path.
Report template
# <Subject> — Audit
**Date:** YYYY-MM-DD
**Host:** <this machine>
## <CVEs | Advisory> in scope
- **<ID or source> "<Name>"** — <one-line description>. <Affected versions or scope>.
## Audit results
| Check | Result |
|---|---|
| <Check 1> | <Result> |
| <Check 2> | <Result> |
## Verdict
**<Not affected. | Affected. | Partially affected. | Inconclusive.>**
- <Rationale bullet 1>
- <Rationale bullet 2>
## Action taken
None — diagnostic only, no files modified outside the report directory.
## Follow-ups
- <Actionable item, or "None">Verdict
The attack vector decides which check proves exposure:
- Supply-chain / malicious package: a present vulnerable version is
exposure, because its install-time and import-time payloads may already have run. Presence is Affected whether or not anything is running; the report states the observed package state, not that a payload ran.
- Network / service (RCE): exposure needs the vulnerable code running and
reachable, so the process and listener checks decide.
Verdicts:
- Not affected. Absent, or installed but patched; for network/service
advisories, also installed but not running and not exposed.
- Affected. A vulnerable version present and reachable by the attack
vector.
- Partially affected. Network/service advisories only: installed and
running but only partly reachable, e.g. bound to loopback or exposed only behind auth or a firewall. Spell out the mitigation. A fully stopped service is Not affected.
- Inconclusive. A check needed to prove absence, version, or reachability
could not run. Name that check and the missing evidence in the report.
