ShyftLabs Inc. takes the security of Continuum seriously. This document describes how to report a vulnerability, what to expect after you do, and which versions receive fixes.

We patch security issues on the latest minor release of Continuum. Older minor releases receive a fix only if the underlying issue is critical and an upgrade path is non-trivial.

Please do not open a public GitHub issue for security reports. Public disclosure before a patch is available puts other users at risk.

Use one of the two private channels below:

Include in your report:

• A clear description of the vulnerability and the affected component.
• A minimal reproduction or proof-of-concept (code, request, configuration).
• The Continuum version, Python version, and any relevant dependency versions.
• The impact you observed and any impact you suspect but did not confirm.
• Whether you intend to disclose the issue publicly, and on what timeline.

If you would like to encrypt your email, request our PGP key in your first message and we will send it back over a side channel.

Targets are measured from the moment severity is confirmed, not from initial submission. If a fix will slip a target, the reporter is notified in writing with a revised date and reason.

• We never disclose vulnerability details publicly until a patched version is shipped and users have had a 30-day upgrade window, unless the issue is already public.
• The reporter is credited by name (or handle) in the release notes and the GitHub Security Advisory, unless they explicitly decline.
• We do not currently operate a paid bug-bounty programme. We will, where appropriate, send a thank-you and Continuum swag.

In-scope:

• Code in this repository under src/, scripts/, playground/, and the published Python package shyftlabs-continuum.
• Default configurations shipped in .env.template, docker-compose.yml, and pyproject.toml.
• Documentation under docs/ that recommends an insecure pattern or configuration.

Out of scope (please do not report):

• Vulnerabilities in dependencies that have already been disclosed upstream — open a normal issue if the version pin needs to change.
• Issues that require an attacker to already have local code execution or root on the host.
• Social-engineering attacks against maintainers or contributors.
• Self-XSS, missing security headers on non-authenticated marketing pages, or theoretical issues without a working reproduction.

• CI gate — every pull request must pass ruff (lint) and the unit test suite before it can merge to dev/main.
• Dependency vulnerabilities — Dependabot vulnerability alerts are enabled; vulnerable dependencies are surfaced in the repository Security tab. Automated dependency-bump PRs are intentionally disabled to keep PR noise low — maintainers triage alerts and bump versions as needed.
• Secret scanning — GitHub secret scanning and push protection apply on the public repository, and the project history is scanned for committed credentials.
• Code scanning — static analysis (e.g. CodeQL) may be enabled as the project matures and infrastructure allows.

If you are running Continuum in production, please also:

• Pin your Continuum version (shyftlabs-continuum==X.Y.Z) and review the CHANGELOG.md and Security Advisories before upgrading.
• Subscribe to repository Security Advisories (Watch → Custom → Security alerts).
• Run the agent process with the minimum privileges it needs — never as root, never with broader cloud-IAM scopes than the deployed agents require.
• Treat LLM outputs as untrusted input when feeding them into tools, shells, or database queries.
• Keep mem0, Milvus, Qdrant, Redis, Temporal, and Langfuse reachable only from the application network — never expose them to the public internet without an authenticated proxy.

Non-vulnerability security questions (e.g. "how do I configure X safely") belong in GitHub Discussions. Commercial / enterprise security inquiries (SOC 2, indemnification, custom hardening) go to continuum@shyftlabs.io.

Last updated: 2026-05.