Please report suspected vulnerabilities privately through GitHub private vulnerability reporting when available. If that is not possible, email [email protected] with reproduction steps and the affected commit or image version. Do not include live credentials, signed download URLs, account data, or copyrighted archives in a report unless the maintainers explicitly request a secure transfer.

Direct-download providers are untrusted discovery services. A supported deployment must keep each provider on a private network and must not grant it:

• Pullbox data, config, import, download, quarantine, or library mounts.
• Database access, Pullbox sessions, or artifact-host account credentials.
• The Docker socket, privileged mode, added Linux capabilities, or persistent queues.
• A public host port unless an operator deliberately accepts that risk.

Providers require a unique bearer token containing at least 32 characters. Pullbox remains responsible for semantic matching, artifact planning, downloads, archive validation, post-processing, history, and library state.

The synthetic provider and fixtures contain generated test data only. Never commit source-account credentials, signed URLs, cookies, personal information, or downloaded publications to this repository.

Pull requests run secret scanning, strict Python dependency auditing, Bandit, dependency review, CodeQL extended security queries, workflow linting, runtime smoke tests, multi-architecture builds, and Grype image scans. Public and fork pull requests run on GitHub-hosted runners with read-only default permissions; pull request workflows do not publish images or receive registry credentials.

The pinned Python base image currently has reviewed upstream findings that are tracked in .github/security/container-vulnerability-baseline.json. The baseline is not a suppression of scanner output: new High or Critical findings fail CI, full reports remain available as CI artifacts, and every accepted entry requires an owner, evidence link, rationale, review date, and expiry date. Acceptance is limited to the reviewed package version, ecosystem, advisory namespace, platform, and unfixed status. An available fix, changed package, expired review, or malformed report fails the gate. The image base label must match the reviewed digest; this is a build-consistency check, not attestation.

Both AMD64 and ARM64 runtime images are scanned. JSON and SARIF come from one pinned Grype invocation. Only unreviewed High or Critical findings are uploaded to the actionable code-scanning dashboard when review metadata is valid; if it is invalid, the raw SARIF is uploaded instead. Full reports always remain CI artifacts. Base image and dependency updates should remove resolved entries.

The weekly Published Container Security workflow separately pulls the highest stable release of each source provider by immutable digest and scans both platforms without rebuilding or publishing anything. Published releases outside the current reviewed base fail visibly; this deliberately catches the gap between patched source and images still in users' hands. Their findings use separate published-<provider>-<arch> categories. Merging a patch does not fix an already published image: a new release and user upgrades are still required.

Only provider-prefixed semantic-version tags can publish production images. The release workflow builds Linux AMD64 and ARM64 images by immutable digest, checks the reviewed vulnerability baseline, smoke-tests the hardened candidate, and only then creates runnable tags in GHCR and Docker Hub. Both registries must resolve to the same digest before the image is signed.

Every release image includes SBOM and provenance attestations and is signed in both registries with keyless Sigstore/Cosign through GitHub Actions OIDC. The GitHub Release is created only after both signatures are verified. Operators should pin a numbered version or digest and use the verification commands in the corresponding GitHub Release notes.