You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce supply-chain and static-analysis automation: Dependabot (or equivalent)
for pip and GitHub Actions version updates, a pip-audit step in CI for known-vuln
detection in the dependency tree, and CodeQL scanning for the Python source.
Why this matters
A security kernel is held to a higher supply-chain standard than the average
library: adopters will (and should) check whether the project scans itself. The
runtime dependency set is admirably small (httpx, pydantic), but extras pull in
larger trees (mcp, otel, yaml, tiktoken), CI actions are a moving dependency, and
none of it is monitored today. These are low-effort, high-signal controls that also
future-proof releases (a known-vulnerable pin caught before publish, not after).
Current evidence
No .github/dependabot.yml; no pip-audit/CodeQL/security-scanning workflow exists (only ci.yml and publish.yml).
Update-PR noise (grouping mitigates); CodeQL minutes on a small repo are negligible.
Failure-policy tuning needs one iteration to avoid blocking unrelated work.
Summary
Introduce supply-chain and static-analysis automation: Dependabot (or equivalent)
for pip and GitHub Actions version updates, a pip-audit step in CI for known-vuln
detection in the dependency tree, and CodeQL scanning for the Python source.
Why this matters
A security kernel is held to a higher supply-chain standard than the average
library: adopters will (and should) check whether the project scans itself. The
runtime dependency set is admirably small (httpx, pydantic), but extras pull in
larger trees (mcp, otel, yaml, tiktoken), CI actions are a moving dependency, and
none of it is monitored today. These are low-effort, high-signal controls that also
future-proof releases (a known-vulnerable pin caught before publish, not after).
Current evidence
.github/dependabot.yml; no pip-audit/CodeQL/security-scanning workflow exists (onlyci.ymlandpublish.yml).ci.ymluses floating action tags (actions/checkout@v4) — update automation pairs with pinning (ISSUE 56).pyproject.tomlextras:mcp,otel,policy,tiktoken— real third-party trees beyond the minimal core.External context
Dependabot/pip-audit/CodeQL are the standard GitHub-native security baseline (OpenSSF
Scorecard checks measure exactly these).
Proposed implementation
.github/dependabot.yml: weeklypip(with grouped minor/patch updates to limitnoise) +
github-actionsecosystems.pip-auditover the dev environment; decidepolicy for failures (block on HIGH+, warn otherwise) and document it.
until then) — neutral wording.
AI-agent execution notes
.github/workflows/,pyproject.toml(extras and pins), open issue [Community] Add issue templates, SECURITY.md, CODE_OF_CONDUCT, and a curated good-first-issue set #144 (community files) to avoid duplicating its SECURITY.md scope.permissions:blocks — pairs with ISSUE 56).Acceptance criteria
Test plan
Verify first Dependabot PRs, a seeded pip-audit failure in a branch, and a CodeQL
run completing. Run
make ci.Documentation plan
README security section note (until SECURITY.md exists via #144); CHANGELOG
Added(CI).Migration and compatibility notes
Not expected to require migration.
Risks and tradeoffs
Update-PR noise (grouping mitigates); CodeQL minutes on a small repo are negligible.
Failure-policy tuning needs one iteration to avoid blocking unrelated work.
Suggested labels
security, reliability, contributor-experience