gh-observer

Users can always install the latest release (gh extension upgrade, go install @latest); older releases remain available on the releases page, and upgrade is a single command — no migration steps, config format is backward compatible. SECURITY.md documents the release support scope.

GitHub's issue tracker is used for individual issues. https://github.com/fini-net/gh-observer/issues

No vulnerability reports have been resolved in the last 12 months.

https://github.com/fini-net/gh-observer/blob/main/.github/SECURITY.md
SECURITY.md documents the response process: confidential disclosure channel, acknowledgment goal, SCA/SAST remediation thresholds with SLAs (14-day goal for critical), and the VEX workflow for tracking non-exploitable findings.
[osps_vm_01_01]

https://github.com/fini-net/gh-observer?tab=contributing-ov-file
CONTRIBUTING.md identifies the coding standards: standard Go conventions (gofmt, Effective Go) for Go code, shellcheck compliance for shell scripts.

Enforcement is automatic: golangci-lint runs in pre-commit and CI (reviewdog comments on PRs); shellcheck runs via pre-commit and CI; CI fails on findings.

The standard Go toolchain (go build) handles compiler and linker environment variables (CGO_ENABLED, GOFLAGS, GOOS/GOARCH, and via GOFLAGS, CC/CFLAGS/LDFLAGS passing) natively; the project adds no build system layer that could drop or override them.

go build embeds DWARF debug info in the binary by default; the project never strips it (no -ldflags "-s -w" in build or release recipes).

The Go build system is package-based with accurate, compiler-verified dependency information; there is no recursive make-style directory walking.

Installation and uninstallation use common conventions: gh extension install/uninstall (the gh CLI's package mechanism), go install for Go users, and precompiled release binaries for manual installation.

Installation is via the gh extension mechanism or go install, both of which honor GOBIN/GOPATH conventions for install location; the project performs no custom file installation that would need DESTDIR.

A developer gets the full environment with standard commands: git clone, go mod download (or just go build — modules fetch automatically), just build, go test ./... — all documented in CONTRIBUTING.md's development process and the README.
[osps_do_07_01]

https://github.com/fini-net/gh-observer/blob/main/go.mod https://github.com/fini-net/gh-observer/blob/main/go.sum
External dependencies are listed in go.mod/go.sum, the computer-processable standard for Go.
[osps_br_05_01]

Dependencies are monitored continuously: govulncheck runs daily (and on every PR) for known Go vulnerabilities; dependency-review scans changed manifests on every PR; Dependabot and Renovate both propose updates on a schedule; findings are triaged per SECURITY.md thresholds, and OpenVEX documents non-exploitable ones.
[osps_vm_05_03]

All external components are declared in go.mod and updated with go get -u / just deps-update; there are no vendored or forked convenience copies (no vendor/ directory), so security updates flow in via a single standard mechanism.
[osps_qa_02_01]

Renovate and Dependabot keep dependencies current, and the codebase is regularly modernized; deprecations surface via golangci-lint and CodeQL findings and are addressed in normal maintenance.

The CI workflow applies the full automated test suite (go test ./...) on every push to main (the shared trunk) and every pull request, and reports pass/fail on each run — visible on every commit.
[osps_qa_06_01]

Yes, bugs are fixed with additional regressions tests where possible.

Whole-project statement coverage is 83.3% (merged go test -coverprofile across all packages; per-package: tui 93.1%, github 88.2%, timing 97.1%, config 97.4%, debug 93.6%), above the required 80%. The TUI render paths, run-mode handlers, and REST/GraphQL decode logic are covered by deterministic table-driven and httptest-backed unit tests.

https://github.com/fini-net/gh-observer/tree/main?tab=contributing-ov-file#testing
The policy is formal and written: CONTRIBUTING.md's Testing section mandates tests for major changes, states CI must pass, and PRs without test updates "may be asked to add tests before merging"; the README echoes it.
[osps_qa_06_03]

The test-adding policy is written down in CONTRIBUTING.md and echoed in the README's Testing section.

https://github.com/fini-net/gh-observer/tree/main?tab=contributing-ov-file#testing [osps_qa_06_03]

Go's compiler is strict by default (unused variables/imports and type errors are fatal), supplemented by golangci-lint's linter set and go vet on every test run.

https://github.com/fini-net/gh-observer/blob/main/docs/THREAT_MODEL.md
The threat model's Secure Design Principles section maps each principle to the implementation: least privilege (ambient token only, no OAuth), fail-safe defaults (unknown states render as unknown; last-good display retained), complete mediation (all API input through validated parsing), economy of mechanism (single binary, no listeners).

govulncheck runs daily in CI and flags known cryptographic weaknesses in the standard library and dependencies; connections use modern TLS (1.2+ with ECDHE, 1.3 preferred) only.

Credentials are never embedded in code, config, or logs: the token comes from the GITHUB_TOKEN environment variable or is delegated to the gh CLI's own secure storage at runtime; users can rotate either without any recompilation.

All network communication is HTTPS (TLS 1.2+, preferring 1.3) to api.github.com and github.com; no plaintext protocols are used or supported anywhere.

Go's crypto/tls defaults to TLS 1.3 minimum on modern Go (1.26); connections to GitHub use at least TLS 1.2 in all configurations.

Go's HTTP client performs standard TLS certificate verification on every request by default; the project never disables it (no InsecureSkipVerify anywhere in the codebase).

Certificate verification happens before any HTTP headers are sent, including the Authorization header with the private token — this is Go's standard TLS handshake-then-request ordering, with verification never disabled.

https://github.com/fini-net/gh-observer/tree/main?tab=security-ov-file#verifying-release-author-identity [osps_do_03_02]
Every release binary is cryptographically signed three independent ways: Sigstore keyless cosign signatures, GitHub build attestations, and SLSA L3 provenance; the README documents how to obtain the public verification material and verify each (cosign verify-blob, gh attestation verify, slsa-verifier). No private signing key is stored on distribution sites — signing is keyless via the release workflow's OIDC identity.

All potentially untrusted input is allowlist-validated: PR/run/repo arguments must match fully-anchored URL or slug regexes; API responses pass through typed decoding with explicit error handling; config values are validated on load. The fuzz targets exercise the parsers with arbitrary input.

Hardening measures: Go's memory-safe runtime and bounds checking; input allowlists on all untrusted data; no network listeners, no plugin loading, no dynamic eval; minimal CI/CD permissions and hardened workflow runners (harden-runner) limit the build path itself.

https://github.com/fini-net/gh-observer/blob/main/docs/THREAT_MODEL.md
The assurance case is docs/THREAT_MODEL.md: it contains the threat model (STRIDE per trust boundary), clearly identified trust boundaries (six crossings, each with mitigations), an argument that secure design principles are applied (Secure Design Principles section), and an argument that common implementation weaknesses are countered (critical code paths CP-1..CP-6 map each weakness to its countermeasure).
[osps_sa_03_01]

CodeQL's Go security query pack checks for common vulnerability classes (CWE-mapped); results upload to GitHub code scanning.

The project is pure Go — memory-safe, no memory-unsafe languages.