Signed release assets with SLSA provenance and SBOMs, Atheris fuzzing, and Scorecard fixes

[laithalsaadoon]

Raises the OpenSSF Scorecard checks this repository can move by itself: Signed-Releases, Packaging (after the first publish), Fuzzing and Vulnerabilities. Branch protection is already applied in the repository settings, and RELEASING.md describes it (see the end).

What changes

Signed release assets with provenance and SBOMs (publish.yml, mise run release:assets)

• The build job stages release/ on the tag: the wheel and sdist that go to PyPI, CycloneDX and SPDX SBOMs of the locked runtime closure (uv export --no-dev, converted to SPDX by syft so both describe one set), and SHA256SUMS.
• A new attest job, the only one holding attestations: write, signs SLSA v1 build provenance over every asset and an SBOM attestation over the two distributions with actions/attest (Sigstore, this workflow's OIDC identity), and writes both bundles into atif_sql-<version>.intoto.jsonl.
• A new release-assets job runs gh attestation verify --signer-workflow .../publish.yml on every asset, then scripts/verify_release_assets.py --attestations read at the tag, then gh release upload without --clobber. A stray file, a name that disagrees with the tag, a wrong digest, an SBOM for another version or an asset outside the provenance fails the upload. The PyPI job now also waits on attest.
• RELEASING.md documents the six assets and the verify commands; SECURITY.md points at them.

Vulnerabilities: OpenVEX suppressions reach the docs-site lockfile

• osv-scanner applies the osv-scanner.toml in a lockfile's own directory only. Scorecard's recursive scan therefore reported GHSA-vfj7-8cjw-p6xm and GHSA-ch52-4w7c-c8xp against site/pnpm-lock.yaml even though the ledger argues both. The renderer writes the same render to site/osv-scanner.toml, and security:vex:check drift-gates both copies. osv-scanner scan source -r . (2.6.0): 2 findings before, "No issues found" after.

Fuzzing with Atheris (fuzz/, fuzz.yml, mise run fuzz)

• Harnesses drive the Claude Code and Codex conversion use cases end to end; only DomainError is an accepted rejection. Seeds come from the existing fixtures and replay in mise run check without atheris (an optional fuzz group, Linux x86_64 only). fuzz.yml runs weekly, on dispatch and on pull requests touching the converter or fuzz/.

Three crashes the fuzzer found, fixed (two fix(converter) commits)

• build_edges raised TypeError sorting a non-string uuid; Codex _tool_use_ids and extract_codex_blobs raised TypeError on an unhashable payload type (the third came from this PR's first fuzz.yml run). Every string-set membership test on a transcript field outside the harbor conversion now uses a key that is None for a non-string. The three inputs are kept under fuzz/regressions/ and each fails on the unfixed code. Every input that converted before keeps byte-identical output, so CONVERTER_SCHEMA_VERSION stays 9 and only the source digest is re-pinned.

release.yml pushes through a deploy key

• main requires pull requests and checks, and GITHUB_TOKEN cannot be a ruleset bypass actor; a deploy key can. The job runs in a release environment and refuses a non-dry run without RELEASE_DEPLOY_KEY. RELEASING.md has the one-time setup and, without the key, a fallback that cuts the bump commit through a pull request (cz bump --version-files-only --changelog) and pushes only the tag.

RELEASING.md describes the three main rulesets

• main history (deletion and non-fast-forward refused, no bypass), main checks (the six CI jobs on an up-to-date branch, deploy key bypass only) and main review (two approvals, Code Owner review, last-push approval, resolved threads, stale reviews dismissed; deploy key, plus the admin role for pull requests only). It says why they are split (a bypass skips every rule in its ruleset), how the maintainer merges (gh pr merge --admin once the checks are green), why fuzz and the external link crawl are not required, and gives a read-only command that lists what main enforces.

Verification

• mise run --force check: see the latest CI run; locally 2,604 tests passed, pyright 0 errors, Vale 0 errors at baseline.
• mise run fuzz at 240 s each on the fixed code: claude_code 319,406 runs, codex 422,633 runs, both exit 0.
• New tests: 13 for the release gate (each planted defect red, a well-formed release green, and the workflow order pinned), 3 for the site osv-scanner copy, 3 crash regressions.
• actionlint and zizmor (auditor persona) report no findings on the changed workflows.
• Not run: the publish workflow end to end. It runs for the first time on the next release; the attest and release-assets jobs are checked only statically here.

Repository settings (applied)

These are in place and match RELEASING.md. gh api repos/laithalsaadoon/atif-sql/rules/branches/main --jq '[.[].type]' lists required_status_checks, deletion, non_fast_forward and pull_request.

1. The write deploy key release.yml push, the release environment (deployments from main) and its RELEASE_DEPLOY_KEY secret.
2. Rulesets main history, main checks and main review, as above. This PR therefore reads review required; it merges with gh pr merge --admin once the required checks are green.
3. Immutable releases stay off: assets are attached after the release is published.

🤖 Generated with Claude Code