Security Policy

summary

Security reporting process and monorepo release hardening baseline.

read_when

Reporting a vulnerability.

Reviewing release and workflow security controls.

system4d

container	compass	engine	fog
Security policy for maintainers and contributors.	Private reporting, least privilege, auditable releases.	Report privately -> triage -> patch -> verify -> disclose.	Monorepo release automation may evolve before first public publish flow is fully settled.

Supported versions

Security fixes target main and the latest relevant package releases.

Use private reporting.

Preferred: GitHub Security tab -> Report a vulnerability.
If private reporting is unavailable, open a minimal issue titled Security contact request without exploit details and request a private channel.
Include impact, affected packages/versions, and reproduction steps.
Avoid public disclosure until maintainers confirm a fix/release plan.

Root validation uses scripts/quality-gate.sh through npm run quality:pre-push and npm run quality:ci before push/release decisions.
Package release checks remain package-local until monorepo release automation is finalized.
Workflow permissions should default to read and elevate per job only.
Third-party actions should stay explicit; high-risk paths should be SHA pinned.