Security policy

Security policy

SECURITY.md asks for a vulnerability to be reported through GitHub’s private vulnerability reporting, not in a public issue. It says that one person maintains the repository, so a first reply takes days and there is no bounty. It also says that only the latest release receives fixes.¹

The repository releases the schema and the Python models generated from it. Nothing is published to PyPI. When the bundle or the schema has changed, the knowledge release attaches the adapt copy, the bundle as a zip and a Microsoft 365 Copilot skill zip, each with its .sha256 and a build-provenance attestation. The upstream watch reads two public pages of CIS, sends no credentials and writes nothing but its report.

The policy’s table of surfaces names each workflow and what holds it. The pull request checks run read-only. The release job runs only on a push to main, in the release Environment. The website’s deploy job alone holds the Pages scopes. The upstream watch writes only issues. The librarian’s agent runs without a write token, and its publish job runs no agent.

Every workflow declares permissions: {} at the top, pins its actions to commit hashes and runs harden-runner in audit mode. Dependabot keeps the pins, the package’s lock, the sidecar’s lock, the website’s npm packages and the release tools’ npm lock current, each monthly.² The policy says that a ruleset on main blocks deletion and force-pushes and keeps the history linear. It names two settings not yet in force: required reviewers on the release Environment, and secret scanning with push protection.

The policy leaves out the CIS Controls themselves, LinkML, a compromised runner or harness, and whether the knowledge bundle is true.

Footnotes

1. SECURITY.md, every section ↩

2. .github/dependabot.yml, the five entries ↩