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.
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- container-scanSkill
- dashboardSkill
- dependency-choiceSkill
- dep-resolveSkill
- detection-rulesSkill
- eol-checkSkill
- exploit-testSkill
- fixSkill
- iac-scanSkill
- license-checkSkill
- repo-impactSkill
- sast-scanSkill
- sbom-generateSkill
- secret-scanSkill
- secure-code-writeSkill
- typosquat-checkSkill
- verify-fixSkill
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
- Very specific: line 36
Read .vulnetix/memory.yaml.
- Very specific: line 52
Default format openvex. If user passes --format cyclonedx, the CLI emits CycloneDX VEX.
- Very specific: line 56
If user passed --upload:
- Very specific: line 66
If binaries.gh: true and we're inside a PR (env GITHUB_REF or gh pr view --json number):
≈ “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.
Files
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) orvulnetix vdb vuln <id>,vulnetix_exploits(MCP),fixfirst; 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_affectedfix-applied→fixedrisk-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.jsonDefault 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.jsonOtherwise, 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.mdWhere 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.choicevia 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 cyclonedxproduce different schemas; consumers downstream typically prefer one or the other.--uploadsends to the Vulnetix triage endpoint — requires authenticated CLI; community-tier may rate-limit.- PR comment posting needs
binaries.gh: trueAND 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.choicepopulated for every entry to be published — entries withstatus: under_investigationare filtered out unless--include-investigatingis passed.
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
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.

