bookstack-mcp

All CI/CD workflows use a read-all or contents: read baseline with per-job permission overrides granting only what each job requires. The one over-privileged case (verify job having packages: write when it only inspects images) was corrected to packages: read in PR #73. Write permissions (packages: write, contents: write, security-events: write) are scoped only to the specific jobs that need them.

The pipelines do not interpolate user-controlled strings (branch names, commit messages, PR titles) directly into shell run: steps. Dynamic values used in shell steps are either integers (PR number), file-sourced (version from package.json via jq), or GitHub-controlled identifiers (github.repository, github.actor). StepSecurity harden-runner is applied to all jobs.

All release assets are tagged with the version identifier vX.Y.Z derived from packages/stdio/package.json:

GitHub Release is created with the exact git tag (vX.Y.Z) as both the release name and tag ref
Docker images are published with :X.Y.Z, :X.Y, and :X tags in addition to :latest, ensuring the exact version is always addressable
SLSA Level 2 provenance attestations are attached to the specific image digest at build time, cryptographically binding each image to the commit and build run that produced it
The git tag is only created after the registry manifest is verified, so the tag always corresponds to a confirmed published image

SECURITY.md contains a "Secrets and Credentials Policy" section documenting storage (env vars only, .gitignore, never hardcoded), access (dedicated least-privilege BookStack user, separate tokens per environment), rotation (immediately on exposure, recommended 90-day cadence, revoke old tokens promptly), CI/CD secrets (none manually stored; only auto-provisioned short-lived GITHUB_TOKEN), and incident response (rotate first, then report privately).

The README Verifying releases section documents how to verify Docker image provenance attestations using gh attestation verify (by tag and by digest), confirming the image was built by the official pipeline from this repository. It also documents git tag --verify for signed source tags.

The README Verifying releases section documents two methods for verifying authorship identity:

gh attestation verify confirms the image was built by a GitHub Actions workflow running under the paradoxbound organisation — cryptographically binding the release to the repository owner's identity
git tag --verify verifies the SSH signature on the git tag against the signing key registered to the paradoxbound GitHub account

SECURITY.md contains a "Supported Versions" section stating that only the latest release (2.6.x) is actively maintained with security updates, and all prior versions (< 2.6) are unsupported. This defines both scope (security updates) and duration (latest release only) of support.

SECURITY.md states: "Only the latest release is actively maintained with security updates." The Supported Versions table marks all versions below 2.6.x as unsupported. This makes the end-of-support condition explicit: a release stops receiving security updates as soon as a newer release is published.

MAINTAINERS.md contains an "Adding collaborators" section documenting the four-step review process required before escalated permissions are granted: verified contribution track record, identity verification, explicit approval from @paradoxbound, and least-privilege scoping. This policy applies to all sensitive resource access listed in the document.

The project produces Docker images as its compiled release assets. Starting from v2.6.1, every Docker image release is accompanied by a Software Bill of Materials (SBOM) in SPDX JSON format (sbom.spdx.json), generated by anchore/sbom-action using Syft and attached as an asset to the corresponding GitHub Release. Users can download it with gh release download vX.Y.Z --pattern 'sbom.spdx.json'. The release pipeline validates SBOM generation on every PR via a smoke test in the pre-merge CD check job.

This project is a single-repository monorepo (packages/core + packages/stdio). There are no separate source code repositories involved in producing a release — both packages live in github.com/paradoxbound/bookstack-mcp and are built, tested, and released together by the same CI/CD pipeline. The criterion is marked N/A.

The README Testing section documents both when and how tests are run. Tests run automatically on every pull request and every push to main via the Functional Tests GitHub Actions workflow. Locally, tests are run with npm test after setting TEST_BOOKSTACK_URL, TEST_BOOKSTACK_TOKEN_ID, and TEST_BOOKSTACK_TOKEN_SECRET. The section also describes test behaviour: self-seeding, automatic cleanup, and graceful skip when credentials are absent.

CONTRIBUTING.md step 2 in "Making changes" explicitly states: "any change that adds or modifies functionality should include corresponding tests in the automated test suite (packages/core/tests/)". This policy applies to all contributors as part of the documented contribution workflow.

The project's primary branch is protected by a branch protection rule requiring at least one approving review from a non-author collaborator before any pull request can be merged. This is enforced for all users including repository administrators, with no bypass permitted.

The project's SECURITY.md contains a 'Threat Model and Attack Surface Analysis' section documenting trust boundaries, entry points, and critical code paths, with six identified threats rated by severity and their mitigations. The section notes it is reviewed and updated at each release.

A VEX document (vex.json) in OpenVEX format is maintained at the repository root. When vulnerability scanners report CVEs in dependencies that do not affect the deployed product, statements are added with machine-readable justifications. Trivy reads the VEX document automatically during both PR and release scans to suppress confirmed non-applicable findings."

SECURITY.md includes a 'Vulnerability and License Remediation Policy' section defining severity thresholds (CRITICAL blocks release, HIGH must be resolved within 30 days, MEDIUM/LOW addressed via Dependabot) and a license policy requiring OSI-approved permissive licenses for all runtime dependencies.

SECURITY.md explicitly states that no release may be published while any unresolved CRITICAL or HIGH severity SCA finding remains open. CRITICAL findings are blocked by the Trivy release gate and HIGH findings are blocked by the npm audit CI gate, both of which must pass before a release can proceed.

SECURITY.md documents the automated dependency evaluation pipeline that runs on every PR and push to main: npm audit blocks on HIGH/CRITICAL and malicious package advisories, OSV Scanner blocks on any OSV advisory match including malicious packages, Trivy blocks on CRITICAL in the Docker image, and GitHub Dependency Review blocks on new vulnerable or malicious dependencies introduced by a PR. Confirmed non-exploitable findings may be suppressed via vex.json.

SECURITY.md includes a 'SAST Policy' section defining remediation thresholds: error-level (HIGH/CRITICAL) CodeQL findings block merge; warning-level (MEDIUM) and note-level (LOW) findings are reported to the GitHub Security tab on a best-effort basis.

CodeQL runs automatically on every PR and push to main. The workflow fails with exit code 1 if any error-level finding is found in the SARIF output, and CodeQL is a required branch protection check — PRs cannot merge while the check fails. False positives may be suppressed inline with a documented justification.