discovery-media-player

Every job is granted the minimum for its activity, and the workflow that publishes is the strictest. release.yml declares permissions: {} at workflow level — no scope at all — then grants per job: the verification job contents: read plus actions: read because it queries the Actions API, the publish job contents: read plus id-token: write for OIDC and nothing else, the announce job contents: write alone to create the Release. ci.yml is contents: read throughout, scorecard.yml read-all. The release pipeline is deliberately split into four jobs with disjoint permissions so that the job holding a write scope is never the job that executes downloaded code.

The only collaborator input this project accepts is the tag on a workflow_dispatch of release.yml and image.yml. It was already not injectable — TAG is read as a shell environment variable, never interpolated with ${{ }} inside a run block, the same rule applied to untrusted input in cla.yml — and it is now validated as well: the first step of the release pipeline, before any repository access, rejects anything that is not the vX.Y.Z form this project tags, and image.yml has carried the same check. Validation is separate from injectability: a typo previously travelled as far as the checkout to fail on a message about a missing ref, and a compromised collaborator account had a free-text field on the workflow that publishes.

Every asset carries the release identifier. The npm tarball is named discovery-media-player-<version>.tgz and is published under that exact version. The container image is pushed on the immutable versioned tag first, with latest promoted afterwards by atomic retag rather than pushed during the build. The GitHub Release is the tag itself, and the CycloneDX SBOM attached to it is named discovery-media-player-<tag>.cdx.json — an SBOM detached from the version it describes describes nothing. CI refuses a tag whose version does not match package.json, and refuses a tag on a commit that is not an ancestor of main.

docs/SECURITY-PRACTICES.md defines the policy, and its rule is that the project holds no long-lived secret and does not want one. It tabulates every credential, who holds it and how long it lives: npm publishing held by nobody because OIDC issues an identity per run, GHCR push scoped per job, no signing key at all because Sigstore signs against the workflow identity, and the operator's own secrets which never transit through this project. Storing: never in version control, enforced by tools/secrets-en-clair.mjs in CI and pre-push, with .env.example carrying names and no values. Accessing: the resource list in MAINTAINERS.md, granted only after the vetting policy in the same file. Rotating: a table of triggers, with the standing rule that a leaked credential is revoked first and removed second, because a pushed secret is disclosed and rewriting history does not recall it.

docs/VERIFYING-RELEASES.md gives the technology, the commands and the expected output for each asset: npm audit signatures for the package, with the verified registry signature and verified attestation lines a consumer should see; gh attestation verify against the OCI reference for the image, plus docker buildx imagetools inspect to read its embedded SBOM and provenance; and gh release download for the CycloneDX SBOM attached to each GitHub Release. A table states what each check proves and, deliberately, what it does not — a verification that is oversold is worse than none, because it stops people looking further. The document also tells readers to fetch it from a source other than the artifact they are checking.

docs/VERIFYING-RELEASES.md carries an explicit identity table for the expected signer. Because publication is signed by a workflow rather than a person, what must match is the Sigstore issuer https://token.actions.githubusercontent.com, the source repository github.com/Juli1artha/discovery-media-player, the workflow .github/workflows/release.yml, and a commit belonging to main — which CI enforces separately by refusing to publish a tag whose commit is not an ancestor. The document states plainly that a signature which verifies but names a different repository or workflow is not this project's release, and that a failing check is handled as an incident through SECURITY.md rather than as a support question.

SECURITY.md states the scope and duration in a table rather than by implication: the latest release is supported for bug fixes and security fixes, anything earlier for neither. The reasoning is given — the project is young, releases are small and frequent, there is one maintainer, and a long-term support branch would be a promise nobody here could keep. It also says what makes the abrupt cutoff workable: upgrading is npm update or a new image tag, and where a database migration is genuinely required, docs/MIGRATIONS.md documents it and the running instance says so rather than degrading silently.

SECURITY.md says exactly when security updates stop: a version stops receiving them the moment the next release is published. There is no backporting — a fix is delivered as a new release, never as a patch to an older line — so a consumer three versions behind when an advisory lands upgrades to current rather than waiting for a fix on their line. The changelog for each version names the security-relevant changes it carries, so what is gained by moving is visible before moving. The document also commits to changing that table first, before any wider support promise is made elsewhere.

MAINTAINERS.md carries a Granting access policy: nobody receives escalated permissions — merge rights on main, repository settings, publishing, or the security mailbox — without being reviewed first, before the grant rather than after. It states what is examined and in what order: a record of merged pull requests over a period long enough to see how the person behaves when they disagree with review (explicitly not a commit count), the CLA already signed, 2FA confirmed rather than assumed, and the smallest grant that does the job, with access to a secret granted per resource rather than as a bundle. Grants are recorded in the same pull request that makes them, and the policy notes the one place it is currently weaker than it reads: with a single maintainer, the person applying it is the person it would be applied to — which is why it was written before anyone is waiting on it.

Both compiled assets ship with an SBOM. The container image is built with sbom: true and provenance: mode=max, so its bill of materials travels as an attestation readable with docker buildx imagetools inspect. The npm package now carries one too: the release workflow generates a CycloneDX SBOM with npm sbom from the same production tree the tarball is published from, verifies it is well-formed CycloneDX with at least one component rather than an empty file, and attaches it to the GitHub Release named discovery-media-player-<tag>.cdx.json. It is generated with --ignore-scripts, because the announcing job is the only one holding contents: write and installing dependencies that execute their own scripts there would hand downloaded code exactly the privilege the four-job split removes. docs/VERIFYING-RELEASES.md tells consumers how to fetch and use it.

The project is a single repository. No subproject codebase is compiled into a release, and nothing outside github.com/Juli1artha/discovery-media-player contributes source to the published npm package or container image, so there is no additional codebase whose security requirements could be looser than the primary one.

CONTRIBUTING.md documents when and how the tests run, in a table naming each of the four benches, the command that invokes it, what it proves that the others cannot, and when it runs — all four on every push and pull request, on Node 22 and 24 for the unit bench. It lists what runs alongside them (lint, typecheck, CodeQL, the blocking dependency-vulnerability check, and the repository's own guards), states that all of it must pass before a pull request can merge and that pull requests are the only way into main, and explains how to read a failure: an ::error:: names your branch, while GARDE NON CONCLUANTE means the guard could not look and the fix is in the guard or its environment, not in your change.

The policy is CONTRIBUTING.md's stated one rule: a behaviour worth keeping is worth a test that fails without it. It extends to the test's name, which must say which failure it prevents rather than that it tests the happy path — a test that does not will be asked about in review. AGENTS.md repeats it among the conventions that only review enforces. The history shows it applied: the suite stands at 1515 tests across 144 files, and the credential guard added during this badge review shipped with 21 tests of its own, covering both what it catches and what it deliberately lets pass.

docs/THREAT-MODEL.md is the threat model and attack-surface analysis. It is organised by asset rather than by feature — documents, reading data, host credentials, in descending order of what their loss would cost an operator — because a model arranged by feature reassures its author and finds nothing. It tabulates every entry point an unauthenticated stranger can reach, then works through eight attack paths: reading a document without being its recipient, server-side request forgery through the file proxy (named the highest-value target, with the realised failure mode of a plausible typo widening the guard), taking or spying on a live presentation, crossing the host boundary, XSS against the nonce-based CSP, reaching the database directly, compromising the supply chain, and denial of service. Each names its residual risk, including the ones deliberately left standing — a link forwarded by its legitimate recipient, and compromise of the single maintainer account. It is reviewed when a feature changes what an actor can do or the host contract breaks.

There is nothing to account for in a VEX document. npm audit reports zero vulnerabilities across both the production and development trees, so no known vulnerability in a component has been assessed as non-exploitable here, and a VEX statement would have no subject. The policy for when that changes is written down rather than left open: docs/DEPENDENCIES.md states that a finding may be suppressed only as not exploitable in this project — never as won't fix — that the suppression records why the vulnerable path cannot be reached, who decided and when, and that the non-exploitability assessment is published with the release carrying it, in that version's changelog section and alongside the SBOM attached to the GitHub Release, so a consumer scanning our SBOM can distinguish a real exposure from one already assessed.

docs/DEPENDENCIES.md defines the thresholds, and gives each one a reason rather than a number alone. Production tree: no known vulnerability at any severity — it runs on the operator's machine beside their commercial documents and under their credentials, and it holds one dependency, so tolerating anything there would be choosing to ship a known hole in code we can read in full. Development tree: nothing High or Critical — it never leaves the repository, and blocking on a moderate in a test plugin would stall delivery of real fixes for a threat that reaches no instance, while teaching people to route around the check. Licences are held to the same bar: FLOSS and compatible with AGPL-3.0-or-later distribution, and a licence that changes under us is treated as a finding at the same thresholds.

docs/DEPENDENCIES.md states the release rule: no release goes out carrying a violation of either threshold. It is enforced structurally rather than remembered — the check runs on every commit, a tag can only publish a commit that is an ancestor of main, and every commit on main has passed it. The document also says what happens when an advisory lands against an already-published version: the fix goes out as a release of its own rather than waiting for the next feature, which is consistent with the support policy in SECURITY.md, where a fix is always a new release and never a backport.

ci.yml carries a blocking software-composition check on every push and every pull request, evaluated against the documented thresholds and required before merge: npm audit --omit=dev --audit-level=low for the production tree and npm audit --audit-level=high for the development tree, each failing with an error naming which tree breached and pointing at docs/DEPENDENCIES.md. Because pull requests are the only route into main and the check is required, a change introducing a vulnerable or malicious dependency is blocked rather than reported. Suppression is possible only as a recorded non-exploitability assessment, per the policy in the same document. Integrity of what is installed is enforced alongside it: npm ci only, against a committed lockfile carrying an integrity hash per package, with actions pinned to commit SHAs and base images to digests.

docs/SECURITY-PRACTICES.md defines the SAST thresholds in a table: Critical and High must be resolved before the pull request merges and block any release; Medium before the next release, as a fix or a written suppression but never silence; Low and Note triaged within the release cycle and acceptable with a recorded reason. A fourth row overrides the others — any severity in a security-critical path (the file proxy, the access wall, share revocation, the presentation control token, CSP handling) blocks the merge regardless of the tool's own rating, because severity ratings are generic and this codebase is not: a medium in the component that fetches a caller-supplied URL server-side is not a medium here. Suppression is allowed only as not exploitable, with the reason, the decider and the date, and never as a repository-wide rule disablement.

Every change is automatically evaluated and blocked on violation. CodeQL runs the javascript-typescript security query suites on every pull request and every push to main, is a named required check, and is blocking on the publication path; a weekly scheduled run additionally applies new rules to code that has not changed. Alongside it on the same trigger: ESLint with typescript-eslint, tsc under strict with noUnusedLocals, noUnusedParameters and noFallthroughCasesInSwitch, and the repository's own static guards over the workflow YAML, the Dockerfile, the published surface and every tracked file. Because pull requests are the only way into main and these are required checks, a violation blocks the merge. Suppression is governed by the policy in docs/SECURITY-PRACTICES.md and is available only as a recorded non-exploitability assessment. Current state: zero outstanding findings across all of them.