agentleFS
VulnetixVulnetix/pix-ai-coding-assistant/skills/vex-publish/SKILL.md

vex-publish

Skill9 starsChanged 7 days agoApache-2.0View on GitHub

Generate OpenVEX / CycloneDX VEX attestations from `.vulnetix/memory.yaml` triage decisions, optionally sign with cosign, optionally upload to Vulnetix and post to a GitHub PR. Use when documenting triage decisions for supply-chain consumers, attaching VEX to a CycloneDX SBOM, or satisfying customer attestation requests.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .vulnetix/memory.yaml.

    line 36
  2. Very specific:

    Default format openvex. If user passes --format cyclonedx, the CLI emits CycloneDX VEX.

    line 52
  3. Very specific:

    If user passed --upload:

    line 56
  4. Very specific:

    If binaries.gh: true and we're inside a PR (env GITHUB_REF or gh pr view --json number):

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Vulnetix VEX Publication Skill

Use when

  • Triage cycle is complete and you need to publish VEX statements for supply-chain consumers.
  • A customer requested OpenVEX attestations for a specific delivery.
  • Attaching VEX to a CycloneDX SBOM in a compliance bundle.
  • Posting VEX status as a PR comment so reviewers see the security disposition.
  • Auditing the decision history — VEX is the durable record of what was decided when.

Don't use for

  • Making the triage decisions — use vulnetix_vuln (MCP) or vulnetix vdb vuln <id>, vulnetix_exploits (MCP), fix first; this skill publishes existing decisions.
  • Generating the SBOM itself — use sbom-generate.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

Turns the decisions captured in .vulnetix/memory.yaml into a signed/uploadable VEX document.

Step 1: Load memory

Read .vulnetix/memory.yaml. Collect every entry with a non-default decision.choice (i.e. anything that isn't investigating).

Step 2: Map decisions → VEX status

Mapping (Vulnetix CLI uses the same):

  • not-affected / risk-avoided → not_affected
  • fix-applied → fixed
  • risk-accepted / deferred / mitigated → affected (with mitigations)
  • investigating → under_investigation

Step 3: Generate VEX

vulnetix triage --provider vulnetix --vex-format ${FORMAT:-openvex} -o json > .vulnetix/vex/${TIMESTAMP}.vex.json

Default format openvex. If user passes --format cyclonedx, the CLI emits CycloneDX VEX.

Step 4: Upload (conditional)

If user passed --upload:

vulnetix upload --file .vulnetix/vex/${TIMESTAMP}.vex.json

Otherwise, skip and report the local file path.

Step 5: GitHub PR comment (conditional)

If binaries.gh: true and we're inside a PR (env GITHUB_REF or gh pr view --json number):

gh pr comment "$PR_NUMBER" --body-file .vulnetix/vex/${TIMESTAMP}.vex.summary.md

Where the summary file is a short Markdown rendering of the VEX (auto-generated from the JSON).

Step 6: Render report

VEX statements: N
- not_affected: N
- fixed: N
- affected (with mitigations): N
- under_investigation: N
File: .vulnetix/vex/<timestamp>.vex.json
Uploaded: <yes|no>
PR comment: <yes|no>

Edge cases & gotchas

  • VEX status maps from decision.choice via a closed dict — not-affected/risk-avoided → not_affected, fix-applied → fixed, risk-accepted/deferred/mitigated → affected (with mitigation), investigating → under_investigation. Custom decision strings break the mapping.
  • --format openvex (default) and --format cyclonedx produce different schemas; consumers downstream typically prefer one or the other.
  • --upload sends to the Vulnetix triage endpoint — requires authenticated CLI; community-tier may rate-limit.
  • PR comment posting needs binaries.gh: true AND the current directory inside a PR-context git repo (CI envs typically have GITHUB_REF set).
  • Signing with cosign uses keyless OIDC by default; the user must have a valid OIDC identity (CI runners typically do, dev laptops may not).
  • Memory schema requires decision.choice populated for every entry to be published — entries with status: under_investigation are filtered out unless --include-investigating is passed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.