We recommend always running the latest version to benefit from security updates.

We take security seriously. If you discover a security vulnerability, please report it responsibly.

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Report via GitHub Security Advisories
3. Or email the maintainers directly (see repository contacts)

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

• Initial response: Within 48 hours
• Status update: Within 7 days
• Resolution target: Within 30 days (depending on severity)

• We follow coordinated disclosure
• Security fixes are released as soon as possible
• Public disclosure after patch is available

This project implements several security measures:

• SLSA Level 3 provenance for all release binaries
• Signed checksums using Sigstore/Cosign
• SBOM generation for all releases
• Dependency scanning via Dependabot and Trivy

• Static analysis via CodeQL and gosec
• Secret scanning via gitleaks
• Vulnerability scanning via govulncheck
• License compliance checks

• Signed container images via Cosign
• SBOM and provenance attestations
• Multi-arch builds from trusted base images

slsa-verifier verify-artifact ofelia-linux-amd64 \
  --provenance-path ofelia-linux-amd64.intoto.jsonl \
  --source-uri github.com/netresearch/ofelia

cosign verify-blob \
  --certificate checksums.txt.pem \
  --signature checksums.txt.sig \
  --certificate-identity "https://github.com/netresearch/ofelia/.github/workflows/release-slsa.yml@refs/tags/<TAG>" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  checksums.txt

cosign verify ghcr.io/netresearch/ofelia:<TAG>

The OpenSSF Scorecard may report a low or zero score for "Signed-Releases" despite this project implementing superior supply chain security measures:

Why this is a false negative: SLSA Level 3 provenance with Sigstore/Cosign provides stronger guarantees than traditional GPG signing:

• Provenance attestations prove the exact source commit, build environment, and workflow
• Keyless signing eliminates key management risks
• Transparency log (Rekor) provides public audit trail
• Certificate-based identity tied to GitHub Actions OIDC

See Verifying Releases for verification commands.

Some Scorecard checks are designed for team-based development and will show lower scores for solo-maintainer projects:

• Code-Review: Requires external approvers (not applicable for solo-dev)
• Branch-Protection: Partial score due to 0-approval requirement

These are accepted trade-offs documented as part of our security model.

The Pinned-Dependencies check flags references to reusable workflows that are not pinned by commit SHA. This project intentionally references its own organisation's reusable workflows via the @main ref:

uses: netresearch/.github/.github/workflows/<workflow>.yml@main

Third-party actions (anything outside the netresearch/ GitHub organisation) MUST still be pinned by full commit SHA — this is enforced by code review and by the Dependabot configuration (.github/dependabot.yml), which auto-bumps every SHA-pinned third-party action in the github-actions ecosystem on a weekly schedule. The trivy-action supply-chain incident of 2026 reinforced this rule.

Rationale for @main on first-party workflows:

• The netresearch/.github repository is owned by the same organisation and protected by the same access controls as this repository
• Pinning by SHA on first-party reusable workflows would require a Renovate/Dependabot cycle across every consumer repository for every improvement to the shared workflow, with no security benefit (the source of truth is the same set of maintainers)
• The shared workflows themselves pin all their internal third-party action calls by SHA, so the supply-chain surface area is contained at the central repository
• Trade-off accepted: a compromise of a netresearch/.github maintainer account would cascade to consumers. This is mitigated by branch protection and the same review requirements on the central repository

Open Scorecard "Pinned-Dependencies" alerts that reference netresearch/.github/.github/workflows/*.yml@main are dismissed as "Won't fix — first-party reusable workflow, see SECURITY.md".

For OpenSSF Scorecard compliance while maintaining solo-developer workflow:

With these settings, solo developers can:

1. Create feature branches: git checkout -b feature/xyz
2. Push changes and create PR
3. Wait for CI to pass
4. Merge without requiring external approval

This repository targets the following scorecard improvements:

• ✅ Pinned-Dependencies: All third-party GitHub Actions pinned by SHA (first-party netresearch/.github reusable workflows use @main — see policy above)
• ✅ Token-Permissions: Minimal permissions in workflows
• ✅ Security-Policy: This file exists
• ✅ SAST: CodeQL and gosec enabled
• ✅ Dangerous-Workflow: No dangerous patterns
• ⚠️ Branch-Protection: Configure via GitHub UI (see above)
• ⚠️ Code-Review: Enabled via branch protection