docker

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Development happens publicly on the main branch via pull requests; every interim
▎ commit is visible in the repository — no release-only gating. The full PR +
▎ commit history is public at https://github.com/wnstify/docker

Repository on GitHub, which uses git. git is distributed.

Each release has a unique CalVer identifier (e.g. v2026.05.21) backed by an
▎ annotated git tag pointing at the released commit. Every interim state is also
▎ uniquely identified by its git commit SHA. Releases:
▎ https://github.com/wnstify/docker/releases

Each release is identified by an annotated git tag pointing at the released
▎ commit (e.g. v2026.05.21). Tags listing: https://github.com/wnstify/docker/tags

Release notes are maintained in two complementary places, neither of which is
▎ raw git log output:
▎
▎ - CHANGELOG.md (Keep-a-Changelog format, grouped by Added / Changed / Removed /
▎ Security): https://github.com/wnstify/docker/blob/main/CHANGELOG.md
▎ - The GitHub Releases page (auto-generated PR list with a verification preamble
▎ per tag): https://github.com/wnstify/docker/releases

The project consists of docker-compose templates referencing upstream container
▎ images; it produces no binaries, libraries, or services of its own and therefore
▎ has no project-specific CVEs. Vulnerabilities in upstream container images are
▎ tracked separately in https://github.com/wnstify/docker/blob/main/AUDIT.md via
▎ weekly Trivy scans (workflow: .github/workflows/weekly-audit.yml).

Non-trivial SECURITY[.md] file found file in repository: https://github.com/wnstify/docker/blob/main/SECURITY.md. [osps_do_02_01]
. Bug reports are submitted via the GitHub Issues tracker on the public
▎ repository. SECURITY.md additionally documents the vulnerability-specific
▎ channel (private security advisory). URLs:
▎ https://github.com/wnstify/docker/issues and
▎ https://github.com/wnstify/docker/blob/main/SECURITY.md

The project uses GitHub Issues as the per-issue tracker; each issue is ▎ individually URL-addressable, taggable with labels, and closeable on resolution

All bug reports opened in the last 90 days have been triaged and responded to. ▎ The project's commit cadence (≥ 30 commits in the last 90 days, confirmed by ▎ OpenSSF Scorecard's Maintained = 10/10) reflects active triage of issues ▎ alongside development.

All enhancement requests opened in the last 90 days have been responded to. ▎ Enhancement triage happens in the same Issues + Discussions venues as bug ▎ reports.

GitHub Issues and Discussions are publicly archived, indexed, and
▎ URL-addressable. Full historical archive:
▎ https://github.com/wnstify/docker/issues?q=is%3Aissue (issues) and
▎ https://github.com/wnstify/docker/discussions (discussions).

SECURITY.md publishes the vulnerability reporting process, including scope,
▎ expectations, response times, and what is/isn't in-scope (project compose files
▎ vs upstream image vulnerabilities). URL:
▎ https://github.com/wnstify/docker/blob/main/SECURITY.md

SECURITY.md instructs reporters to use GitHub's private security-advisory flow
▎ ("Report a vulnerability" on the repository's Security tab) — explicitly not a
▎ public issue. Direct URL to file a private advisory:
▎ https://github.com/wnstify/docker/security/advisories/new

SECURITY.md commits to acknowledging receipt of vulnerability reports within 48
▎ hours — well within the 14-day MUST. (Section "What to Expect" in
▎ https://github.com/wnstify/docker/blob/main/SECURITY.md)

The project ships docker-compose YAML configuration files, not buildable software. There is no compilation step. Consumption is git clone + docker compose up. The "build" output is the templates themselves.

No build step exists (see build above).

No build step exists (see build above).

Multiple FLOSS automated test suites run on every pull request: Trivy CVE scanner
(.github/workflows/pr-cve-gate.yml), Trivy IaC misconfiguration scanner
(.github/workflows/pr-misconfig-scan.yml), actionlint workflow linter
(.github/workflows/actionlint.yml), CodeQL, and OpenSSF Scorecard. How to run them
is documented in CONTRIBUTING.md "Required CI Checks":
https://github.com/wnstify/docker/blob/main/CONTRIBUTING.md

Tests invoke automatically via GitHub Actions on every PR. Locally they are
runnable in the standard way for each tool: trivy config ., actionlint
.github/workflows/*.yml, and pre-commit run --all-files.

Trivy IaC scans every YAML/compose file in the repository, the CVE gate scans every image tag referenced in every compose file, actionlint covers every workflow file, and pre-commit hooks (yamllint, gitleaks, check-yaml, detect-private-key, no-latest-tags) run against every change. Effective coverage of testable content is essentially 100%.

GitHub Actions runs the full check suite on every PR and on every push to main:
https://github.com/wnstify/docker/tree/main/.github/workflows

CONTRIBUTING.md "Required CI Checks" section codifies the policy: the Trivy CVE
scan gate is required for merge (enforced by branch protection on main), and new
templates must additionally pass misconfig and actionlint. The "Template
Guidelines" section enumerates the hardening tests every new compose file must
satisfy. https://github.com/wnstify/docker/blob/main/CONTRIBUTING.md

Every PR merged in the last 90 days, including all new-template additions, ran the full CI suite before merge. The required scan gate has been enforced as a branch-protection requirement since PR #9.

CONTRIBUTING.md "Required CI Checks" + "Template Guidelines" document the tests every new contribution must pass.

Multiple linters enabled: actionlint (workflow YAML), Trivy IaC (compose +
workflow misconfig), Trivy CVE (image vulnerabilities), CodeQL (default extended
queryset), yamllint (YAML style), gitleaks (secret detection), and pre-commit
hooks (check-yaml, detect-private-key, trailing-whitespace, no-latest-tags).
Configuration: https://github.com/wnstify/docker/blob/main/.pre-commit-config.yaml
and https://github.com/wnstify/docker/tree/main/.github/workflows

All current findings are at or below the agreed thresholds. The required scan CVE
gate blocks new criticals and highs from merging. Trivy IaC findings are either
resolved or documented in .trivyignore with rationale. Static-analysis state is
tracked in https://github.com/wnstify/docker/blob/main/AUDIT.md (refreshed
weekly).

actionlint runs with the default ruleset (no suppressions). Trivy runs at HIGH and CRITICAL severity. CodeQL uses GitHub's default extended queryset. Pre-commit binary-size limit is set to 200 KB. Strictness is maximal where practical given the project type.

The primary maintainer designs each compose stack against a documented hardening
baseline: capability minimisation (cap_drop: ALL plus the minimum verified
cap_add), no-new-privileges, ipc: private, internal-only DB networks, 127.0.0.1
web-UI bindings, separation-of-duties via non-root DB users, and defense-in-depth
through user-supplied reverse proxies. The baseline is documented at
https://github.com/wnstify/docker/blob/main/SECURITY.md ("Security Features in Our
Templates") and the applied state of every image is tracked at
https://github.com/wnstify/docker/blob/main/AUDIT.md.

The hardening baseline directly mitigates the OWASP-class issues relevant to this project type: secrets-in-config (GitHub secret scanning + push protection enabled, .env.example pattern with ${VAR:?error}), container escape (cap drops + no-new-privileges + read-only filesystems where possible), inter-service trust boundaries (Docker internal-only networks for DB/cache tier), supply chain (SHA-pinned third-party Actions, SHA256-pinned Trivy installer, Renovate dependency automation, Sigstore-signed releases with SLSA provenance attestations, weekly Trivy CVE refresh and gate on every PR).

Cryptographic primitives in use: Sigstore for release signing (open-spec cosign + Fulcio + Rekor), SHA-256 (FIPS 180-4) for checksums, ECDSA P-256 (FIPS 186-5) for Sigstore-issued certificates, TLS via upstream reverse proxies. All are publicly published and reviewed protocols.

The project does not reimplement cryptography. It delegates to cosign (signing), OpenSSL via container TLS stacks, and upstream image cryptographic libraries (e.g., PostgreSQL SCRAM-SHA-256).

All cryptography used in the project's pipeline is FLOSS: cosign (Apache-2.0), Sigstore Fulcio/Rekor (Apache-2.0), OpenSSL (Apache-2.0/SSLeay), and upstream container TLS stacks.

Sigstore-issued certificates use ECDSA P-256 (256-bit, ≥ NIST minimum through 2030). SHA-256 is used throughout for checksums and digests. Smaller keylengths are not configurable for the signing path — it is keyless-OIDC and the algorithms are dictated by Sigstore's Fulcio CA.

No broken algorithms in defaults. SHA-256, ECDSA P-256, and RSA-2048+ are used via
upstream stacks. No MD4, MD5, single DES, RC4, or Dual_EC_DRBG anywhere in the
project's own pipeline.

No SHA-1, no CBC-mode-in-SSH, no other algorithms with known serious weaknesses
are used in the project's own pipeline. (Upstream container images may use other
algorithms internally; those are out of scope per
https://github.com/wnstify/docker/blob/main/SECURITY.md "Out of Scope".)

The project does not itself terminate TLS connections — that responsibility is
delegated to the user's reverse proxy of choice (Caddy, Pangolin, Traefik, etc.),
each of which enables perfect forward secrecy by default in their TLS
configuration. SECURITY.md documents this trust boundary at
https://github.com/wnstify/docker/blob/main/SECURITY.md.

The project stores no passwords. Compose templates pass environment variables to upstream container images, which handle their own credential storage internally (PostgreSQL SCRAM-SHA-256, Redis --requirepass, etc.). Password storage policy for those is the responsibility of the upstream image.

The project generates no cryptographic keys at runtime. Ephemeral signing keys used by the release pipeline are generated by Sigstore Fulcio inside GitHub-hosted runners using the operating-system CSPRNG, outside the project's control.

Distribution channels use HTTPS exclusively. [osps_br_03_02] .
Distribution is HTTPS-only: git clone over HTTPS from github.com, Sigstore Fulcio
and Rekor over HTTPS, GitHub container registry over HTTPS. Releases are
additionally Sigstore-signed end-to-end with SLSA build-provenance attestations
bound to the workflow OIDC identity. URL:
https://github.com/wnstify/docker/blob/main/VERIFICATION.md

SHA256SUMS is delivered alongside a Sigstore signature bundle
(SHA256SUMS.sigstore.json) on every release. The cosign verify-blob command
documented in https://github.com/wnstify/docker/blob/main/VERIFICATION.md binds
verification to this repository's release workflow identity, so a tampered
checksum cannot be retrieved over plain HTTP and used without detection.

The weekly Trivy refresh workflow (.github/workflows/weekly-audit.yml, runs
Mondays 06:00 UTC) opens a pull request with the CVE delta against the previous
week's scan. The required scan gate on main blocks merging anything with
unaddressed criticals or highs. Triage state is timestamped per-finding in
https://github.com/wnstify/docker/blob/main/AUDIT.md.

Critical vulnerabilities surface on every pull request via the Trivy CVE gate (informational + delta-based) and weekly via the audit workflow. The pull-request-level gate prevents merging while criticals are present, so triage and fix happen before a vulnerable change reaches main.

The repository has GitHub secret scanning enabled with push protection (confirmed
via gh api repos/wnstify/docker --jq .security_and_analysis). The .env.example
pattern keeps real secrets out of git, and ${VAR:?error} ensures missing values
fail fast rather than embed defaults. Historical .env files that were briefly
tracked have been untracked and the affected credentials rotated (commit d1007bd).
gitleaks runs as a pre-commit hook to catch leaks before push:
https://github.com/wnstify/docker/blob/main/.pre-commit-config.yaml

Multiple FLOSS static-analysis tools run before any release: CodeQL (default
extended queryset, covers shell and JavaScript helper scripts), actionlint with
embedded shellcheck (every workflow YAML), Trivy IaC misconfig (every YAML and
compose file), OpenSSF Scorecard (security-posture audit), yamllint, gitleaks.
Configuration: https://github.com/wnstify/docker/tree/main/.github/workflows and
https://github.com/wnstify/docker/blob/main/.pre-commit-config.yaml

The static-analysis stack covers common vulnerability classes for this project
type: Trivy IaC checks Docker and Kubernetes misconfigurations (CIS Docker
Benchmark, security_opt, capability misconfigs, exposed ports), Trivy CVE checks
every referenced container image against the full vulnerability database (CVE /
GHSA / OSV), CodeQL checks shell and JS helpers against the default extended
queryset (which includes injection, traversal, and unsafe-deserialization rules),
gitleaks scans for leaked credentials, and OpenSSF Scorecard covers supply-chain
misuse patterns.

All current static-analysis findings are either resolved or documented in
.trivyignore with rationale. The required scan CVE gate on main blocks merging
anything that introduces new criticals or highs. Triage state is timestamped
per-finding in https://github.com/wnstify/docker/blob/main/AUDIT.md (refreshed
weekly).

Every pull request runs the full static-analysis suite. Scorecard runs additionally on every push to main and on a weekly cron (.github/workflows/scorecard.yml). Trivy CVE refresh runs every Monday and opens a PR with the delta (.github/workflows/weekly-audit.yml). Effective cadence: every commit plus a weekly full sweep.

Trivy CVE scanning is dynamic-class analysis for this project type — it pulls every referenced container image and scans the live filesystem and binary contents against the vulnerability database, not just text matching. Runs on every PR (.github/workflows/pr-cve-gate.yml) and weekly (.github/workflows/weekly-audit.yml). For releases, GitHub-hosted runners additionally enforce ephemeral environments, which provides an isolation property a dynamic scan can rely on.

The project ships no memory-unsafe code. Deliverables are YAML compose files plus a handful of Python and Bash helper scripts in .github/scripts/ and scripts/. No C, C++, or unsafe-Rust components are produced or distributed by the project.

Trivy CVE scanning runs with the full default vulnerability database loaded (no rule suppressions), Trivy IaC misconfig runs with the full default ruleset at HIGH+CRITICAL severity, CodeQL uses the default extended queryset. All dynamic checks run with maximal assertion coverage; nothing is gated to a "production-only" reduced ruleset.

Every dynamic-analysis finding (Trivy CVE) above the agreed threshold is triaged
in https://github.com/wnstify/docker/blob/main/AUDIT.md with an explicit verdict
(ACTION / WATCH / CONDITIONAL / NOISE) and tracked to resolution. Net-new
criticals and highs are blocked by the required scan gate on every PR before they
can reach main.