bitmath

All workflows in .github/workflows/ declare permissions: read-all at top level, and every job-level elevation (security-events: write for SARIF upload, id-token: write for OIDC PyPI publish, contents: write only on the publish job for attaching the SBOM to the GitHub release) is the minimum required for that step. Verifiable at https://github.com/timlnx/bitmath/tree/master/.github/workflows

The workflow_dispatch triggers on bandit.yml, scorecard.yml, and sca.yml accept zero inputs (no inputs: block), so there is no untrusted collaborator-provided data flowing into any pipeline step.

All release assets carry the SemVer version: bitmath-<version>-py3-none-any.whl, bitmath-<version>.tar.gz, and the new bitmath-<version>.cdx.json SBOM. Verifiable on any release at https://github.com/timlnx/bitmath/releases and https://pypi.org/project/bitmath/

The Secrets and Credentials Policy section of SECURITY.md (https://github.com/timlnx/bitmath/blob/master/SECURITY.md) documents what secrets the project handles (none long-lived, PyPI auth via OIDC Trusted Publishing), storage (no secrets in the repo, zero GitHub Actions secrets configured), access control, rotation (short-lived OIDC tokens rotated per workflow run), and incident response.

VERIFICATION.md (https://github.com/timlnx/bitmath/blob/master/VERIFICATION.md) documents SHA-256 hash verification (automatic via pip, plus manual shasum -a 256 instructions cross-referencing PyPI's published hashes) and CycloneDX SBOM verification with cyclonedx-cli. The document lives separately from publish.yml so a single compromise cannot tamper with both the release and the verification instructions.

VERIFICATION.md documents PEP 740 attestation verification via the pypi-attestations CLI, including the expected identity binding (repository timlnx/bitmath, workflow .github/workflows/publish.yml, ref refs/tags/<version>). The Sigstore signing chain backs the attestation, so no long-lived signing key is involved.

SECURITY.md (https://github.com/timlnx/bitmath/blob/master/SECURITY.md) Supported Versions table plus the new "Scope of Support" and "Duration of Support" subsections explicitly state which versions receive security fixes, bug fixes, and functional changes, and what the EOL signaling looks like (12-month overlap on NEWS.rst before a major-version support window ends).

The Duration of Support subsection of SECURITY.md documents that the 2.x series receives security fixes as long as it is the current major, and that a future 3.x release would start a documented deprecation clock on 2.x with at least 12 months of overlap announced in NEWS.rst. The 1.x and pre-1.x series are stated as end-of-life.

MAINTAINERS.md (https://github.com/timlnx/bitmath/blob/master/MAINTAINERS.md) "Becoming a Maintainer" section documents the escalation path: prospective co-maintainers start by regularly landing reviewed contributions and graduate to write access only after trust is established. The current sole-maintainer access is enumerated explicitly.

The publish.yml workflow (https://github.com/timlnx/bitmath/blob/master/.github/workflows/publish.yml) generates a CycloneDX SBOM via cyclonedx-py against the built wheel installed in an isolated venv, and attaches the resulting bitmath-<version>.cdx.json to the GitHub release alongside the wheel and sdist. Verification instructions are in VERIFICATION.md.

bitmath is a single-repository project with no subprojects compiled into the release.

The "Running the Tests", "Makefile Targets", and "Components" sections of the contributing guide (https://bitmath.readthedocs.io/en/latest/contributing.html) document how to run tests locally (make ci), how they run in CI (full Python 3.9–3.13 × {macOS, Ubuntu, Windows} matrix on every push and PR), what each tool checks, and how to interpret the results.

The "Testing Policy" section of the contributing guide (https://bitmath.readthedocs.io/en/latest/contributing.html#testing-policy) states with explicit MUST language that every major change to the library must be accompanied by tests in the same pull request, with a precise definition of what counts as a major change and what does not.

SECURITY_ASSESSMENT.md (https://github.com/timlnx/bitmath/blob/master/SECURITY_ASSESSMENT.md) is the project's standing threat model, identifying attack surfaces in order of concern (parse_string, filesystem helpers, query_device_capacity, the build/release pipeline) with the mitigations in place at each. The document is reviewed at every minor release per its stated contract.

bitmath has zero runtime dependencies (verifiable in pyproject.toml), so there are no third-party software components against which non-exploitability assessments need to be expressed. The project itself has no known vulnerabilities; the disclosure channel (GitHub Security Advisories) is configured for future use.

SECURITY_POLICIES.md (https://github.com/timlnx/bitmath/blob/master/SECURITY_POLICIES.md) defines CVSS-based remediation thresholds for SCA findings (Critical: 7 days, High: 30 days, Medium: 90 days, Low: best effort) along with a documented suppression rule for non-exploitable findings.

SECURITY_POLICIES.md states that releases MUST NOT ship while a Critical or High SCA finding is unaddressed (unless formally suppressed as non-exploitable), and that the .github/workflows/sca.yml required status check enforces this on the merge path that gates releases.

The .github/workflows/sca.yml workflow runs pip-audit against requirements.txt on every push and pull request. The audit job is configured as a required status check on master in branch protection settings, so any finding blocks merging until resolved.

SECURITY_POLICIES.md defines remediation thresholds for SAST findings from Bandit and CodeQL (High: 7 days for existing findings, immediate block for new ones; Medium: 30 days; Low: best effort) along with a suppression rule that requires an inline justification on any # nosec or # lgtm[] annotation.

Bandit (.github/workflows/bandit.yml) and CodeQL (.github/workflows/codeql.yml) are both in the 18 required status checks on master, so any High SAST finding from either tool blocks merging until resolved.