pixel

Every workflow is read-only at the top level and grants write permissions only to the job that needs them (release publication, notes edit, code-scanning upload); OpenSSF Scorecard's Token-Permissions check scores 10/10.

Dispatch inputs are passed through environment variables and validated before use: the mutants range must be on the dispatched branch, fuzz seconds must be 1–1200, and harness-grid's pr must be a number (held by scripts/test-harness-grid-input.py).

Every release asset is attached to the vX.Y.Z GitHub release, archives are named pixel-vX.Y.Z-<target>.tar.gz with their .sha256, and the signed provenance attestation names the tag that built each asset.

GOVERNANCE.md defines the secrets policy: credentials are stored only as GitHub encrypted repository secrets (secret scanning with push protection enabled), only the maintainers can access them, each is read by the one workflow that needs it with least-privilege scope, and tokens expire within a year and are revoked and replaced at once on a maintainer change or possible exposure.

URL: https://github.com/Pixel-CLI/pixel/blob/main/GOVERNANCE.md#secrets-and-credentials

SECURITY.md ("Verifying a release") explains how to check each asset's SHA-256 and verify its signed provenance with gh attestation verify.

URL: https://github.com/Pixel-CLI/pixel/blob/main/SECURITY.md#verifying-a-release

The verification command pins the signer identity: --signer-workflow Pixel-CLI/pixel/.github/workflows/release-build.yml, the release tag (--source-ref) and GitHub-hosted runners, so only the project's release workflow on that tag verifies.

SECURITY.md: only the latest release receives security fixes; a release stops receiving them when the next one is published.

SECURITY.md: only the latest release receives security fixes; a release stops receiving them when the next one is published.

GOVERNANCE.md requires both maintainers to review a person's contributions and agree, in a pull request that updates the file, before granting write or admin access to the repository or the Homebrew tap, an organization seat, or access to a secret.

URL: https://github.com/Pixel-CLI/pixel/blob/main/GOVERNANCE.md#granting-access

Each release archive ships with a CycloneDX SBOM (pixel-vX.Y.Z-<target>.cdx.json) listing exactly the crates compiled into it, covered by the release's signed provenance attestation; see SECURITY.md, "Software bill of materials".

Releases are built from a single repository; LivioGama/homebrew-tap only receives the formula the release workflow generates.

CONTRIBUTING.md ("Gates", "Tests: where they live") documents the test commands and that GitHub Actions runs them on every pull request and push to main, with mutation testing nightly.

CONTRIBUTING.md's Definition of done requires every behaviour change to add or update a test that fails without it, enforced by mutation testing on each pull request.

docs/threat-model.md is the project's threat model and attack surface analysis: the assets, the actors and trust boundaries, every entry point (CLI, daemon socket, agent hooks, file parsing, the .pixel/ sidecars, git operations, network access, installation and updates, CI and the release chain), each threat with the mitigation in the code and its residual risk, and how the critical paths are tested (unit and integration tests, mutation testing, fuzzing, CodeQL). CONTRIBUTING.md requires a pull request that crosses a trust boundary to update it, and the release procedure reviews it before each release.

URL: https://github.com/Pixel-CLI/pixel/blob/main/docs/threat-model.md

No known vulnerability affects Pixel's dependency tree; the two accepted RustSec entries are informational "unmaintained" notices, documented with their reason in osv-scanner.toml.

CONTRIBUTING.md's dependency policy: cargo-deny fails CI on any RustSec advisory or license outside the allow-list; the only accepted exceptions are listed with their reason in deny.toml and osv-scanner.toml.

The release workflow runs cargo deny check on the tag before anything is built; an advisory published since the last dependency change blocks the release until fixed or accepted with its reason (CONTRIBUTING.md, dependency policy).

Every pull request is evaluated by cargo-deny against deny.toml (RustSec advisories for vulnerable, malicious-flagged and unmaintained crates, a licence allow-list, crates.io as the only source). The main branch ruleset makes it a required status check, so a violation blocks the merge; accepted exceptions are declared with their reason in deny.toml and osv-scanner.toml. Maintainers can bypass only explicitly, through GitHub's bypass option, which the pull request records. The shipped software is Rust only; the JavaScript manifests are documentation tooling and are not distributed.

URL: https://github.com/Pixel-CLI/pixel/blob/main/CONTRIBUTING.md#gates-run-before-every-pr

SECURITY.md sets the SAST remediation threshold: no merge with a new CodeQL finding of medium severity or higher unless fixed or dismissed with a written reason; high and critical findings on main fixed within 14 days, medium within 30, low by the next release; Clippy warnings fail CI.

URL: https://github.com/Pixel-CLI/pixel/blob/main/SECURITY.md#static-analysis-findings

Every pull request is analysed by CodeQL (Rust, GitHub Actions, Python, JavaScript/TypeScript). The main branch ruleset requires code scanning results: a security alert of medium severity or higher, or any error-level alert, blocks the merge unless it is dismissed in code scanning with a written reason, as SECURITY.md ("Static analysis findings") requires. Maintainers can bypass only explicitly, through GitHub's bypass option, which the pull request records.

URL: https://github.com/Pixel-CLI/pixel/blob/main/SECURITY.md#static-analysis-findings