PermLang

Every workflow starts read-only and gives write permissions only to the job that uses them: pull-requests: write only to the job that comments, id-token and attestations only to the release's publish job: https://github.com/PermLang/PermLang/tree/main/.github/workflows and https://github.com/PermLang/PermLang/blob/main/docs/policies.md#secrets-and-credentials

Collaborators' input (release tag names, the PermLang Action's inputs) reaches scripts only through environment variables, never as a ${{ }} expression in a script, and the release workflow checks the tag against package.json before building: https://github.com/PermLang/PermLang/blob/main/.github/workflows/release.yml and https://github.com/PermLang/PermLang/blob/main/action.yml

Every release asset has the version in its name: permlang-<version>.tgz, .tgz.sigstore.json, .tgz.intoto.jsonl, and the SBOM permlang-<version>.cdx.json. For example: https://github.com/PermLang/PermLang/releases/tag/v0.4.3

docs/policies.md is the policy for secrets and credentials: none are stored (OIDC for publishing and coverage), tokens get the least permission, secret scanning and push protection are on, maintainers use 2FA, and a leaked credential is revoked and investigated: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#secrets-and-credentials

SECURITY.md says how to verify a release: gh attestation verify for the npm package and release assets, the Sigstore bundle for cosign, npm audit signatures, and how to rebuild a release byte for byte: https://github.com/PermLang/PermLang/blob/main/SECURITY.md#verifying-a-release

Each release's attestation names the repository, workflow (release.yml) and commit that built it, and SECURITY.md shows how to check it with gh attestation verify --repo PermLang/PermLang: https://github.com/PermLang/PermLang/blob/main/SECURITY.md#verifying-a-release

SECURITY.md says which versions are supported, and for how long (before 1.0, a minor version until the next one comes out): https://github.com/PermLang/PermLang/blob/main/SECURITY.md#supported-versions

SECURITY.md says when a version stops getting security fixes (before 1.0, when the next minor version comes out), and lists the versions that no longer get them: https://github.com/PermLang/PermLang/blob/main/SECURITY.md#supported-versions

GOVERNANCE.md: before anyone gets write, maintainer or administrator access, the maintainers review their contributions and their account (which must use 2FA), and they review who has access every six months: https://github.com/PermLang/PermLang/blob/main/GOVERNANCE.md#getting-more-access

Every release since 0.4.2 comes with a CycloneDX SBOM (permlang-<version>.cdx.json), attested by the release workflow and attached to the GitHub release: https://github.com/PermLang/PermLang/blob/main/SECURITY.md#whats-in-a-release-sbom

Releases come from one repository, PermLang/PermLang. The organization's other repositories (an example project and the profile page) are never released: https://github.com/PermLang/PermLang/blob/main/GOVERNANCE.md#repositories

docs/policies.md and CONTRIBUTING.md say which tests run, on which platforms and Node versions, when (every pull request and push to main), and how to run them locally: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#tests and https://github.com/PermLang/PermLang/blob/main/CONTRIBUTING.md#setting-up

Every change comes with a test that proves it, and fails without the change: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#tests and https://github.com/PermLang/PermLang/blob/main/CONTRIBUTING.md#making-a-change

PermLang has one maintainer, who reviews every pull request before merging it. Approval by a maintainer who isn't the author will be required once there's a second maintainer: https://github.com/PermLang/PermLang/blob/main/GOVERNANCE.md#changes-to-the-code

docs/threat-model.md covers the assets, threat actors, trust boundaries, and every critical code path's threats and defences. Its first review found five vulnerabilities, all fixed and published: https://github.com/PermLang/PermLang/blob/main/docs/threat-model.md

permlang.openvex.json, an OpenVEX document, records any vulnerability in a dependency that doesn't affect PermLang, and why; there are none so far: https://github.com/PermLang/PermLang/blob/main/permlang.openvex.json and https://github.com/PermLang/PermLang/blob/main/SECURITY.md#vulnerabilities-in-permlangs-dependencies

docs/policies.md sets the thresholds: no new dependency with a known vulnerability of any severity, existing ones fixed within 7 days (critical and high) or 30 (moderate and low), and only licenses on an allow-list: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#vulnerabilities-in-dependencies and https://github.com/PermLang/PermLang/blob/main/docs/policies.md#licenses

No release ships with an open alert for a package in its SBOM, unless the vulnerability has been shown not to affect PermLang, with the reason written down: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#vulnerabilities-in-dependencies

The required dependency-review check fails any pull request that adds or updates a dependency with a known vulnerability of any severity, or a license not on the allow-list, unless the advisory is let through with a written reason: https://github.com/PermLang/PermLang/blob/main/.github/workflows/dependency-review.yml and https://github.com/PermLang/PermLang/blob/main/docs/policies.md#vulnerabilities-in-dependencies

docs/policies.md: ESLint and TypeScript errors and high or critical CodeQL alerts block merging; medium and low CodeQL alerts are fixed, or dismissed with a reason, before the next release: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#static-analysis

CodeQL and lint (ESLint with type-aware rules) are required checks on main, so a change with a high or critical CodeQL alert or a lint error can't merge, unless the alert is dismissed with a written reason: https://github.com/PermLang/PermLang/blob/main/docs/policies.md#static-analysis