boost-skill-cli 1.2.34__tar.gz → 1.2.36__tar.gz

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/CONTRIBUTING.md

@@ -257,6 +257,17 @@ branch ruleset (**Settings → Rules → Rulesets**):
   gate before it can merge, so an incompatible pair can't both land — the second
   PR must include the first and re-run CI.
 
+> **Set it in the ruleset, and verify it from the API.** This repository asks
+> for that rule in two places, and for a while neither one enforced it. Classic
+> branch protection had `strict: true` *and* `enforce_admins: false`, so it
+> skipped the only account that merges; the active ruleset — no bypass actors,
+> so it does apply — had `strict_required_status_checks_policy: false`. Two
+> mechanisms, and the binding one had the safety off. Two PRs then merged into
+> a red `main`, which stopped the release guard arming and left two merged PRs
+> unreleased. Check the real state with
+> `gh api repos/jonnyeclectic/boost/rulesets/<id>`, never the settings page,
+> and note that the `branch-current` required check now backstops it.
+>
 > Check names must be **unique across workflows** — GitHub matches a required
 > check by name alone. Three names collided before this was written (`lint` in
 > ci/markdownlint/theme-lint, `audit` in lighthouse/pip-audit, `analyze` in

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/Makefile

@@ -88,6 +88,7 @@ lint:
 	$(PY) scripts/build_registries.py --check
 	$(PY) scripts/build_roadmap.py --check
 	$(PY) scripts/build_command_reference.py --check
+	$(PY) scripts/build_vex.py --check
 	$(PY) scripts/lock_toolchain.py --check
 	$(PY) scripts/a11y_check.py
 	$(PY) scripts/page_budget.py
@@ -237,6 +238,7 @@ generate:
 	$(PY) scripts/build_registries.py
 	$(PY) scripts/build_roadmap.py
 	$(PY) scripts/build_command_reference.py
+	$(PY) scripts/build_vex.py
 
 # regenerate docs/demo.gif (brew install vhs)
 demo:

{boost_skill_cli-1.2.34/boost_skill_cli.egg-info → boost_skill_cli-1.2.36}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.34
+Version: 1.2.36
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.34'
-__version_tuple__ = version_tuple = (1, 2, 34)
+__version__ = version = '1.2.36'
+__version_tuple__ = version_tuple = (1, 2, 36)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.34
+Version: 1.2.36
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/boost_skill_cli.egg-info/SOURCES.txt

@@ -213,6 +213,7 @@ docs/roadmap/items/boost-first-carried-the-losing-trigger.md
 docs/roadmap/items/boost-first-rule.md
 docs/roadmap/items/boost-langchain-publishing.md
 docs/roadmap/items/boost-run-live-agents.md
+docs/roadmap/items/branch-current-gate.md
 docs/roadmap/items/bring-commands-under-mutation-testing.md
 docs/roadmap/items/broken-link-and-anchor-checking-lychee.md
 docs/roadmap/items/browse-could-not-search-two-words.md
@@ -463,6 +464,7 @@ docs/roadmap/items/update-diff-before-apply.md
 docs/roadmap/items/update-refreshed-rules-without-a-gate.md
 docs/roadmap/items/update-refreshes-rules-and-workflows.md
 docs/roadmap/items/update-reinstall-widens-agent-scope.md
+docs/roadmap/items/vex-openvex-feed.md
 docs/roadmap/items/visual-regression-pass-on-the-guide.md
 docs/roadmap/items/widen-the-ruff-rule-surface-b-sim-c4-perf-ruf.md
 docs/roadmap/items/windows-in-the-ci-matrix.md
@@ -475,6 +477,12 @@ docs/roadmap/items/zip-strict-audit.md
 docs/roadmap/items/zizmor-ignores-drift-and-make-lint-never-ran-it.md
 docs/roadmap/items/zizmor-pin-is-a-yanked-release.md
 docs/superpowers/specs/2026-08-16-catalogue-content-identity-design.md
+docs/vex/meta.md
+docs/vex/openvex.json
+docs/vex/statements/gitleaks-secretscan-test-fixtures.md
+docs/vex/statements/quality-trust-fingerprint-not-sensitive.md
+docs/vex/statements/zizmor-adhoc-packages-lint-runners.md
+docs/vex/statements/zizmor-dangerous-triggers-workflow-run.md
 evals/README.md
 evals/__init__.py
 evals/baseline.json
@@ -507,7 +515,9 @@ scripts/build_demo_index.py
 scripts/build_registries.py
 scripts/build_roadmap.py
 scripts/build_scale_corpus.py
+scripts/build_vex.py
 scripts/check_anchors.py
+scripts/check_branch_current.py
 scripts/check_dco.py
 scripts/check_licenses.py
 scripts/check_reproducible.py
@@ -627,6 +637,7 @@ tests/unit/test_ai.py
 tests/unit/test_bmad_core.py
 tests/unit/test_boost_first_offer.py
 tests/unit/test_bootstrap.py
+tests/unit/test_branch_current.py
 tests/unit/test_browse.py
 tests/unit/test_builtin.py
 tests/unit/test_capabilities.py
@@ -767,6 +778,7 @@ tests/unit/test_typosquat.py
 tests/unit/test_updatediff.py
 tests/unit/test_util.py
 tests/unit/test_version.py
+tests/unit/test_vex.py
 tests/unit/test_visual_harness_flags.py
 tests/unit/test_workflow_concurrency.py
 tests/unit/test_workflow_concurrency_groups.py

boost_skill_cli-1.2.36/docs/roadmap/items/branch-current-gate.md

@@ -0,0 +1,39 @@
+---
+id: branch-current-gate
+board: code
+section: health
+status: inflight
+category: CI · Release safety
+complexity: S
+impact: High
+wow: 4
+note: two protection mechanisms disagreed; the binding one had the safety off
+order: 10
+owner: loop/generated-freshness
+pr:
+title: main went red because "require branches up to date" was never actually on
+---
+Two pull requests, each green against the <code>main</code> it was tested on, merged into a
+combination that turned <code>main</code> red. Their source files did not conflict. The
+<b>generated</b> <code>docs/roadmap.html</code> did — and a squash merge takes one side of a
+generated file <b>without ever reporting a conflict</b>. The board's "Loop finds" counter was
+correct on both branches and wrong for their union.
+<b>Seventeen jobs failed on one line.</b> Ten test legs, the lint job and all six mutation
+shards — the shards because the unit suite runs inside <code>mutants/</code>, where
+<code>test_roadmap_fresh</code> fails baseline <i>collection</i>, so a stale generated file
+reads as "the mutation gate could not start". And because <code>ci</code> was red on
+<code>main</code>, the release workflow's guard never armed: two merged pull requests, one of
+them the reproducible-build pipeline, sat on <code>main</code> with no tag.
+<b>The root cause was a setting, and the trap was that it looked set.</b> The repository asks
+GitHub to require branches be up to date <b>twice</b>. Classic branch protection has
+<code>strict: true</code> — and <code>enforce_admins: false</code>, so it does not apply to the
+one account that merges. The active ruleset, which has no bypass actors and therefore does
+apply, had <code>strict_required_status_checks_policy: false</code>. Two mechanisms, and the
+binding one had the safety off. They also disagreed on how many checks are required: 14, 20,
+and 21 in <code>required-checks.txt</code>.
+<b>Fixed both ways.</b> The ruleset now enforces up-to-date merges, verified by reading it back
+from the API rather than trusting the settings page. And <code>branch-current</code> is now a
+required check, because that setting is invisible config that drifted once and can drift again
+— a required check is in the diff, in <code>required-checks.txt</code>, and shows up in review.
+Within minutes of the fix, GitHub moved two open pull requests to <code>behind</code> and
+refused them; an hour earlier both would have merged and broken <code>main</code> a second time.

boost_skill_cli-1.2.36/docs/roadmap/items/vex-openvex-feed.md

@@ -0,0 +1,39 @@
+---
+id: vex-openvex-feed
+board: code
+section: health
+status: shipped
+category: Security · Posture
+complexity: S
+impact: Low
+wow: 2
+note: OSPS-VM-04.02 — 4 statements, zero fabricated CVEs
+order: 45
+owner: loop/vex
+pr:
+title: A machine-readable VEX feed, sourced from findings that already existed
+---
+<code>OSPS-VM-04.02</code> — a Level 3 Baseline criterion <a
+href="roadmap.html#osps-baseline-levels">the audit</a> hadn't reached — asks for a VEX
+document accounting for vulnerabilities that don't affect the project, with the
+non-exploitability reasoning attached. boost already had that reasoning; it just wasn't in a
+form a consumer could ingest. CodeQL dismissals carry a <code>#
+codeql[rule-id]</code> comment, <code>.gitleaks.toml</code> allowlists boost's own synthetic
+secret-scanner fixtures, and <code>.github/zizmor.yml</code> documents six ignores by reason.
+<a href="https://openvex.dev/">OpenVEX</a> 0.2.0 turns those into
+a published document at <code>docs/vex/openvex.json</code>,
+generated by <code>scripts/build_vex.py</code> from one statement file per finding under
+<code>docs/vex/statements/</code> — the same one-file-per-item convention the roadmap boards
+themselves use, wired into <code>make generate</code> and a <code>--check</code> freshness
+gate in CI.
+<b>Four statements, and every one traces to a real, already-merged suppression</b> — not an
+invented CVE. boost has never had one, so nothing here is named <code>CVE-</code> or
+<code>GHSA-</code>; each statement's vulnerability name is the scanner's own rule id instead
+(<code>codeql:py/clear-text-logging-sensitive-data</code>, <code>gitleaks:...</code>,
+<code>zizmor:dangerous-triggers</code>, <code>zizmor:adhoc-packages</code>).
+<b>This satisfies one criterion, not the level.</b> <code>OSPS-QA-07.01</code> — a non-author
+human approval before merge — is the wall Level 3 hits regardless, and this change does not
+move it; <code>docs/openssf-badge.md</code> tracks the passing-badge criteria only and has no
+Baseline rows to flip, so the record lives here and in
+<code>docs/security-design.md</code>
+instead.

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>17</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>278</b><span>Loop finds</span></div>
+      <div class="stat"><b>280</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -5015,6 +5015,41 @@ re-embeds every vector already paid for.</p>
         </div>
       </article>
 
+      <article class="cap rcard" id="branch-current-gate">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">CI · Release safety</span></div>
+        <h3>main went red because "require branches up to date" was never actually on</h3>
+        <p>Two pull requests, each green against the <code>main</code> it was tested on, merged into a
+combination that turned <code>main</code> red. Their source files did not conflict. The
+<b>generated</b> <code>docs/roadmap.html</code> did — and a squash merge takes one side of a
+generated file <b>without ever reporting a conflict</b>. The board's "Loop finds" counter was
+correct on both branches and wrong for their union.
+<b>Seventeen jobs failed on one line.</b> Ten test legs, the lint job and all six mutation
+shards — the shards because the unit suite runs inside <code>mutants/</code>, where
+<code>test_roadmap_fresh</code> fails baseline <i>collection</i>, so a stale generated file
+reads as "the mutation gate could not start". And because <code>ci</code> was red on
+<code>main</code>, the release workflow's guard never armed: two merged pull requests, one of
+them the reproducible-build pipeline, sat on <code>main</code> with no tag.
+<b>The root cause was a setting, and the trap was that it looked set.</b> The repository asks
+GitHub to require branches be up to date <b>twice</b>. Classic branch protection has
+<code>strict: true</code> — and <code>enforce_admins: false</code>, so it does not apply to the
+one account that merges. The active ruleset, which has no bypass actors and therefore does
+apply, had <code>strict_required_status_checks_policy: false</code>. Two mechanisms, and the
+binding one had the safety off. They also disagreed on how many checks are required: 14, 20,
+and 21 in <code>required-checks.txt</code>.
+<b>Fixed both ways.</b> The ruleset now enforces up-to-date merges, verified by reading it back
+from the API rather than trusting the settings page. And <code>branch-current</code> is now a
+required check, because that setting is invisible config that drifted once and can drift again
+— a required check is in the diff, in <code>required-checks.txt</code>, and shows up in review.
+Within minutes of the fix, GitHub moved two open pull requests to <code>behind</code> and
+refused them; an hour earlier both would have merged and broken <code>main</code> a second time.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">two protection mechanisms disagreed; the binding one had the safety off</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="log-timestamps-mislabeled-utc">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Observability · Diagnostics</span></div>
         <h3>Log timestamps are local time mislabeled <code>Z</code></h3>
@@ -5252,6 +5287,42 @@ composed into a blind spot, which is the shape most of these have.</p>
           <span class="m">Gemini warned once per skill per session and no boost surface could see it</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="vex-openvex-feed">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Security · Posture</span></div>
+        <h3>A machine-readable VEX feed, sourced from findings that already existed</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>OSPS-VM-04.02</code> — a Level 3 Baseline criterion <a
+href="roadmap.html#osps-baseline-levels">the audit</a> hadn't reached — asks for a VEX
+document accounting for vulnerabilities that don't affect the project, with the
+non-exploitability reasoning attached. boost already had that reasoning; it just wasn't in a
+form a consumer could ingest. CodeQL dismissals carry a <code>#
+codeql[rule-id]</code> comment, <code>.gitleaks.toml</code> allowlists boost's own synthetic
+secret-scanner fixtures, and <code>.github/zizmor.yml</code> documents six ignores by reason.
+<a href="https://openvex.dev/">OpenVEX</a> 0.2.0 turns those into
+a published document at <code>docs/vex/openvex.json</code>,
+generated by <code>scripts/build_vex.py</code> from one statement file per finding under
+<code>docs/vex/statements/</code> — the same one-file-per-item convention the roadmap boards
+themselves use, wired into <code>make generate</code> and a <code>--check</code> freshness
+gate in CI.
+<b>Four statements, and every one traces to a real, already-merged suppression</b> — not an
+invented CVE. boost has never had one, so nothing here is named <code>CVE-</code> or
+<code>GHSA-</code>; each statement's vulnerability name is the scanner's own rule id instead
+(<code>codeql:py/clear-text-logging-sensitive-data</code>, <code>gitleaks:...</code>,
+<code>zizmor:dangerous-triggers</code>, <code>zizmor:adhoc-packages</code>).
+<b>This satisfies one criterion, not the level.</b> <code>OSPS-QA-07.01</code> — a non-author
+human approval before merge — is the wall Level 3 hits regardless, and this change does not
+move it; <code>docs/openssf-badge.md</code> tracks the passing-badge criteria only and has no
+Baseline rows to flip, so the record lives here and in
+<code>docs/security-design.md</code>
+instead.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Low</b></span>
+          <span class="m">Wow <b class="wow">★★</b></span>
+          <span class="m">OSPS-VM-04.02 — 4 statements, zero fabricated CVEs</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/docs/security-design.md

@@ -173,6 +173,43 @@ Every one of these gates blocks a merge to `main`.
 | `import-linter` | the layering that keeps `core/` free of CLI concerns |
 | SLSA provenance + PyPI Trusted Publishing | a released artifact traces to the commit and workflow that built it |
 
+## VEX: accounting for findings that don't affect boost
+
+Every tool in the table above finds things it does not fix — a CodeQL query
+firing on a pattern that isn't actually sensitive here, a gitleaks match on a
+string that was never a real credential, a zizmor rule on a trigger that
+carries its own mitigation. Each dismissal already has a written reason living
+next to the code it describes: a `# codeql[rule-id]` suppression comment, a
+`.gitleaks.toml` allowlist entry, an ignore in `.github/zizmor.yml`. None of
+that was a document a consumer could ingest, which is exactly what OSPS
+Baseline's `OSPS-VM-04.02` asks for: *"While active, any vulnerabilities in
+the software components not affecting the project MUST be accounted for in a
+VEX document, augmenting the vulnerability report with non-exploitability
+details."*
+
+[`docs/vex/openvex.json`](vex/openvex.json) is that document — an
+[OpenVEX](https://openvex.dev/) 0.2.0 feed, published at
+<https://jonnyeclectic.github.io/boost/vex/openvex.json>. It is generated by
+`scripts/build_vex.py` from one Markdown file per statement under
+[`docs/vex/statements/`](vex/statements/) — the same one-file-per-item
+convention `docs/roadmap/items/*.md` uses, so two people adding two different
+findings edit two different files rather than one shared JSON blob.
+`make generate` regenerates it; `make lint` and CI both run
+`build_vex.py --check` and fail if the committed document has drifted from
+its source files.
+
+Every statement in it today is sourced from a real, already-dismissed finding
+in this repository, not an invented one — the print-side CodeQL
+`py/clear-text-logging-sensitive-data` finding on `trust add`'s fingerprint
+line, the gitleaks allowlist entry for `tests/unit/test_secretscan.py`'s
+synthetic fixtures, and the two categories of `zizmor` ignores in
+`.github/zizmor.yml`. **boost has never had a CVE**, so the document names no
+CVE or GHSA identifier — each statement's `vulnerability.name` is the
+scanner's own rule id (`codeql:...`, `gitleaks:...`, `zizmor:...`) instead. An
+empty-but-honest VEX document would have been the right call had none of these
+findings existed to describe; naming a vulnerability that was never reported
+would not have been.
+
 ## Security review record
 
 OpenSSF Best Practices `security_review` asks for a review performed within the

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.36}/docs/verifying-releases.md

@@ -77,6 +77,15 @@ PGP key for boost, they did not come from this project.
 | Git tag | Points at the commit the release was built from | `git verify-tag` is *not* applicable — tags are unsigned; the provenance attestation is the authority |
 | Release notes | Assembled from the merged pull requests in that release | [Releases page](https://github.com/jonnyeclectic/boost/releases) |
 
+## VEX: findings that do not affect boost
+
+The SBOM says what is in a release; a separate, continuously-updated
+[OpenVEX](https://openvex.dev/) document says which known findings against
+those components don't actually affect boost, with the reasoning attached.
+It is not published per release — it is always current at
+[`docs/vex/openvex.json`](vex/openvex.json). See
+[security-design.md](security-design.md#vex-accounting-for-findings-that-dont-affect-boost).
+
 ## Can you rebuild it yourself? Yes — the measurement
 
 A reproducible build lets a third party rebuild the artifact from source and

boost_skill_cli-1.2.36/docs/vex/meta.md

@@ -0,0 +1,12 @@
+---
+id: openvex
+author: "the boost project (https://github.com/jonnyeclectic/boost)"
+version: 1
+timestamp: "2026-08-28T00:00:00Z"
+---
+Document-level identity for `docs/vex/openvex.json`, hand-edited the way a
+changelog is: bump `version` and set `timestamp` to the date of the change
+whenever a statement under `statements/` is added, changed, or removed.
+Neither field is computed — `scripts/build_vex.py` deliberately never reads
+the wall clock, so `--check` can compare byte-for-byte. This body is prose
+for humans editing the file; it is not part of the generated document.

boost_skill_cli-1.2.36/docs/vex/openvex.json

@@ -0,0 +1,61 @@
+{
+  "@context": "https://openvex.dev/ns/v0.2.0",
+  "@id": "https://jonnyeclectic.github.io/boost/vex/openvex.json",
+  "author": "the boost project (https://github.com/jonnyeclectic/boost)",
+  "timestamp": "2026-08-28T00:00:00Z",
+  "version": 1,
+  "statements": [
+    {
+      "vulnerability": {
+        "name": "gitleaks:leaked-secret-detection"
+      },
+      "products": [
+        {
+          "@id": "pkg:pypi/boost-skill-cli"
+        }
+      ],
+      "status": "not_affected",
+      "justification": "vulnerable_code_not_present",
+      "impact_statement": "`tests/unit/test_secretscan.py` exists to prove `boost_cli/core/secretscan.py`\nflags private keys and API tokens, so it ships synthetic examples of both by\ndesign — strings shaped exactly like the credentials gitleaks' own ruleset\nlooks for. gitleaks correctly matches the shape; none of the matched strings\nis a real, working credential, was ever live, or grants access to anything.\n`.gitleaks.toml` allowlists only this one file, by exact path, and the\nallowlist's own comment states why: nothing else in the repository is\nexcluded from the scan."
+    },
+    {
+      "vulnerability": {
+        "name": "codeql:py/clear-text-logging-sensitive-data"
+      },
+      "products": [
+        {
+          "@id": "pkg:pypi/boost-skill-cli"
+        }
+      ],
+      "status": "not_affected",
+      "justification": "vulnerable_code_not_present",
+      "impact_statement": "CodeQL's `py/clear-text-logging-sensitive-data` query flags\n`boost trust add`'s success line, which prints the trusted key's name and\nminisign fingerprint, because the argument is user-supplied and `fingerprint`\nreads like a credential name. It is not one: the value is a minisign\n**public** key fingerprint, which is meant to be published, and printing it is\nthe entire point of the command — it is how a user checks by eye that the key\nthey just trusted matches the one the publisher advertises. The class of data\nthe query exists to catch (a secret, token, or password) is not present in\nwhat is logged, so the pattern the rule looks for does not apply here. An\nearlier automated fix that replaced this line with a constant string removed\nthe only verification `trust add` offers; the line was restored, the\nsuppression carries this reasoning inline\n(`# codeql[py/clear-text-logging-sensitive-data]`), and\n`tests/functional/test_tap_signing.py` pins the output so it cannot be quietly\ndropped a second time."
+    },
+    {
+      "vulnerability": {
+        "name": "zizmor:adhoc-packages"
+      },
+      "products": [
+        {
+          "@id": "pkg:pypi/boost-skill-cli"
+        }
+      ],
+      "status": "not_affected",
+      "justification": "inline_mitigations_already_exist",
+      "impact_statement": "zizmor's `adhoc-packages` rule flags installing packages without a lockfile,\nbecause an unpinned install can resolve to a tampered or unexpectedly newer\npackage. Two workflows do this on purpose: `theme-lint.yml` installs\nmajor-pinned linters with `--no-save` into an empty checkout — boost ships no\n`package.json`, so a lockfile would exist solely for this one step — and\n`visual.yml` installs a pinned `puppeteer-core` from\n`tests/visual/package.json`, also `--no-save`. Both run on an ephemeral\nrunner, hold only `contents: read`, and their output gates nothing but\nthemselves — a compromised lint or screenshot tool in either job cannot reach\na secret or influence a later, privileged job."
+    },
+    {
+      "vulnerability": {
+        "name": "zizmor:dangerous-triggers"
+      },
+      "products": [
+        {
+          "@id": "pkg:pypi/boost-skill-cli"
+        }
+      ],
+      "status": "not_affected",
+      "justification": "inline_mitigations_already_exist",
+      "impact_statement": "zizmor's `dangerous-triggers` rule flags `workflow_run`, because the classic\nfailure mode is a privileged run executing pull-request-controlled code. Four\nworkflows use it — `ci-failure-issue.yml`, `publish.yml`, `post-deploy.yml`,\n`sbom.yml` — and each carries the mitigation that makes the pattern safe in\nits specific case, recorded inline in `.github/zizmor.yml`: none of them\nchecks out the triggering run's head SHA (each explicitly checks out `main`,\na release tag, or nothing at all), so no code a fork's pull request could\ninfluence ever runs in the privileged context. `publish.yml`, the one job that\nholds write credentials (PyPI Trusted Publisher OIDC), is additionally scoped\nto `push` events from this repository only — a fork PR opened from a branch\nnamed `main` cannot satisfy that filter. `sbom.yml` is gated on\n`head_repository == this repository` for the same reason. The remaining two\nhold only `contents: read` and no secrets."
+    }
+  ]
+}

boost_skill_cli-1.2.36/docs/vex/statements/gitleaks-secretscan-test-fixtures.md

@@ -0,0 +1,15 @@
+---
+id: gitleaks-secretscan-test-fixtures
+vulnerability: "gitleaks:leaked-secret-detection"
+status: not_affected
+justification: vulnerable_code_not_present
+source: .gitleaks.toml, tests/unit/test_secretscan.py
+---
+`tests/unit/test_secretscan.py` exists to prove `boost_cli/core/secretscan.py`
+flags private keys and API tokens, so it ships synthetic examples of both by
+design — strings shaped exactly like the credentials gitleaks' own ruleset
+looks for. gitleaks correctly matches the shape; none of the matched strings
+is a real, working credential, was ever live, or grants access to anything.
+`.gitleaks.toml` allowlists only this one file, by exact path, and the
+allowlist's own comment states why: nothing else in the repository is
+excluded from the scan.

boost_skill_cli-1.2.36/docs/vex/statements/quality-trust-fingerprint-not-sensitive.md

@@ -0,0 +1,22 @@
+---
+id: quality-trust-fingerprint-not-sensitive
+vulnerability: "codeql:py/clear-text-logging-sensitive-data"
+status: not_affected
+justification: vulnerable_code_not_present
+source: boost_cli/commands/quality.py:1248
+---
+CodeQL's `py/clear-text-logging-sensitive-data` query flags
+`boost trust add`'s success line, which prints the trusted key's name and
+minisign fingerprint, because the argument is user-supplied and `fingerprint`
+reads like a credential name. It is not one: the value is a minisign
+**public** key fingerprint, which is meant to be published, and printing it is
+the entire point of the command — it is how a user checks by eye that the key
+they just trusted matches the one the publisher advertises. The class of data
+the query exists to catch (a secret, token, or password) is not present in
+what is logged, so the pattern the rule looks for does not apply here. An
+earlier automated fix that replaced this line with a constant string removed
+the only verification `trust add` offers; the line was restored, the
+suppression carries this reasoning inline
+(`# codeql[py/clear-text-logging-sensitive-data]`), and
+`tests/functional/test_tap_signing.py` pins the output so it cannot be quietly
+dropped a second time.

boost_skill_cli-1.2.36/docs/vex/statements/zizmor-adhoc-packages-lint-runners.md

@@ -0,0 +1,17 @@
+---
+id: zizmor-adhoc-packages-lint-runners
+vulnerability: "zizmor:adhoc-packages"
+status: not_affected
+justification: inline_mitigations_already_exist
+source: .github/zizmor.yml (theme-lint.yml:48, visual.yml:38)
+---
+zizmor's `adhoc-packages` rule flags installing packages without a lockfile,
+because an unpinned install can resolve to a tampered or unexpectedly newer
+package. Two workflows do this on purpose: `theme-lint.yml` installs
+major-pinned linters with `--no-save` into an empty checkout — boost ships no
+`package.json`, so a lockfile would exist solely for this one step — and
+`visual.yml` installs a pinned `puppeteer-core` from
+`tests/visual/package.json`, also `--no-save`. Both run on an ephemeral
+runner, hold only `contents: read`, and their output gates nothing but
+themselves — a compromised lint or screenshot tool in either job cannot reach
+a secret or influence a later, privileged job.

boost_skill_cli-1.2.36/docs/vex/statements/zizmor-dangerous-triggers-workflow-run.md

@@ -0,0 +1,20 @@
+---
+id: zizmor-dangerous-triggers-workflow-run
+vulnerability: "zizmor:dangerous-triggers"
+status: not_affected
+justification: inline_mitigations_already_exist
+source: .github/zizmor.yml (ci-failure-issue.yml:28, publish.yml:19, post-deploy.yml:21, sbom.yml:29)
+---
+zizmor's `dangerous-triggers` rule flags `workflow_run`, because the classic
+failure mode is a privileged run executing pull-request-controlled code. Four
+workflows use it — `ci-failure-issue.yml`, `publish.yml`, `post-deploy.yml`,
+`sbom.yml` — and each carries the mitigation that makes the pattern safe in
+its specific case, recorded inline in `.github/zizmor.yml`: none of them
+checks out the triggering run's head SHA (each explicitly checks out `main`,
+a release tag, or nothing at all), so no code a fork's pull request could
+influence ever runs in the privileged context. `publish.yml`, the one job that
+holds write credentials (PyPI Trusted Publisher OIDC), is additionally scoped
+to `push` events from this repository only — a fork PR opened from a branch
+named `main` cannot satisfy that filter. `sbom.yml` is gated on
+`head_repository == this repository` for the same reason. The remaining two
+hold only `contents: read` and no secrets.