Dependency management policy
Last updated 2026-11-02
Last updated 2026-11-02.
What this policy covers
Botseon is built on open-source packages and on automation that other people publish. This policy says how we choose, lock, update and check that outside code. The outside services we run on are a separate matter, listed on our sub-processors page. It describes what we do today. Where a piece is not in place yet, we say so. Each section ends with the file in our code that backs the claim. The code repository is private; we show the named file to a customer's security reviewer on request.
Every version is locked
Every package the service installs, and every package those packages install, is recorded with its exact version in one lock file. Our pipeline and our production deploy install with the lock file frozen: if the lock file and the package list disagree, the install fails instead of quietly picking a new version. The version of the package manager itself is fixed too.
Source: pnpm-lock.yaml; package.json (packageManager); .github/workflows/ci.yml and
.github/workflows/deploy-prod.yml (pnpm install --frozen-lockfile).
Pipeline automation is pinned
Almost every automation step our pipeline borrows from another publisher is named with a fixed
major version, such as actions/checkout@v7, rather than a floating "latest". A major version tag
can still be moved by its publisher; one step is pinned to an exact commit instead. Two steps still
follow a moving branch: one step of the production deploy
(superfly/flyctl-actions/setup-flyctl@master) and one step of the developer kit release
(pypa/gh-action-pypi-publish@release/v1). Pinning every step to an exact commit is on our work
list.
Source: .github/workflows/, .github/actions/.
How we update
Today we update packages by hand, in an ordinary pull request that runs every required check. The lock file shows exactly what changed. Automatic weekly update proposals, grouped so related packages move together (Dependabot), are not set up yet. They are on our work list.
Source: pnpm-lock.yaml; the .github/ folder holds no Dependabot configuration file yet.
When a package has a known weakness
Automatic alerts for a vulnerable package are not set up yet, so today we learn of one from the publisher's notice or from a report to security@botseon.com. From then on it is handled under our vulnerability management policy: rated by the harm it can do in our service, fixed by updating or replacing the package, and shipped through the same checks as any other change.
Source: SECURITY.md; the .github/ folder holds no Dependabot configuration file yet.
Licences
The framework is published under the Apache 2.0 licence. A first-party extension must carry the same licence, and a check on every pull request refuses one that does not, or one that names no licence. A third-party extension must carry an open-source licence approved by the Open Source Initiative. A copyleft extension may run only on a bot's own computer, never inside the framework itself. An extension with no licence is not listed.
Source: docs/reference/extension-licensing.md; scripts/ext-verify.mjs;
scripts/gate-manifest.json; LICENSE; NOTICE.
Third-party extensions
Our design for code extensions written by other people is strict. Each one is named in a composition file, its package and every package it depends on are hashed into a lock file, its publisher's signature (a provenance attestation) is verified, and the build refuses any package whose hash or signature does not match. Third-party code runs on a bot's own computer by default, not inside the service.
That lock and signature check is designed, not built. Until it is built, the build refuses any composition file outright, so no third-party code extension can be built into the service.
Source: docs/superpowers/specs/2026-10-23-modular-extensions.md (decision EXT/D6, section 4.5);
scripts/extensions-gen.mjs.