Security Baseline

On this page

Kerckhoffs’s Principle (Non-Negotiable)

All applications, libraries, documents, and configuration files must remain secure even if their design, source code, and configuration are fully public. Security derives exclusively from secrets (keys, tokens, credentials), never from obscurity of implementation. This applies to every artifact in every project without exception.

Implications — violations of any of these are blocking defects:

  • No hardcoded secrets, API keys, or credentials in source code or configuration files.

  • No "hidden" endpoints, undocumented admin paths, or obscured URLs as security controls.

  • No proprietary algorithms or custom cryptography — use vetted, standard implementations.

  • No assumptions that attackers lack access to source code, CI configuration, or infrastructure details.

  • All security-relevant behavior must be auditable from the public source tree.

Public Visibility Enforcement

The repository must be publicly accessible. This is verified before any implementation task as part of the preflight checklist and by cargo xtask validate.

Verification: glab project view or the GitLab API — check the visibility field.

If public: proceed normally.

If private: check for a visibility_exception block in .claude/CLAUDE.md. The authority repo is project-defined via visibility_policy_repo (no org-specific default is baked into this universal baseline):

## Visibility Exception
visibility: private
visibility_policy_repo: gitlab.com/your-org/policy-repo
exception_ref: https://gitlab.com/your-org/policy-repo/-/issues/NN
exception_expires: YYYY-MM-DD
exception_reason: <brief justification>

Validation requirements — all must be true:

  1. .claude/CLAUDE.md defines visibility_policy_repo (the project’s policy authority). Fail-safe: if it is unset, no exception is valid and work is refused — a private repo without a configured policy authority cannot self-authorize.

  2. The exception_ref URL points to an issue in that visibility_policy_repo.

  3. The referenced issue exists and is still open.

  4. The exception_expires date has not passed.

  5. The exception reason is documented.

If no valid exception: refuse to work. Explain Kerckhoffs’s principle and direct the user to file an exception request with the project’s visibility_policy_repo authority.

Edit this page · latest