flask-todolist

Every workflow job declares its own permissions block with only what that job needs (for example the scorecard job takes security-events: write and actions: read and nothing else); the repository default is read-only. OpenSSF Scorecard scores Token-Permissions 10/10.

Untrusted or collaborator-supplied text is never interpolated into a shell command: values such as the pull request body are passed to a Python script through the environment (PR_BODY) rather than into the run block. OpenSSF Scorecard scores Dangerous-Workflow 10/10.

Every asset is attached to the tagged release itself, which is the association to the release identifier, and each signature bundle is named after the asset it signs (sbom-core.json / sbom-core.json.sigstore.json). The SBOMs record the component versions they describe.

docs/OPERATIONS.md has a secrets policy that covers all three layers (application runtime secrets behind SECRETS_URL, CI secrets in GitHub Actions, external service tokens), naming for each where it is stored, who can read it, and when it is rotated — with the rotation deadlines carried as rows in docs/SECURITY-CADENCE.md. Storage in version control is blocked by gitleaks on every push plus GitHub secret scanning with push protection.

SECURITY.md, section 'Release artifacts are signed', gives the exact commands to verify a downloaded asset: cosign verify-blob against the sigstore bundle, and gh attestation verify for the SLSA build provenance.

The same verification command pins the expected identity of the release process: --certificate-identity-regexp bound to this repository's release.yml workflow and --certificate-oidc-issuer bound to GitHub's OIDC issuer, so a signature made by any other workflow or account fails the check.

SECURITY.md, section 'Supported versions', states the scope: main and the latest release are supported, earlier releases are superseded, and pre-1.0 releases promised nothing.

The same section states when security updates stop: a release stops receiving them the moment a newer release exists. There is no long-term support branch; fixes land on main and go out in the next tag, and releases are never patched in place.

CONTRIBUTING.md, section 'Who holds what', states that escalated access is reviewed before it is granted — the maintainer reviews the person's contribution history and confirms the identity behind the account, and the grant is recorded in that section so the list always names everyone who holds it.

Every release carries an SBOM per dependency category (core plus one per installable plugin), generated in CI and attached to the release together with its signature.

The project is a single repository; there are no subprojects to hold to the same requirements.

CONTRIBUTING.md documents when and how tests run: one preflight command reproduces CI's lint and test steps locally by reading the workflow itself, the commit hook covers formatting and typing, and every pull request runs 27 required checks including the full suite against three database engines.

CONTRIBUTING.md rule 1 requires every new test to be proven by mutation before it counts, and diff-cover gates every pull request at 100% coverage of changed lines, so a change that adds behaviour without tests cannot merge.

docs/THREAT-MODEL.md is a threat model and attack surface analysis of this project: scope and assumptions, the assets ranked by what their loss costs, the actors and the trust boundary each one cannot cross, an enumeration of every entry point with the threat considered and the control that stands in the way, and a deeper walk through the three paths that hurt most if they break — login to session, appending to the audit chain, and loading a plugin. It ends with what is knowingly left unprotected and what the model cannot answer. The model is bound to the code rather than left as prose: tests/test_threat_model.py fails if a route that needs no login is added without updating the model, if the model names a route that no longer exists, or if it cites a gate or an ADR that does not exist. https://github.com/sayam/flask-todolist/blob/main/docs/THREAT-MODEL.md

docs/vex.openvex.json is an OpenVEX document generated from the same advisory registers that CI already checks in both directions (scripts/build_vex.py). Advisories that live in CI tooling are not_affected with justification component_not_present; advisories in the image's OS layer are reported as affected with the action being waited on, because claiming otherwise would be a lie the consumer's own scanner could catch. tests/test_vex.py enforces both directions between the registers and the document, the OpenVEX shape, and that nothing inside the image is claimed to be absent. SECURITY.md points readers to it. https://github.com/sayam/flask-todolist/blob/main/docs/vex.openvex.json

docs/SECURITY-CADENCE.md defines the remediation thresholds for SCA findings: critical within 7 days, high within 30, medium within 90, counted from the day the project becomes aware; an advisory without a score is treated as high until scored. Licence findings are gated separately by the licensing check, which fails on copyleft conflicts.

A release cannot be cut while an SCA violation is open: the release path requires the same required checks as any change, and the dependency audits fail the build unless every finding is either fixed or recorded with its reasoning in the accepted-advisories registers, which are themselves checked in both directions.

Every change is evaluated automatically: pip-audit for the application and for CI tooling, npm audit for the JavaScript tooling, trivy for the container image, and Dependabot for updates. All dependencies are hash-pinned (Pipfile.lock, pins/ with --require-hashes, npm ci), so a substituted or malicious artefact fails installation rather than being trusted.

SAST findings follow the same documented thresholds as other vulnerabilities in docs/SECURITY-CADENCE.md (critical 7 / high 30 / medium 90 days from awareness), and every alert that stays open must carry its reasoning in .github/accepted-code-scanning-alerts.txt, which CI checks in both directions.

Every change runs CodeQL (Python and JavaScript), semgrep with a proven scan scope, and gitleaks as required checks; a finding blocks the pull request unless it is declared with its reasoning in .github/accepted-code-scanning-alerts.txt, and a declaration that no longer matches a real alert fails the build too.