signal-bot/SECURITY.md

Security Policy

Scope of a linked device

This bot runs as a linked device on an existing Signal account. That means it can read every direct message and every group on that account, and anything it sends is sent as the account owner. It is not a separate identity.

GROUP_IDS is the only thing that narrows this. The bot therefore:

• refuses to start when GROUP_IDS is missing or blank, rather than defaulting to an empty string that matches nothing predictably;
• drops messages with no groupInfo (direct messages) explicitly, in counting.watched_group, rather than relying on a falsy comparison;
• resolves a message's group once, and uses that one answer as the reply address and the key for all per-group state, so the scoping gate and the reply router cannot disagree and answer in the wrong group;
• ships a scoping scenario asserting that direct messages and other groups produce zero outbound messages, run by scripts/e2e.sh in CI.

If you widen that boundary, the scoping scenario is what should fail.

Secrets

.env is gitignored and never committed. .env.sample contains no real values. The bot reads no credentials of its own: authentication is the signal-cli data directory mounted into the container, which stays on the host.

Reporting a vulnerability

Open an issue at https://github.com/kuhyx/signal-bot/issues. If the issue would expose message content or account access, say so without a working proof of concept in the public issue.

Dependencies

Every dependency is exact-pinned at its newest stable release and checked by scripts/check_dependency_freshness.sh in pre-commit and CI. There are no pre-release pins.