Docula

Security

Official security policy and vulnerability reporting procedures for the project, including guidance on responsible disclosure and implemented security hardening measures.

We take security seriously and work to keep this project up to date. If you discover a security vulnerability, please report it privately so we can investigate and ship a fix before the issue becomes public.

Table of Contents

Reporting a vulnerability

Please use one of the following private channels — do not open a public issue, pull request, or discussion for security concerns:

  1. Preferred: open a private report via GitHub's Privately reporting a security vulnerability flow on this repository's Security tab.
  2. Email: send the details to [email protected]. If the issue is urgent, include [SECURITY] in the subject line and we will respond as soon as possible.

When reporting, please include as much of the following as you can:

  • A description of the vulnerability and its impact.
  • Steps to reproduce, or a proof-of-concept.
  • The affected version(s) and platform.
  • Any suggested remediation, if you have one.

We will acknowledge receipt, work with you on a coordinated disclosure timeline, and credit you in the advisory once a fix is published unless you ask to remain anonymous.

How this repository is secured

This repository follows the defense-in-depth hardening checklist; progress is tracked in DEFENSE_IN_DEPTH.md. Measures currently in place:

  • All changes land through pull requests — direct pushes to main are blocked, and merging requires passing status checks.
  • Tags (and therefore releases) can only be created by repository admins.
  • Workflow runs from outside collaborators always require maintainer approval, and only allowlisted GitHub Actions can run.
  • CI runs with read-only permissions; every action is pinned to a full commit SHA; Socket Firewall (sfw) wraps pnpm install / npm install; workflows are security-linted with zizmor on every PR.
  • Codespaces and Cursor Cloud Agents install through Aikido Safe Chain; package-manager shims must not be bypassed.
  • Dependencies install through pnpm with a 7-day cooldown on new versions, and lifecycle scripts are blocked by default. Socket reviews every dependency change; Aikido scans every build, and the release workflow's stage-publish job requires a passing Aikido release gate.
  • npm releases are staged, never published directly: CI authenticates with stage-only OIDC trusted publishing (npm stage publish with provenance). Drydock reviews the staged artifact; a maintainer promotes with 2FA. The package requires 2FA and disallows tokens.
Edit this page