Shapin

The README's ## Support section explicitly documents the support policy (latest release only) and states that upgrading is straightforward since Shapin is a single self-contained binary. The ## Upgrading pinned refs section documents how to upgrade pinned references when updating.

Met. The project uses GitHub Issues as its issue tracker, referenced in both the README (## Support section) and CONTRIBUTING.md.

no vulnerabilities have been resolved in the last 12 months.

SECURITY.md documents the full response process: private reporting channels, 7-day response commitment, fix and release process, public disclosure via GitHub Security Advisory, and CVE request procedure. URL: https://github.com/Kirskov/Shapin/blob/main/SECURITY.md

CONTRIBUTING.md identifies the coding standards under ## Acceptance requirements → Code style: gofmt, go vet, and standard Go conventions. URL: https://github.com/Kirskov/Shapin/blob/main/CONTRIBUTING.md#acceptance-requirements

golangci-lint and gofmt are enforced automatically on every PR via CI. The #nosec and #nolint suppressions in the code are rare and each documented with an inline justification, as required

Shapin is built with the Go toolchain, which does not use CC, CFLAGS, CXX, CXXFLAGS, or LDFLAGS. No native binaries requiring these variables are produced.

Shapin uses the Go toolchain which handles debug information independently of C/C++ flags. Go debug symbols can be controlled via go build -gcflags if needed, but the project produces no C/C++ native binaries requiring CFLAGS/CXXFLAGS handling.

The Go toolchain manages all dependency resolution and build ordering automatically and correctly — there is no recursive make or custom build system.

The project provides multiple standard installation methods: a one-liner install script, manual binary download, and a Docker image in standard OCI format. Uninstallation is straightforward — remove the single binary from /usr/local/bin/.

Shapin is distributed as a pre-built binary with no make install or build-time installation system. Users place the binary wherever they choose — the install script targets /usr/local/bin but users can install manually to any location.

The README.md includes a Build from source section documenting the only prerequisite (Go 1.24+) and the exact build command. The go.mod file specifies the minimum Go version. No additional libraries, frameworks, or SDKs beyond the standard Go toolchain are required. [osps_do_07_01]

Dependencies are listed in go.mod and go.sum — the standard Go module files, processable by the Go toolchain. URL: https://github.com/Kirskov/Shapin/blob/main/go.mod

The grype job in ci.yml runs on every push to main and every PR. It scans the SBOM with Grype, uploads results as SARIF to GitHub Code Scanning, then runs a second gate step with fail-build: true and severity-cutoff: high. The vex.json is passed to suppress documented non-exploitable findings. Once added as a required status check in branch protection, this blocks any merge with unaddressed Critical or High vulnerabilities. [osps_vm_05_03]

The project uses Go modules. go.mod and go.sum at the repository root enumerate all direct and transitive dependencies with pinned versions and checksums, as required by the Go toolchain. [osps_qa_02_01]

The project uses Go 1.25 with modern standard library APIs, and Dependabot is configured to open weekly PRs for outdated dependencies, ensuring deprecated functions are caught and replaced promptly.

The ci.yml workflow runs go test ./... on every push to main and every pull request targeting main. The test suite covers unit and integration tests across all providers and the scanner package. Results are publicly visible in the GitHub Actions tab. Contributors can run the same suite locally with go test ./... — no special environment or secrets required, as all tests use fake HTTP servers via net/http/httptest. [osps_qa_06_01]

CONTRIBUTING.md explicitly requires regression tests for all bug fixes: "Bug fixes must include a test that fails before the fix and passes after." The recent git log confirms this is followed in practice.

CONTRIBUTING.md defines an explicit testing policy that specifies what constitutes a major change (new provider, new CLI flag, regex/parsing changes, bug fixes, scanner logic changes) and requires tests for each. Bug fixes must include a regression test. PRs that reduce coverage without justification are rejected. The full suite must pass before submission. [osps_qa_06_03]

CONTRIBUTING.md defines an explicit testing policy that specifies what constitutes a major change (new provider, new CLI flag, regex/parsing changes, bug fixes, scanner logic changes) and requires tests for each. Bug fixes must include a regression test. PRs that reduce coverage without justification are rejected. The full suite must pass before submission. [osps_qa_06_03]

The CI pipeline runs golangci-lint, gosec, and CodeQL on every push and PR, with Critical/High findings blocking merges. The few suppressions (#nosec) all include explicit justifications. This demonstrates the project is maximally strict where practical.

Fail-safe defaults: dry-run mode is on by default (--dry-run=true), so no files are modified without explicit opt-in
Least privilege: CI uses ephemeral GITHUB_TOKEN with per-job minimum permissions
Complete mediation: every file path is validated via assertWithinRoot before read or write
Economy of mechanism: single self-contained binary, no daemon, no persistent state
Limited attack surface: no network listeners, no stored credentials, only HTTPS outbound calls
Input validation: all file paths validated with allowlist (within root only), HTTPS-only enforced in doWithRetry

Shapin uses Go 1.25's net/http with no custom TLS configuration. Go's default cipher suites are AEAD-only (AES-GCM, ChaCha20-Poly1305) — CBC, RC4, and 3DES are defined as constants but classified as insecure and disabled by default. No weak ciphers are active.

Shapin does not implement or choose cryptographic algorithms — it delegates entirely to Go's TLS stack and registry APIs. There are no user-selectable cryptographic primitives in the project.

API tokens (--github-token, --gitlab-token, --forgejo-token) are passed via CLI flags or environment variables (GITHUB_TOKEN, GITLAB_TOKEN, FORGEJO_TOKEN), completely separate from code and config files. They can be updated at any time without recompilation. If stored in .shapin.json, that file is separate from the binary and documented as sensitive in SECURITY.md.

Shapin uses HTTPS exclusively for all network communications, enforced in doWithRetry which explicitly rejects non-HTTPS URLs (except 127.0.0.1/localhost for tests). There is no mechanism to enable plain HTTP in production.

Go 1.25's crypto/tls enforces TLS 1.2 as the minimum by default. Shapin uses no custom TLS configuration, so this is guaranteed by the runtime.

Shapin uses Go's default http.Client with no custom TLSConfig — certificate verification is enabled by default and InsecureSkipVerify is never set anywhere in the codebase.

All HTTP requests go through doWithRetry which uses Go's default http.Client — TLS certificate verification happens at the transport level before any data (including authorization headers with API tokens) is transmitted.

The "Verify release integrity" section in README.md documents the expected signer identity for both binary and Docker image verification:

Certificate identity: https://github.com/Kirskov/Shapin/.github/workflows/release.yml@refs/tags/vX.Y.Z
OIDC issuer: https://token.actions.githubusercontent.com
These identify the exact GitHub Actions workflow and tag that must have produced the signature, preventing acceptance of signatures from any other identity. This is stored in the README, separate from the release workflow. [osps_do_03_02]

all inputs from untrusted sources are validated with an allowlist: --format is checked against an explicit allowlist (text, json, sarif) and host URLs must start with https://. File paths are validated with assertWithinRoot to prevent directory traversal. No denylists are used.

Go's runtime provides hardening by default (bounds checking, no undefined behavior, memory safety). The project doesn't disable any of these protections and uses gosec in CI to catch security issues.

SECURITY.md now covers all four required elements: threat model, trust boundaries, secure design principles (Saltzer & Schroeder), and common implementation weaknesses (CWE/OWASP) : https://github.com/Kirskov/Shapin/blob/main/SECURITY.md

The project uses gosec, which is specifically designed to detect common Go security vulnerabilities (hardcoded credentials, path traversal, insecure TLS, etc.), and CodeQL, which covers a broad set of CWE-mapped vulnerability patterns.

Shapin is written entirely in Go, which is a memory-safe language.