bouine

bouine maintains older versions and provides documented upgrade paths. The SECURITY.md supported-versions table shows the latest minor receives security fixes and the previous minor is supported for 6 months. The CHANGELOG.md (Keep a Changelog format, SemVer) documents all notable changes per release, with breaking changes explicitly flagged (e.g., "Breaking (SDK): removed Client.Reload "). The cluster protocol maintains an N/N-1 compatibility window for rolling upgrades, documented in docs/architecture.md §5 . Migration guides exist for Varnish (docs/migration/varnish.md ), NGINX ( docs/migration/nginx.md ), and cluster mode changes ( docs/migration/cluster-mode.md ). The Go SDK ( pkg/bouineapi ) follows semver — wire types in pkg/api are additive, and breaking changes require a major version bump with a migration note per AGENTS.md §13.

The project uses GitHub Issues at https://github.com/bouine-cache/bouine/issues, referenced in the README and CONTRIBUTING.md.

No vulnerabilities raised in the past 12 months.

URL: https://github.com/bouine-cache/bouine/blob/main/SECURITY.md#vulnerability-response-process

SECURITY.md documents a six-step vulnerability response process: (1) triage within 3 business days with severity assignment, (2) assess and reproduce within 1 week, (3) develop a fix on a private branch with maintainer review, threat model update, and CHANGELOG entry, (4) release a signed tagged release (out-of-band for critical, batched for medium/low), (5) publish GHSA advisory and request CVE, (6) post-release review within one week to strengthen
controls. Reporters receive weekly status updates during the embargo, and target fix timeframes are 30 days for high-severity and 90 days for medium-severity issues.

URL: https://github.com/bouine-cache/bouine/blob/main/AGENTS.md#4-coding-standards-go-126 (with CONTRIBUTING.md#coding-standards-summary as the human-facing entry point)

bouine's primary (and only) language is Go 1.26. The coding style guide is documented in AGENTS.md §4 and summarized in CONTRIBUTING.md § "Coding standards" . It identifies specific style guides and rules: gofmt -s + goimports for formatting, 100-column soft limit, idiomatic Go naming (short receivers, no Hungarian notation), no panic outside main, no init() doing work, no global mutable state, context.Context as first argument for I/O
functions, no bare goroutines, no reflection on the hot path, comments explain why and cite RFC clauses. Enforced automatically via golangci-lint (17 linters including govet , staticcheck , errcheck , gosec , gocritic , revive depguard , gocyclo , funlen , forbidigo ) in prek hooks and CI. Contributions must comply — the PR checklist in CONTRIBUTING.md requires prek run --all-files to pass.

bouine automatically enforces its Go coding style via multiple FLOSS tools, all configured in the repository:Formatters (in .golangci.yaml ):

• gofmt -s (simplify) — enforces standard Go formatting
• goimports with local prefix github.com/bouine-cache/bouine Linters (17 enabled in .golangci.yaml , mandated by AGENTS.md §14.4 ):
• govet , staticcheck , errcheck , gosec , bodyclose , contextcheck , noctx , nilerr , gocritic , revive ,
  forbidigo , gocyclo (≤15), funlen (≤80), depguard (layer enforcement), unparam , ineffassign , unused ,
  misspell
  Enforcement points:
• prek pre-commit hook — runs gofmt -s , golangci-lint --new-from-rev=HEAD~ on changed lines, go mod tidy check,
  go test -race -short on every commit
• prek pre-push hook — runs full go test -race and govulncheck
• CI ( ci.yml ) — re-runs prek run --all-files as its first stage, so bypassed local hooks still fail the build Style exceptions are rare and must be documented at their location (e.g., gosec suppressions require a comment citing the threat model per AGENTS.md §6 ).

bouine is pure Go (no import "C" ), but produces native binaries and uses CGO_ENABLED=1 in CI for the race detector. The build system honors relevant compiler/linker variables:

• GO — respected via ?= in the Makefile, so GO=gccgo make build works
• GOFLAGS — respected via ?= and passed to go build
• CC — honored by the Go toolchain when CGO is enabled (used by the race detector)
• CGO_CFLAGS , CGO_CXXFLAGS , CGO_LDFLAGS — honored by the Go toolchain for cgo compilation
• LDFLAGS — the Makefile now uses += to append project-specific Go -ldflags to any caller-provided LDFLAGS , so distribution hardening flags or ASAN-related linker options are passed through rather than overwritten
  This makes it easy to enable special build features like ASAN ( CGO_CFLAGS="-fsanitize=address" CGO_LDFLAGS="-fsanitize=address" make build ) or distribution hardening flags.

The build system preserves debugging information when requested. Symbol stripping ( -s -w ) is now controlled by a STRIPFLAGS variable (default: -s -w ) in both the Makefile and Dockerfile. To produce a debug build with full DWARF info and symbol table:

• Makefile: make build STRIPFLAGS=
• Dockerfile: docker build --build-arg STRIPFLAGS= .
  The Go toolchain natively generates DWARF debug info; the strip flags were the only thing removing it. With STRIPFLAGS=empty, go tool nm and go tool objdump work on the resulting binary, and hardening audit tools can inspect the binary No install -s is used anywhere in the build or installation process.

bouine uses a single Go module ( go.mod at repo root). The build command go build ./cmd/bouine invokes the Go toolchain, which resolves all cross-package dependencies through the import graph — there are no recursive make -C subdir calls, no per-subdirectory Makefiles, and no recursive build hierarchy. The Makefile is a thin wrapper with a single build target that calls go build once. The Go toolchain guarantees correct dependency ordering across packages within the module.

bouine supports bit-for-bit reproducible builds via SOURCE_DATE_EPOCH.

The build already uses - trimpath (strips filesystem paths from the binary) and CGO_ENABLED=0 in the Dockerfile (eliminates C compiler variability). The remaining non-determinism was the build timestamp injected via -ldflags -X ...buildinfo.Date= . When SOURCE_DATE_EPOCH is set, both the Makefile and Dockerfile derive a stable ISO timestamp from it instead of using date -u . Verified: two consecutive builds with SOURCE_DATE_EPOCH=1700000000 make build produce identical SHA-256 checksums

bouine provides multiple commonly-used installation and uninstallation methods:

• Homebrew (macOS): brew install bouine-cache/bouine/bouine / brew uninstall bouine-cache/bouine/bouine
• Go install: go install github.com/bouine-cache/bouine/cmd/bouine@latest
• Docker (standard OCI container image on Docker Hub): docker pull bouinecache/bouine:latest / docker rmi bouinecache/bouine:latest
• Helm (Kubernetes package manager, chart published on Artifact Hub): helm install bouine bouine/bouine / helm uninstall bouine
• Prebuilt binaries: downloadable from GitHub Releases with standard tar -xzf extraction

All four are commonly-used conventions. The Helm chart and Docker image are the primary distribution channels for
production deployments.

The Makefile provides make install and make uninstall targets that honor the DESTDIR environment variable, the standard POSIX convention for staged installs. The install location is controlled by PREFIX (default: /usr/local ), so make install DESTDIR=/tmp/staging PREFIX=/opt/bouine writes to /tmp/staging/opt/bouine/bin/bouine . Both targets use the standard install command with explicit permissions (0755). Verified: install writes the binary, uninstall removes it.

make setup-dev provides a one-command setup that installs all development tools ( golangci-lint , govulncheck , gitleaks , templ ), downloads Go module dependencies, installs prek hooks, and verifies the build and short tests pass. The only prerequisites are Go 1.26.x (pinned in go.mod ), prek (installed via brew / pip / uv ), and Docker (for integration/conformance tests). The target is documented in CONTRIBUTING.md § "Setting up" and AGENTS.md §14.1 , and uses commonly-used conventions: go install for tool installation, go mod download for dependencies, and make for orchestration.

URL: https://github.com/bouine-cache/bouine/blob/main/go.mod

The project uses Go modules: go.mod enumerates all direct dependencies, and go.sum pins their
checksums. CI enforces hygiene with a go mod tidy pre-commit hook ( .pre-commit-config.yaml ) that fails if go.mod / go.sum drift, plus govulncheck on pre-push and in CI. [osps_qa_02_01]

bouine monitors external dependencies through multiple mechanisms:

1. govulncheck — runs in CI ( .github/workflows/ci.yml , on every push) and as a pre-push prek hook ( .pre-commit-config.yaml ). It analyzes the Go dependency graph against the Go vulnerability database and reports known vulnerabilities in direct and transitive dependencies.
2. Dependabot ( .github/dependabot.yml ) — automatically checks for outdated dependencies weekly across Go modules, GitHub Actions, and Docker base images. Grouped updates for OTel and golang.org/x packages. Creates PRs to bump versions, which triggers CI including govulncheck.
3. Trivy ( release.yml ) — scans the released container image for HIGH/CRITICAL vulnerabilities ( exit-code: 1 ) before publishing. Blocks releases if exploitable vulnerabilities are found.
4. docs/deps.md — the dependency allow-list includes a manual license audit of the production build graph, and every new dependency requires an ADR and a security review pass per AGENTS.md §5.

The project uses Go modules: go.mod enumerates all direct dependencies, and go.sum pins their
checksums. CI enforces hygiene with a go mod tidy pre-commit hook ( .pre-commit-config.yaml ) that fails if go.mod / go.sum drift, plus govulncheck on pre-push and in CI. [osps_qa_02_01]

bouine avoids deprecated or obsolete functions and APIs through automated enforcement. staticcheck is enabled in .golangci.yaml and runs in prek hooks and CI. Its SA1019 check (which flags use of deprecated APIs) is not suppressed anywhere in the project. The only staticcheck exclusion is SA5011 in test files (a known false positive with t.Fatal ). Dependabot bumps dependencies weekly, ensuring the project stays on current API versions. The Go toolchain is pinned to 1.26.x via go.mod . The one internal // Deprecated: comment in responsewriter.go marks an internal API that callers should not use; it is not a deprecated external API.

The test-linux job in .github/workflows/ci.yml runs go test -race -count=1 -timeout=120s -coverprofile=coverage.out ./... on every pull request and every push to main . It produces a visible pass/fail report in the GitHub Actions UI and prints a coverage summary ( go tool cover -func ). Coverage results are uploaded to Codecov for trend tracking. Additionally, the test-arm job runs the same test suite on ubuntu-24.04-arm for architecture coverage on PRs. The prek job runs go test -race -short as a pre-commit hook mirror. All jobs gate merging — a test failure blocks the PR.

An audit of substantive bug fix commits in the last 6 months shows that every fix included regression tests in the same commit.

Examples: 84fa0f0 (purge deletes Vary variants) added tests in handler_test.go and tiered_test.go ; b566ba1 (Vary:* non-matchable) added tests in vary_test.go ; c3ee147 (tombstone queue overflow) added tests in tiered_test.go ; 2d641a1 (reflected-XSS) added tests in handler_invalidation_test.go ; b9f3333 (attacker-controlled route label) added tests in dataplane_source_test.go ; 847e4cd (SWR use-after-close) added tests in handler_test.go . This far exceeds the 50% threshold. The AGENTS.md working loop (§16) and PR checklist require "Tests added or updated; coverage not reduced" for every change, and the prek hook runs go test -race -short on every commit.

The production code has 87.9% statement coverage (measured with go test -coverprofile across all non-test-infrastructure, non-generated packages). Every production package individually exceeds 80%:

• internal/cache : 91.9%, internal/admin : 96.5%, internal/server : 80.1%, internal/config : 80.3%, internal/origin : 81.1%, internal/storage : 81.7%, internal/cluster : 84.0%, internal/cloudflare : 91.7%, internal/dashboard : 93.4%, internal/dashboard/insights : 88.1%, pkg/api : 98.5%, pkg/bouineapi : 97.9%
• 6 packages are at 100%: observability/accesslog , observability/responsewriter , platform , runtime/shutdown, storage/cachaner , storage/evictor

The total across all packages (including test infrastructure at 0% and generated templ code) is 56.6%, but the 0% packages are: cmd/bouine (4-line main() ), internal/testutil/testkey (no test files, test helper), and internal/dashboard/templates (generated _templ.go files, not manually editable). The FLOSS tool ( go test -coverprofile ) measures coverage per-package; the aggregate of 87.9% across production packages meets the 80% threshold.

URL: https://github.com/bouine-cache/bouine/blob/main/AGENTS.md#8-testing-rules

Justification: AGENTS.md §8 contains a formal written policy: "When major new functionality is added to the software tests for that functionality MUST be added to an automated test suite in the same pull request. A PR that adds major functionality without tests will be rejected by reviewers and will fail the CI gate." The policy defines "major new functionality" as any change that adds a new user-visible capability, configuration option, API endpoint, or code path
in the cache, storage, cluster, or server layers. It is reinforced in CONTRIBUTING.md § "Testing discipline" and in the PR checklist.

The test-adding policy is documented in CONTRIBUTING.md ("The working loop", step 4: "Implement smallest reasonable change, follow neighboring patterns, add tests as you go") and in the PR checklist ("Pull request checklist": "Tests added or updated; coverage not reduced"). AGENTS.md mandates "Add tests as you go, not at the end" and requires "Tests added/updated; coverage not reduced" on every PR.

The project is maximally strict with warnings:

• 19 linters enabled in .golangci.yaml (govet, staticcheck, errcheck, gosec, bodyclose, contextcheck, noctx, nilerr, gocritic, revive, forbidigo, gocyclo ≤15, funlen ≤80, depguard, unparam, ineffassign, unused, misspell, lll)
• forbidigo bans fmt.Println , panic , os.Exit outside main
• depguard enforces architectural layer boundaries
• Pre-commit hook runs golangci-lint on every commit ( --new-from-rev=HEAD~ )
• CI re-runs prek run --all-files as first stage
• govulncheck runs on pre-push and CI
• -race flag always on in CI and pre-commit tests
• Coverage gates: ≥85% per package, ≥95% for cache / storage

docs/security/threat-model.md §2.1 documents how bouine implements secure design principles, with concrete examples for each:

• Fail-safe defaults — admin API denies by default (401 without token), upstream TLS verification on by default, Set-Cookie responses not cached by default, container runs non-root with read-only rootfs by default
• Complete mediation — every admin write request authenticated through a single middleware chain with no bypass; every data-plane request passes through route matcher and RFC 9111 freshness evaluation; peer-fetch requires mTLS on every call
• Least privilege — non-root container with dropped capabilities, minimal CI permissions, admin token scoped to admin ops only, separate CAs for data-plane and cluster mTLS
• Economy of mechanism — single HTTP stack ( net/http ), declarative YAML config (no eval), no web framework
• Defense in depth — smuggling defenses + header hygiene + private response protection + path traversal prevention + resource limits, each layer independent
• Separation of privilege — separate admin and data ports, separate cluster and data-plane CAs, tokens in env vars not config files
• Psychological acceptability — secure defaults documented in Helm chart and SECURITY.md hardening checklist, insecure options require explicit opt-in

Go's TLS 1.2+ default cipher suites prefer AEAD modes (GCM, ChaCha20-Poly1305) and exclude SHA-1-dependent suites. CBC mode is not used in SSH (bouine doesn't implement SSH). xxhash is used for cache keys (non-cryptographic, no security claim). crypto/sha256 is used for checksums. No SHA-1 or CBC mode dependencies.

bouine supports multiple cryptographic algorithms through Go's crypto/tls package, which provides algorithm agility by default:

• TLS 1.3 (preferred when MinVersion >= 1.3 ): AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305 for symmetric encryption; SHA-256, SHA-384 for transcript hashing. The cipher suite list is managed by Go's stdlib and cannot be customized for TLS 1.3 (all suites are AEAD, all are secure).
• TLS 1.2 (minimum supported): Go's default cipher suite list includes AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 — multiple symmetric algorithms so users can switch if one is broken. The CipherSuites field on tls.Config is available for operators to further restrict or reorder suites via the TLS config struct.
• Hash algorithms: Go's stdlib provides SHA-224, SHA-256, SHA-384, SHA-512 (SHA-2 family) and SHA-3. bouine uses these
  for TLS transcript hashing and certificate verification. Cache keys use xxhash (non-cryptographic, by design — performance-critical path).
  If a cipher or hash is found broken, operators can update Go's toolchain (which updates the default suite list) or pin specific cipher suites via the TLS config. No code change is required to switch algorithms.

bouine supports storing authentication credentials and private cryptographic keys in files separate from configuration:

• Admin bearer token — can be set via ${ADMIN_TOKEN} env var expansion in the YAML config (the loader supports ${VAR} substitution), or left empty to auto-generate a random token at startup. The token value is never compiled into the binary. Operators can rotate it by changing the env var or config value and restarting — no recompilation.
• TLS private keys — the TLS config struct references cert and key files by path ( cert_file , key_file ), loaded at runtime from disk. Operators replace the files on disk and restart to rotate — no recompilation, no config change needed if the paths stay the same.
• Cluster mTLS keys — the cluster config ( ClusterTLS struct) similarly references cert_file and key_file by path loaded at runtime.
• Origin mTLS client certs — upstream pool TLS config references cert/key files by path. All credentials and keys are in separate files or environment variables, never hardcoded, and can be updated and replaced without recompilation.

bouine supports secure protocols for all network communications, with insecure protocols disabled by default:

• Data plane: HTTP/1.1 and HTTP/2 over TLS (HTTPS). Minimum TLS version is 1.2 ( tls.Config{MinVersion: tls.VersionTLS12} in listener.go:143 ), configurable to 1.3. Plaintext HTTP (h2c) is available only via explicit configuration for in-mesh traffic; the default Helm chart enables TLS.
• Cluster (peer-to-peer): mTLS required for all gossip and peer-fetch traffic. Separate CA from the data plane. No plaintext cluster communication is supported.
• Origin (upstream): TLS verification enabled by default ( insecure_skip_verify refused in release builds). Optional mTLS for client cert authentication.
• Admin API: Separate port, bearer token or mTLS authentication. The Helm chart binds it to cluster-internal only by default (not exposed to the Internet).
• Insecure protocols disabled by default: SSLv3 and earlier are not supported (Go's crypto/tls minimum is TLS 1.0, but bouine sets the minimum to 1.2). FTP, telnet, SSHv1 are not used. insecure_skip_verify is refused in release builds. The admin API rejects insecure HTTP for write methods.

bouine requires at least TLS 1.2 on all TLS surfaces.

The HTTPS listener sets tls.Config{MinVersion: tls.VersionTLS12} by default ( internal/server/listener.go:143 ). The minimum version is configurable via tls.min_version in the config ( internal/config/config.go:101 ), but the default and minimum supported value is 1.2. Cluster mTLS and origin TLS also inherit Go's secure defaults with TLS 1.2 as the floor. The test utility (internal/testutil/tlsutil/tlsutil.go:92 ) explicitly asserts MinVersion >= tls.VersionTLS12 .

bouine performs TLS certificate verification by default on all TLS surfaces:

• Origin (upstream) TLS — Go's default tls.Config performs full certificate verification ( InsecureSkipVerify: false is the Go default). There is no InsecureSkipVerify field in the production config or origin/peer-fetch code. The threat model (T02) confirms: "TLS verify enabled by default; insecure_skip_verify refused in release builds."
• Cluster mTLS — peer-fetch and gossip use a tls.Config with certificate verification enabled (separate CA, mutual verification).
• Data-plane TLS — the HTTPS listener terminates TLS with standard certificate verification; clients verify the server certificate.
• Admin API — when mTLS is configured, client certificates are verified.
  The only InsecureSkipVerify: true occurrences are in test files ( broadcast_test.go:342 , listener_test.go:96 ), both annotated with //nolint:gosec // G402: test-only . No production code disables certificate verification.

bouine performs TLS certificate verification before any HTTP headers (including private ones) are sent. Go's net/http client and server establish the TLS handshake (including certificate verification) before any HTTP data is exchanged — this is inherent to the TLS protocol (handshake completes before application data flows). Since InsecureSkipVerify is false by default in all production code paths (confirmed: no InsecureSkipVerify in non-test origin, cluster, or server code), certificate verification always completes before HTTP headers with private information (such as Authorization , Cookie , admin bearer tokens) are sent to origin or peers.

URL: https://github.com/bouine-cache/bouine/blob/main/README.md#verifying-release-signatures

All releases are cryptographically signed using cosign with keyless signing (Sigstore, via GitHub Actions OIDC). The release.yml workflow signs both the binary checksums ( cosign sign-blob ) and the Docker image ( cosign sign ). The private key is never stored on any distribution server — signatures are generated in CI using ephemeral OIDC credentials tied to the GitHub workflow. The README documents the verification process with step-by-step commands for both binary releases ( cosign verify-blob ) and Docker images ( cosign verify ), including the certificate identity and OIDC issuer to trust. An SPDX SBOM is also generated for each release.

Release tags are annotated tag objects created by the maintainer.

While the tags themselves are not GPG-signed, each tag triggers the release.yml GitHub Actions workflow which produces cosign-signed artifacts (binary checksums and Docker images) using keyless Sigstore signing tied to the GitHub OIDC identity of the workflow. The certificate identity is bound to refs/tags/v* in the bouine-cache/bouine repository, so the signature proves the release was built from that specific tag by the official CI pipeline. Users verify via cosign verify-blob as documented in the README. Additionally, git tags could be GPG/SSH-signed in the future for defense-in-depth, but the cosign-signed release artifacts already provide cryptographic verification of the release provenance.

bouine validates all inputs from potentially untrusted sources using allowlist and bounds-checking patterns:
HTTP data plane — MaxHeaderBytes 64 KiB, ReadHeaderTimeout 10s, MaxConnections configurable, fast-path H1
parser caps at 100 headers and 16 KiB read buffer, HTTP smuggling detection rejects CL+TE conflicts and duplicate Content-Length.Admin API — MaxBodyBytes (default 1 MiB) enforced via http.MaxBytesReader , batch purge capped at MaxBatchSize (default 1000) with empty-entry rejection, JSON decoder uses DisallowUnknownFields() , regex ban predicates validated via regexp.Compile before use, bearer token checked with subtle.ConstantTimeCompare .Config validation — Config.Validate() checks: pool names unique, routes reference valid pools, HTTP methods validated against an 8-method allowlist ( isKnownHTTPMethod ), cluster mode restricted to "strong" / "eventual" allowlist, eviction algorithm restricted to "sieve" / "cachaner" allowlist, all durations and sizes >= 0, JitterPercent 0-50, static root must be absolute path, index files must not contain / , YAML strict mode rejects unknown fields.Static file serving — path traversal prevention via path.Clean + isPathContained() check (rejects paths escaping root with 403), only GET/HEAD allowed, file size capped at MaxBytes , fuzz-tested with FuzzPathTraversal .Cluster protocol — binary frames validated with magic byte ( 0x42 ), version byte, message type, minimum length checks, string length cap (64 KiB) payload bounds checking on every field read, hop limit enforced (max 2, returns 508), request/response body size limits (512 bytes / 64 MiB), unrecognized gossip message types logged and dropped.Query param allowlist — keepParams in keypolicy.go implements an explicit allowlist: only listed params participate in the cache key, all others stripped.
Fuzz tests — 13 fuzz functions cover H1 parsing, header parsing, smuggling detection, path traversal, cluster codec
round-trips, cache key building, Cache-Control parsing, Vary variant keys, cache state machine, and storage object
decoding. All ensure no panics on arbitrary input.

bouine uses multiple hardening mechanisms so that software defects are less likely to result in security vulnerabilities:Container hardening (Helm chart values.yaml + Dockerfile):

• Runs as non-root ( runAsNonRoot: true , runAsUser: 65534 )
• Read-only root filesystem ( readOnlyRootFilesystem: true )
• All Linux capabilities dropped ( capabilities.drop: [ALL] )
• No privilege escalation ( allowPrivilegeEscalation: false )
• Seccomp profile RuntimeDefault (blocks unsafe syscalls)
• Distroless base image ( gcr.io/distroless/static-debian13:nonroot ) — no shell, no package manager, no attack surface

Language-level hardening (Go):

• Go is a memory-safe language with garbage collection — no buffer overflows, no use-after-free, no format string vulnerabilities
• panic forbidden outside main (enforced by forbidigo linter) — errors are returned, not crashed
• os.Exit forbidden outside main — graceful shutdown via context cancellation
• fmt.Print* forbidden outside main — structured logging via slog only
  Code-level hardening:
• HTTP smuggling detection rejects ambiguous framing (CL+TE, duplicate CL, obs-fold)
• Hop-by-hop headers stripped per RFC 9110 §7.6.1
• Private responses ( Set-Cookie , Authorization ) not cached by default
• Storage paths derived from xxhash64 of cache keys, never from user-controlled strings (path traversal prevention)
• All parsers have byte caps (headers <= 64 KiB, URLs bounded, strings <= 64 KiB in cluster protocol)
• Every queue is bounded (connection limits, in-flight caps, latch caps, body size limits)
• gosec linter enforces zero security findings; suppressions require threat model justification

URL: https://github.com/bouine-cache/bouine/blob/main/docs/security/threat-model.md#8-assurance-case

docs/security/threat-model.md §8 provides a structured assurance case with all four required components:

1. Threat model description (§8.1) — references the STRIDE-based threat model in §§1-7 with 13 assets, 6 trust boundaries, 8 attacker classes, and 40+ threat rows with controls and residual risk.
2. Trust boundaries (§8.2) — 6 boundaries clearly identified (Internet/data-plane, listener/engine, bouine/origin, bouine/peer, operator/admin, process/disk) with per-boundary trust assumptions and controls.
3. Secure design principles argument (§8.3) — maps each Saltzer-Schroeder / OWASP principle (fail-safe defaults, complete mediation, least privilege, economy of mechanism, defense in depth, separation of privilege, psychological acceptability) to concrete bouine implementations.
4. Common implementation weaknesses countered (§8.4) — systematic mapping of all 10 OWASP Top 10 (2021) categories and 7 additional CWE Top 25 categories (CWE-125, 190, 400, 444, 22, 79, 352) to specific bouine controls, with references to fuzz tests, linters, and config validation.

The project applies multiple static analysis tools beyond compiler warnings:

• govulncheck, Go vulnerability scanner, runs on pre-push and CI
• gitleaks, secret detection, runs on every commit and CI

All three run before any release (CI gate in ci.yml runs before release.yml on tag pushes).

The project is written entirely in Go, a memory-safe language. No memory-unsafe languages (C/C++) are used.