Check Skill Security

check-skill-security — the security-posture gate for skills

Every rule in this checker is a generalized finding from the project's own 2026-07-24 pre-release security self-audit (internal remediation plan). The audit's meta-lesson: unsafe constructs enter one skill at a time while sibling skills already carry the safe pattern. This gate makes the safe patterns mechanical for every future skill.

Run

python3 -m traust.cli check skill-security            # full listing
python3 -m traust.cli check skill-security --quiet    # violations only

Exit 0 = clean. Exit 1 = violations; each names the rule, the file, and the audit finding class it guards.

Rules (S-series)

Scope: git-tracked files under src/traust/ and harnessing/ only — untracked work dirs (fuzz clones, venvs, scanner binaries) are target content, not harness code. Intentional-vulnerability fixtures (opengrep-rules/, tests/, rule-drafts/) are excluded.

Exemptions discipline

EXEMPTIONS in the script maps (rule, path) → reason. Two reason classes are allowed:

• KNOWN — remediation plan Px.y: a violation the audit already registered, grandfathered until that plan item lands. When the fix merges, remove the entry — the list must only shrink; a P0 entry outliving P0 is itself a finding.
• reviewed — <rationale>: a deliberate design the team has examined (e.g. patch's reviewer-isolation is its doctrine; a checker quoting the word "untrusted" in rule prose).

Never add an exemption to make your own new skill pass. If the gate fires on new code, the code is wrong — the grandfather list exists so the gate could be introduced at all, not as a pattern to follow.

When the gate fires on your skill

• S1: add allowed-tools frontmatter scoped to the scripts and read-only tools the skill actually needs (model: vuln-scan, countersign, or this skill's own frontmatter).
• S2: add the adversarial-content doctrine block (model: secure-code-audit §Adversarial Repository Content) — or, once the shared doctrine include from plan P1.6 exists, reference it.
• S3: gate the URL (^https:// allowlist) and set GIT_ALLOW_PROTOCOL=https in the subprocess env; reject leading-dash arguments; commits must match ^[0-9a-f]{7,40}$.
• S4: build argv lists; never hand variable text to a shell.
• S5: curl --config - with the header on stdin (model: validate-core-ocp/oauth_token.py).
• S6: per-user directory (~/.cache/<tool>/, mode 0700) or tempfile.mkstemp; never a predictable shared name.
• S7: pin exact versions; verify checksums for downloaded binaries.
• S8: wrap the specific fetch in a scoped script and grant that.
• S9: run the headless agent with cwd in a scratch dir and state the isolation doctrine in the launching file.
• S10: route the build/test invocation through python3 -m traust.cli util safe-exec with a profile from $TRAUST_CONFIG_HOME/safe-exec-profiles.yaml (validated argv, git -c/network hardening, shell-free pipelines, scrubbed env).

Integrations

Console-only output (no artifact). Enforced by .githooks/pre-commit alongside check_skill_alignment.py (A-series); the two are complementary — alignment guards cross-skill contracts, this guards security posture. The rule set derives from the internal remediation plan; update both together when a new finding class is discovered (add the rule here, register the campaign fix in the tracker).