Security policy

Security policy

SECURITY.md is the repository’s security policy. Lint & docs holds it to a budget of 900 words.

Reporting a vulnerability

SECURITY.md asks for a report through GitHub’s private vulnerability reporting for the repository, not through a public issue or a pull request.¹ A report says which file is affected, how it is exploitable, and whether it reaches the released schema or only the repository’s automation. One person maintains the repository, so a first reply comes in days, not hours, and there is no bounty.

Supported versions

Only the latest release receives fixes. A security fix is released as a patch and noted in CHANGELOG.md. The schema stays below 1.0.

What the repository releases

The repository releases a LinkML schema, the Python datamodel generated from it, and the schema’s lokf adapt copy as a release asset. Nothing is published to PyPI. scripts/check_upstream_release.py runs only in Upstream watch: it reads SchemaStore’s repository and GitHub’s list of API versions, and writes nothing but its report. scripts/derive.py runs in no workflow of the repository. A host runs it over its own files, on a pull request too, so it parses them with yaml.safe_load, runs nothing they contain and writes nothing: see Derive and check concepts from workflow files.

What holds each surface

• Build and test and Lint & docs on every pull request, and Knowledge Registrar on any that touches .lokf/, run read-only jobs with persist-credentials: false, and uv sync --locked installs only what uv.lock pins.
• Semantic release pushes a changelog commit and a tag to main and dispatches the knowledge release. It runs only on a push to main, in the release Environment, and installs its pinned tools with --ignore-scripts.
• Knowledge website builds without a write token. Only its deploy job holds pages: write and id-token: write, and that job runs only from main, once KNOWLEDGE_WEBSITE_ENABLED is true.
• Upstream watch checks out read-only, and its one write scope, issues: write, opens or updates the finding’s issue.
• Knowledge Librarian and .lokf/scripts/ run an LLM agent on a schedule. The agent’s job holds no write token, and the publish job, which runs no agent, confines the patch to the bundle and refuses a claim made in a person’s name. A person merges the pull request. It is inert until KNOWLEDGE_LIBRARIAN_ENABLED is true.
• Knowledge Release attaches the schema copy and the bundle to a release. SECURITY.md says that it is inert until dispatched, and that only its attach job, which runs no third-party packages, can write.
• The README, llms.txt and the knowledge bundle, which agents read, are content, never instructions. A confirmation by a person must be backed by a review or a signed commit.

SECURITY.md says that every workflow declares permissions: {} at the top, pins its actions to commit SHAs that Dependabot keeps current, and runs harden-runner in audit mode. .github/dependabot.yml asks Dependabot for monthly updates of the workflows’ actions, of the package’s uv dependencies and of the sidecar’s uv dependencies in .lokf/.²

Settings

Three protections are repository settings, not files. SECURITY.md says that a ruleset on main blocks deletion and force-pushes and keeps the history linear, and that two are not yet in force: required reviewers on the release Environment, and secret scanning with push protection. Until they are, a qualifying merge releases with no human step. Nothing in CI can assert them, so keeping them on is the maintainer’s job.

Not covered

• GitHub Actions itself, which goes to GitHub’s bug bounty, and SchemaStore’s schemas, which go to SchemaStore’s issue tracker;
• LinkML, its generators and its runtime, which go to LinkML;
• a compromised runner, upstream action or agent harness, since the policy is a baseline, not a sandbox, though a finding in one is still welcome;
• whether the knowledge bundle is true: the gate proves who vouched, not what they read.

Footnotes

1. SECURITY.md, every section ↩

2. .github/dependabot.yml, the updates list ↩