Only the latest published version of each package receives security fixes. Unreleased code on main, old prereleases, and superseded versions are not supported security branches.

Do not open a public issue for a suspected vulnerability. Use GitHub's private vulnerability reporting form instead.

Include, when possible:

• the affected package and version;
• the impact and realistic attack scenario;
• minimal reproduction steps or a proof of concept;
• affected runtimes or configurations; and
• any mitigation you have already tested.

The maintainer will acknowledge the report, investigate it, and coordinate a fix and disclosure when the report is valid. Please avoid public disclosure until a patched release is available or a disclosure timeline has been agreed.

This policy covers the published enumwaii and eslint-plugin-enumwaii packages and this repository's release automation. Vulnerabilities in a third-party dependency should also be reported to that dependency's maintainer.

The published enumwaii package has one runtime dependency, and the ESLint plugin has one. Framework examples and the documentation site are private workspace projects; their larger dependency graphs are never installed by the automatic core CI or the release workflow.

Repository policy is enforced as follows:

• Private workspace packages and every devDependencies entry use exact SemVer versions or workspace:* for reproducible development. Published dependencies and optionalDependencies use caret ranges or workspace:^ so consumers can deduplicate compatible releases. Peer dependencies use compatibility ranges and never exact versions. pnpm test:pins checks every workspace manifest.
• The lockfile is committed and frozen in CI. Transitive Git and tarball dependencies are blocked.
• Dependency lifecycle scripts fail closed. Only the exact reviewed versions listed under allowBuilds in pnpm-workspace.yaml may run install scripts.
• New package versions are quarantined for 24 hours.
• GitHub Actions are pinned to commit digests. Renovate groups their routine updates into the weekly review PR and opens security updates immediately; Dependabot alerts stay enabled as Renovate's vulnerability source, while Dependabot security updates are disabled.
• Core and extended validation run on pull_request with a read-only token, no secrets, and no persisted credentials. Workflow runs for fork pull requests from outside collaborators wait for maintainer approval.
• Release is manually dispatched, runs only the publishable packages, and is gated by the npm-release environment.

The 24-hour quarantine is not a release blocker. For a reviewed emergency update, add only the required package version to minimumReleaseAgeExclude:

minimumReleaseAgeExclude:
  - "package-name@1.2.3"

Then pin that same version in the appropriate manifest, update the lockfile, and run pnpm check. The exception is version-specific, so leaving it in place does not exempt later releases.

The workflow files define the boundaries, while these GitHub settings enforce the human approval points:

1. Require both Core validation and Extended validation in the branch ruleset, and require approval for fork pull request workflows from outside collaborators.
2. Create an npm-release environment with required reviewers and restrict its deployment branches to protected main. Keep NPM_TOKEN as an environment secret for the initial publication. After both packages exist on npm, configure release.yml as their trusted GitHub Actions publisher, select the npm publish action, bind it to the npm-release environment, verify a release, and then remove the long-lived token.
3. Restrict the github-pages environment to protected main, and require code-owner review for workflow, lockfile, package-manifest, hook, and dependency-policy changes.
4. After making the repository public, enable Dependabot alerts, secret scanning, and push protection. The checked-in dependency review workflow then begins rejecting pull requests that introduce moderate-or-higher known vulnerabilities.

The validation jobs and their dependencies receive no secrets and only a read-only repository token, including for pull requests from forks.