OpenSSF baseline policy¶

This repository uses the OSPS Baseline version 2026.08.28 as its security policy reference. The policy applies to the reusable modules, deployed configuration examples, documentation site, CI, and source history.

Current assessed status¶

The current self-assessment records OSPS Baseline Level 2 for version 2026.08.28. The project does not claim Level 3. OSPS-QA-07.01 at Level 3 requires every change to receive approval from at least one human reviewer who did not author it. The project currently has one maintainer, and the protected main branch requires zero approving reviews. This control is unmet in the published assessment, so the Baseline badge displays Level 2. A future Level 3 claim needs both the independent review process and an evidence-backed assessment of all other Level 3 controls.

Project scope¶

nix-conf publishes reusable NixOS, nix-darwin, and Home Manager modules. The host definitions are maintained deployment examples, not installation templates. This repository does not currently publish a compiled release asset. A future source release must use a unique immutable tag, a change log, integrity evidence, and the release process documented here before it is announced. The SLSA scope and future builder contract are documented in docs/slsa.md.

This repository is part of the related projects listed in the nix-forge project security contract. Related repositories enforce the same minimum security contract or a stricter one for their own code and release surfaces.

Change and build controls¶

Every commit must carry a matching Signed-off-by trailer. The DCO file defines the certificate and .github/workflows/dco.yml checks proposed non-merge commits on pull requests and merge-group refs.

All workflows start with permissions: {}. Jobs grant only the scopes they need, checkout does not persist credentials, and actions use full commit SHAs. Pull requests and merge groups run the required checks before protected main can advance. CI includes flake lock health, dependency review, CodeQL, repository hooks, generated documentation checks, and the test suites that cover the affected configuration.

Use the repository's pinned development environment and run the smallest affected checks from the testing guide. The normal baseline set is:

nix flake check --show-trace
just hooks
python3 -m unittest discover -s tests

Host builds are evaluated separately from deployment. Never put credentials, private identities, or plaintext secret fixtures in a flake, a test, or a workflow. Major configuration changes add or update an observable test and explain the migration in the pull request.

Release and dependency controls¶

Flake inputs, nested lockfiles, package pins, and generated references are reviewed with their security and compatibility impact. Dependency review blocks new low-or-higher severity vulnerabilities. CodeQL findings and SCA findings must be fixed before a future release unless a reviewed suppression records why the finding is not exploitable.

If this repository begins publishing releases, the maintainer will create the tag from reviewed main, publish a scoped change log, record the source commit, and publish checksums and a signed manifest. The release note will identify the actor and workflow, document public interfaces and security changes, explain verification, state the support window, and link the threat model. Releases will not contain host credentials or deployment state.

Governance and vulnerability response¶

The maintainers listed in the governance policy own repository administration, Actions secrets, Pages, dependency policy, and any release. Access to sensitive resources is granted after review of the contributor's history and intended responsibility. New maintainers start with the narrowest role needed and receive broader access only after review.

Report vulnerabilities through the security policy or GitHub private vulnerability reporting. The maintainer acknowledges a report within three business days, provides an initial assessment within seven days, and publishes an advisory after a fix or documented mitigation is available. The OpenVEX record records reviewed non-affectability statements. Support and end-of-life rules are in the support policy.

The operating procedures for dependency management and secret management are part of this policy. They define the review, release-gate, storage, access, and rotation requirements used to support the controls below.

Control evidence¶

This file is reviewed when module contracts, CI trust, dependency policy, or release behavior changes.