mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Marc-André BombeckandClaude Opus 4.7
75d142df25
Issue #88's biggest blocker was that docs and README pointed at ghcr.io/mbombeck/healthlog:latest, but no workflow ever pushed an image — every self-hoster trying to follow the docs hit "manifest unknown". This adds .github/workflows/docker-publish.yml. The workflow: - Triggers on push to main, on v* tags, on PRs (build only, no push), and via workflow_dispatch - Builds linux/amd64 + linux/arm64 multi-arch images via buildx - Tags with `latest` (main only), semver (`1.2.0`, `1.2`), branch name, PR number, and short SHA — using docker/metadata-action defaults - Attaches SLSA build provenance and an SBOM to every image - Caches build layers in GitHub Actions cache for fast iterations - Uses concurrency group + cancel-in-progress so superseded runs stop The bundled docker-compose.yml now references `ghcr.io/mbombeck/healthlog:latest` as the primary `image:` and keeps `build:` as a fallback so contributors can still `docker compose up --build` against their working tree. SECURITY.md gains a Supply Chain section explaining where images come from, how to verify provenance and SBOMs, and how to pin a specific version. README's Quick Start updated to reflect that no build is needed for self-hosters. The first run of this workflow on main will publish the image; until then `docker compose up` will fall back to the `build:` block. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.1 KiB
3.1 KiB
Security Policy
Supported Versions
Only the latest release on the main branch is actively supported with security updates.
| Version | Supported |
|---|---|
| Latest | Yes |
| Older | No |
Reporting a Vulnerability
If you discover a security vulnerability, please report it responsibly.
Do not open a public GitHub issue for security vulnerabilities.
Instead, send an email to security@bombeck.io with:
- A description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
Response Timeline
- Acknowledgement: Within 72 hours
- Initial assessment: Within 1 week
- Fix and disclosure: Coordinated with reporter, typically within 30 days
Scope
The following are in scope:
- Authentication and session management
- Data encryption and secret handling
- API authorization and access control
- Cross-site scripting (XSS), CSRF, and injection vulnerabilities
- Information disclosure
Out of scope:
- Denial of service attacks
- Social engineering
- Vulnerabilities in third-party dependencies (report upstream)
- Issues requiring physical access to the server
Security Architecture
HealthLog is designed with security as a core principle:
- Passkey-first authentication (WebAuthn/FIDO2) with password fallback
- AES-256-GCM encryption for all stored secrets (OAuth tokens, API keys, VAPID keys)
- Argon2id password hashing with zxcvbn strength validation
- HMAC-SHA256 hashed API tokens
- Server-side sessions in PostgreSQL (HttpOnly, SameSite=Strict, 30-day sliding expiry)
- Rate limiting on authentication and external-facing endpoints
- Security headers: CSP with nonces, HSTS, X-Frame-Options DENY, Permissions-Policy
- Proxy-level route protection via
proxy.ts(session cookie validation on all non-public paths)
For more details, see the security documentation.
Supply Chain
HealthLog Docker images are built and published from this repository's CI:
- Source:
.github/workflows/docker-publish.yml— runs on every push tomainand everyv*tag - Registry:
ghcr.io/mbombeck/healthlog - Architectures:
linux/amd64andlinux/arm64 - Provenance attestation: each image carries a SLSA build provenance statement linking it back to the GitHub Actions run, the commit SHA, and the workflow definition
- SBOM: each image includes a Software Bill of Materials you can inspect with
docker buildx imagetools inspect ghcr.io/mbombeck/healthlog:latest --format '{{ json .SBOM }}'
To pin to a specific version in production, replace :latest with the released tag in your docker-compose.yml, e.g. ghcr.io/mbombeck/healthlog:1.2.0. Pinning is recommended for self-hosters who want explicit control over upgrades.
If you discover a tampered or unexpected image, please report it as a vulnerability via the email above.