Skip to main content

Abuse Cases

Abuse CaseOutcomeMitigation
A developer runs sicario init --force in the wrong directory, destroying unrelated governance filesIrreversible data lossDefault init is brownfield-safe (merge/overlay/preserve, never full overwrite); --force requires an explicit flag and still takes a timestamped *.sicario-bak.* backup before each overwrite; --dry-run previews every decision without writing
A developer initializes SicarioSpec and then removes or ignores all governance artifacts to pass verification without meaningful evidenceFalse sense of securitysicario verify checks that required sections contain substantive content (not empty or placeholder), and control maps must be present for selected frameworks
A repo contributor adds an AI feature without prompt-injection guardrailsAI agent behavior bypassVerify rejects AI-domain specs that omit the mandatory ## Prompt Injection guardrails section; the finding code is non-zero exit
A developer commits a hardcoded token and attempts to verifyCredential leakPattern-based secret scan runs as a verify gate; finding produces a non-zero exit and a specific finding code
A feature changes behavior without updating docs, diagrams, or the risk registerDocumentation drift + blind risk acceptanceVerify gates for docs-impact, docs/diagrams/, and valid risk-register rows; any of these missing produces a finding
A maintainer temporarily disables a verify gate to unblock a deploy, then forgets to re-enable itRegression in governance coverageShipped rules load from the package (presets/sicario-core/rules/); a project rule in .sicario/rules/ can override one by reusing its id, but every effective override is recorded in scan_coverage.overrides in generated/sicario/gate-summary.json with an impact string (e.g. disables-critical-severity-rule), so a disabled gate is visible in evidence as well as in diff review. A rule file that fails to load is a critical SICARIO-RULE-INVALID / SICARIO-RULE-UNREADABLE finding, and a run that loads zero rules fails closed with SICARIO-NO-RULES-LOADED (see rule-engine.md)
An external contributor forks the repo and removes all governance before submitting changesFork bypasses governanceGovernance is enforced via CI on the upstream repo; forks cannot modify the upstream CI workflow or branch protection rules
A developer uses --frameworks to select no frameworks, bypassing all control-map checksControl-map requirements circumventedAn empty selection does not bypass the gate: with no .sicario/frameworks.txt, sicario verify falls back to the coarse control-map check (shipped rule SICARIO-MISSING-CONTROL-MAPS, which runs regardless of the selector). Unknown framework keys on --frameworks are a hard error, so a typo cannot silently drop a framework