m3l-groundwork

Permissions are set per job, never inherited from a broad default (default workflow permissions are read; top-level permissions are read or empty). Each write scope sits in the job that needs it, with the reason in the file: publish in release.yml, scorecard.yml, security-audit.yml and labeler.yml.

Collaborator input reaches a shell only through env vars: soak.yml passes inputs.version as SOAK_VERSION, which bin/soak.sh rejects unless it matches [0-9A-Za-z.+-]; environments.yml passes a boolean dry_run through env. No workflow takes a comment or other free text into a shell.

Each release is a version-named tag and GitHub Release, and its assets carry the version in their names: monte3l-groundwork-<version>.tgz and its .sigstore.json bundle. The release workflow adds an SBOM (.cdx.json) from the next release.

SECURITY.md, "Secrets and credentials", states what the project does not store (no npm token, no signing key, no personal access token), inventories every secret with where it is stored and what uses it, and sets rules for storing (narrowest GitHub secret scope, environment secrets restricted to main), accessing (the two organization owners, with 2FA) and rotating (on exposure, at most one-year expiries, yearly replacement of non-expiring keys).

npm provenance (Sigstore-backed, OIDC-issued, no long-lived key) plus a build-provenance attestation attached to the GitHub Release; see https://github.com/monte3l/m3l-groundwork/blob/main/SECURITY.md#verifying-releases for verification instructions. [signed_releases]

npm provenance (Sigstore-backed, OIDC-issued, no long-lived key) plus a build-provenance attestation attached to the GitHub Release; see https://github.com/monte3l/m3l-groundwork/blob/main/SECURITY.md#verifying-releases for verification instructions. [signed_releases]

SECURITY.md, "Scope and duration of support", states what is covered (the latest 1.x release and the /customize plugin as it stands on main) and that a release is supported until the next release in its line is published. There is no fixed calendar duration and no long-term-support line.

SECURITY.md, "Scope and duration of support", states that once a newer release in its line is published, the superseded release receives no fixes, security fixes included, and that the remedy is to upgrade.

GOVERNANCE.md#granting-access is the policy: only an org owner grants access, with the other owner's agreement, after a track-record check and an out-of-band identity check; access starts at triage; either owner can revoke it; access is reviewed at least once a year.

Each release's GitHub Release carries a CycloneDX 1.6 SBOM (monte3l-groundwork-<version>.tgz.cdx.json), attested with actions/attest and verifiable with gh attestation verify --predicate-type https://cyclonedx.org/bom. See SECURITY.md#verifying-releases.

No release is built from more than one source repository; the vendored m3l-design copy lives in this repository (GOVERNANCE.md, Related repositories).

CONTRIBUTING.md, "Test environments and how tests run", lists the three kinds of test, every environment they run in (local, ubuntu-latest, macos-latest, Node's current line, and the manual soak workflow on Linux x64, Linux arm64 and macOS), what triggers each, and how to read the results. Windows is not covered.

https://github.com/monte3l/m3l-groundwork/blob/main/CONTRIBUTING.md#scope-of-a-pr. [test_policy_mandated]

The main ruleset requires one approving review from someone other than the author (required_approving_review_count=1, stale approvals dismissed on push, no bypass actors). See GOVERNANCE.md#decision-making.

https://github.com/monte3l/m3l-groundwork/blob/main/docs/assurance-case.md. [assurance_case]

docs/m3l-groundwork.openvex.json is an OpenVEX document with a not_affected statement (component_not_present) for each of the 13 advisories recorded in docs/security-review.md, for versions 1.0.0 to 1.0.2; SECURITY.md, "Vulnerabilities that do not affect the project", explains its scope and upkeep. No vulnerability is currently open against any component the project ships or uses.

SECURITY.md, "Dependency and code-scanning findings", Remediation thresholds: critical or high SCA vulnerabilities block the PR that introduces them and are fixed within 60 days if published against a locked dependency; medium within 60 days; low with no deadline. A license outside the allow-list in dependency-review.yml blocks the PR that adds it, and one found on a locked dependency is fixed within 60 days. The process section covers identifying, prioritizing and remediating.

SECURITY.md, "Dependency and code-scanning findings", sets the policy: a critical or high advisory in a dependency blocks a PR and blocks any release, and release.yml's pack job runs pnpm audit and npm audit before anything is built.

https://github.com/monte3l/m3l-groundwork/blob/main/.github/workflows/dependency-review.yml fails a PR on a high-severity finding; GitHub CodeQL and Dependabot alerts cover the rest. [dependency_monitoring]

SECURITY.md, "Dependency and code-scanning findings", Remediation thresholds: a new CodeQL alert of error severity or critical or high security severity blocks the PR; one in merged code at medium or higher is fixed within 60 days of triage.

CodeQL default setup analyzes every push and PR, and the CodeQL check is a required status check on main. By GitHub's default it fails on new alerts of error severity or critical or high security severity.