httptap

Every CI job declares explicit minimum permissions at the job level (e.g., security-events: write only for SARIF uploads, id-token: write only for OIDC publishing). Workflow-level default is permissions: {} so no ambient privileges are inherited. Enforced on every PR by zizmor persona=pedantic; Scorecard Token-Permissions check scores 10/10. See any workflow under .github/workflows/.

Trusted-collaborator inputs (e.g., inputs.version, inputs.bump in the Release workflow) are passed through env: blocks and consumed as environment variables rather than interpolated into shell strings. Every workflow is audited by zizmor persona=pedantic, which catches template-injection patterns on every PR. No findings to date.

Each release has a unique semantic version identifier (e.g. 0.4.7) assigned in pyproject.toml, published to PyPI (https://pypi.org/project/httptap/#history), and tagged as vX.Y.Z in git (https://github.com/ozeranskii/httptap/tags). [version_unique]

Secrets policy documented in SECURITY.md and GOVERNANCE.md:

• Long-lived secrets are avoided; PyPI publishing uses GitHub OIDC Trusted Publishing (no PyPI tokens stored).
• Release artifact signing uses Sigstore keyless OIDC (Fulcio-issued ephemeral certs).
• Only secrets.GITHUB_TOKEN and DEPLOY_KEY exist in the repo; DEPLOY_KEY is scoped to the release GitHub Environment and rotatable via Settings → Environments.
• Secret scanning + push protection enabled on the public repository.
  References: https://github.com/ozeranskii/httptap/blob/main/SECURITY.md and https://github.com/ozeranskii/httptap/blob/main/GOVERNANCE.md#releases

Release artifacts (wheel, sdist) are signed via Sigstore keyless signing and ship SLSA v1.0 build provenance via actions/attest-build-provenance; verification: gh attestation verify dist/httptap-*.whl --repo ozeranskii/httptap. Signing keys are ephemeral (issued per-run by Sigstore Fulcio), never stored on PyPI. https://github.com/ozeranskii/httptap/blob/main/.github/workflows/release.yml [signed_releases]

Release artifacts (wheel, sdist) are signed via Sigstore keyless signing and ship SLSA v1.0 build provenance via actions/attest-build-provenance; verification: gh attestation verify dist/httptap-*.whl --repo ozeranskii/httptap. Signing keys are ephemeral (issued per-run by Sigstore Fulcio), never stored on PyPI. https://github.com/ozeranskii/httptap/blob/main/.github/workflows/release.yml [signed_releases]

Support scope and duration documented in SECURITY.md (Supported Versions) and GOVERNANCE.md (Releases). Currently the 0.4.x minor series receives security patches; prior minor series are not supported. Semver 2.0.0 is followed and breaking changes are flagged in CHANGELOG.md. https://github.com/ozeranskii/httptap/blob/main/SECURITY.md

SECURITY.md's Supported Versions table explicitly states which minor series still receive security updates and which do not. The project follows an N/N-1 policy: at any point in time, only the current minor series is supported; older minors stop receiving security updates the moment the next minor is released. Documented in SECURITY.md and ROADMAP.md. https://github.com/ozeranskii/httptap/blob/main/SECURITY.md

GOVERNANCE.md documents the policy: write/admin access to the repository, PyPI publishing, and the release GitHub Environment is granted only after explicit maintainer review. New collaborators receive read-only permissions by default (GitHub platform behaviour); any escalation requires a GOVERNANCE.md update and a maintainer decision. https://github.com/ozeranskii/httptap/blob/main/GOVERNANCE.md#roles

Every GitHub Release attaches a software bill of materials in both CycloneDX JSON (httptap-X.Y.Z.cdx.json) and SPDX JSON (httptap-X.Y.Z.spdx.json) formats, generated by anchore/sbom-action (Syft) during the release workflow's build job. Verifiable at https://github.com/ozeranskii/httptap/releases.

The project consists of a single source code repository (ozeranskii/httptap). There are no subprojects to subject to comparable or stricter security requirements.

The project uses pytest (MIT-licensed FLOSS) for automated testing. Tests live under tests/ and are invoked via uv run pytest. Running instructions are in README.md and CONTRIBUTING.md. Tests are executed on every PR and push via GitHub Actions CI: https://github.com/ozeranskii/httptap/actions/workflows/ci.yml [test]

Formal written policy in CONTRIBUTING.md requires tests for all major new functionality; enforced in PR review and via CI coverage gates. https://github.com/ozeranskii/httptap/blob/main/CONTRIBUTING.md [test_policy_mandated]

Branch protection on main requires pull requests, disallows direct pushes, enforces status checks, and requires codeowner review. [osps_ac_03_01] [two_person_review]

The assurance case (threat model, trust boundaries, applied secure-design principles, countered common implementation weaknesses) is documented at https://docs.httptap.dev/security/assurance-case/ [assurance_case]

The project maintains an OpenVEX (https://github.com/openvex/spec) document at .vex/httptap.openvex.json that records, for every CVE published against a direct or transitive dependency, whether httptap itself is exploitable. The document is version-controlled (history tracks every exploitability assessment), updated as part of the vulnerability response process documented in SECURITY.md, and automatically attached to every GitHub Release as httptap-X.Y.Z.openvex.json alongside the CycloneDX and SPDX SBOMs. Downstream scanners (Grype, Trivy, Snyk) consume the VEX document to suppress false-positive alerts on vulnerable code paths that are not reachable from httptap.

Dependabot (weekly security and version updates via .github/dependabot.yml), CodeQL vulnerability queries, and GitHub native dependency-graph alerts on uv.lock monitor direct and transitive dependencies continuously. [dependency_monitoring]

Dependabot (weekly security and version updates via .github/dependabot.yml), CodeQL vulnerability queries, and GitHub native dependency-graph alerts on uv.lock monitor direct and transitive dependencies continuously. [dependency_monitoring]

Dependabot (weekly security and version updates via .github/dependabot.yml), CodeQL vulnerability queries, and GitHub native dependency-graph alerts on uv.lock monitor direct and transitive dependencies continuously. [dependency_monitoring]

CI fails on any CodeQL / ruff / mypy / zizmor finding, so medium+ severity issues cannot be merged; main is kept clean at all times. [static_analysis_fixed]

CodeQL (SAST), ruff, mypy strict, and zizmor (pedantic) run on every PR and push via GitHub Actions. [static_analysis]