summary
Security reporting process and 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.
Dependency and ecosystem risk shifts over time.
Security fixes target the latest release and main branch.
Reporting a vulnerability 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 versions, and reproduction steps.
Avoid public disclosure until maintainers confirm a fix/release plan.
Release and supply-chain baseline
Release flow uses release-please PRs before tags/releases.
Publish flow uses npm Trusted Publishing (OIDC) and npm publish --provenance.
Workflow permissions default to read and elevate per job only.
Third-party actions must stay explicit; high-risk paths should be SHA pinned.