Security Posture

As of 2026-06-09, GLX self-attests to the OpenSSF OSPS Baseline version 2026.02.19 at Level 2 (operationally mature), with most Level 3 (mature) controls also met. The single remaining gap is listed below and tracked as an open issue.

This document is the public-facing companion to SECURITY.md. SECURITY.md tells you how to report a vulnerability; this file tells you how the project handles supply-chain and process risk so adopters can make informed decisions about depending on GLX.

Why this exists

Two converging frameworks shape the credibility expectations for open-source projects in 2026:

• OpenSSF OSPS Baseline — a structured set of controls organized into three maturity levels (L1 foundational → L3 mature) that adopters and procurement teams reference when evaluating dependencies. Published at https://baseline.openssf.org/.
• EU Cyber Resilience Act (CRA) — partial enforcement begins 2026-09-11. GLX itself is a CLI tool processing local YAML files and is generally expected to fall outside the CRA's "product with digital elements" definition, though the project does not assert a definitive legal scope on adopters' behalf — see the EU CRA section below for the non-legal-advice posture. Downstream products that embed GLX may need this posture document to assemble their own CRA evidence pack; the OSPS Baseline was designed in part as a compliance bridge for that mapping.

GLX prioritizes the Baseline because doing so produces verifiable evidence (CI configurations, documented policies, signed releases) that adopters can cite directly without bespoke questionnaires.

Current status

Status legend: ✓ met · ◐ partial · ☐ not yet met

Level 1 — Foundational

Control	Status	Evidence
Security contacts documented	✓	SECURITY.md — GitHub Security Advisories with a 48-hour acknowledgment SLA
Contribution process explained	✓	CONTRIBUTING.md covers setup, branch naming, conventional commits, DCO sign-off, PR template
Direct commits to primary branch prevented	✓	Maintainer-verified as of 2026-05-07: an active Main Protection ruleset on the default branch requires PRs, blocks force-push and deletion, and gates merge on the workflows listed in the row below. The ruleset is org-internal (not in this repo); the workflows it gates are public under .github/workflows/
MFA for sensitive resource access	✓	Maintainer-verified as of 2026-05-07: two-factor authentication is enforced organization-wide on the genealogix GitHub organization. Like the branch-protection row, this is a GitHub organization setting and is not visible from the repo contents

Level 2 — Operationally Mature

Control	Status	Evidence
Coordinated vulnerability disclosure policy	✓	SECURITY.md defines the reporting channel, acknowledgment SLA, severity classification, and fix timelines, plus a safe-harbor clause protecting good-faith researchers and a coordinated-disclosure embargo policy (90-day disclosure backstop, embargo-conduct expectations, and downstream notification via a published GitHub Security Advisory + CVE). Completed in #424
Contributors assert legal authorization (DCO/CLA)	✓	Developer Certificate of Origin 1.1 sign-off is required on every commit and is verified for every PR during maintainer review (with direct commits to the default branch blocked by protection rules). An automated DCO check is tracked as a future enhancement to reduce reviewer toil, not as a prerequisite for enforcing this control
Automated test suite runs before merge	✓	Four workflows run unconditionally on every pull_request — Validate Specification, Security, Dependency Review, and Lint PR Title. Two are path-filtered to PRs that touch the relevant files: Lint (**.go, go.mod, go.sum, .golangci.yml) and Lint Markdown (specification/**/*.md, docs/**/*.md, *.md, .markdownlint-cli2.jsonc). Whichever workflows are triggered are expected to be green before merge; the Main Protection ruleset (see L1 row above) gates this
Static analysis of dependencies and code	✓	security.yml runs govulncheck (known-vulnerable Go dependencies) and gosec (Go static security analysis) on every PR and weekly. dependency-review.yml blocks PRs that introduce known-vulnerable dependencies. CodeQL is configured via GitHub Default Setup across actions, go, javascript-typescript, and python (maintainer-verified as of 2026-05-07; Default Setup is a repository setting in the Security tab and is not represented by a workflow file in this repo). The per-PR Analyze (…) jobs are visible on every PR's checks list, and findings surface in Code Scanning
Continuous security posture scoring	✓	OpenSSF Scorecard runs on push to main, weekly on Mondays, and on workflow_dispatch. Results are published to the public OSSF dataset and uploaded to GitHub Code Scanning as SARIF

Level 3 — Mature

Control	Status	Evidence
Release artifact signing	✓	.goreleaser.yml signs checksums.txt with cosign keyless (Sigstore / OIDC), publishing checksums.txt.sigstore.json. Signing the checksum manifest transitively covers every release artifact via SHA-256. See Release signing verification details. (#387)
SBOM with compiled releases	☐	Tracked in #269 — GoReleaser v2 native SBOM via sboms: config
Build provenance / SLSA attestations	✓	release.yml runs actions/attest (pinned v4.1.0) after GoReleaser with subject-checksums: ./dist/checksums.txt, producing a keyless-signed SLSA provenance attestation that covers every release artifact via SHA-256. See Build-provenance verification details. (#256)

Release signing verification details

Verification command:

cosign verify-blob --bundle checksums.txt.sigstore.json --certificate-identity-regexp '^https://github\.com/genealogix/glx/\.github/workflows/release\.yml@refs/tags/' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' checksums.txt

The --certificate-* flags constrain which OIDC identity the Fulcio certificate was issued to and which OIDC provider issued the underlying token, binding verification to this repository's release workflow. Without these constraints, verify-blob would still validate the Fulcio chain, signature, and Rekor inclusion proof, but it would accept any valid keyless signature from any workflow.

Build-provenance verification details

Verification command (run against any downloaded release archive):

gh attestation verify --owner genealogix <downloaded-file>

This checks the artifact's SHA-256 against the SLSA provenance attestation GitHub stores for this repository, confirming the binary was produced by release.yml running in GitHub Actions. The attestation is signed keyless via the workflow's OIDC token (id-token: write) and stored with the attestations: write permission. It is complementary to the cosign signature above: cosign proves the integrity of the checksums.txt manifest, while the attestation proves the build provenance of each artifact per SLSA.

Outstanding gaps

All Level 1 and Level 2 controls are met. One Level 3 control remains before full Level 3 self-attestation:

• #269 — SBOM emission alongside compiled releases (Level 3)

This document is updated when that issue (#269) closes.

EU Cyber Resilience Act note

This section is informational and is not legal advice. CRA applicability is nuanced and depends on how a downstream product packages, distributes, and monetises the components it embeds. Adopters should consult their own counsel for product classification under the CRA or any other regulatory regime.

GLX is a local CLI and Go library. There is no service, no telemetry, no auto-update channel, no network listener in normal operation. On its own, GLX is intended for use as a local CLI/library and is generally expected to fall outside the CRA's "product with digital elements" definition — but the project does not assert a definitive legal scope on adopters' behalf.

Adopters who package or embed GLX into a CRA-regulated product may cite this attestation as part of their own evidence pack. The OpenSSF maintains guidance on how the OSPS Baseline maps to CRA expectations: https://openssf.org/public-policy/eu-cyber-resilience-act/.

If you need an explicit statement for procurement or audit purposes that does not appear here (for example, a specific export-control classification or evidence packaging beyond what this file already cites), open a discussion on https://github.com/genealogix/glx/discussions rather than an issue — procurement-shaped questions tend to attract maintainer time better in that forum.

Maintenance

• Review cadence: this document is reviewed at every minor release, when the remaining tracked gap (#269) closes, and when a new OSPS Baseline version is published.
• Pinned Baseline version: 2026.02.19. Re-review on each new Baseline release to incorporate added or changed controls.
• Last reviewed: 2026-06-09.