Please report privately through GitHub Security Advisories rather than opening a public issue.
Include what the flaw is, how to reproduce it, and what an attacker gets from it. You can expect an initial response within a few days.
Please do not use this channel for false positives or missed detections. Those are ordinary issues and belong in the issue tracker.
toolpoison is a security tool, so its own failure modes matter:
- Credential disclosure. Any path where a real credential reaches terminal output, a JSON or SARIF report, or a log. All output is supposed to be masked.
- Code execution during a static scan.
toolpoison scanwithout--deepmust never execute anything from a config it is reading. A way to make it do so is a serious bug. - Escape from deep-mode assumptions.
--deepruns configured commands by design, but it must do so withshell: false, with a timeout, and without interpreting config values as shell input. - Denial of service. A config that hangs the scanner indefinitely or exhausts memory.
- A rule that misses something. That is a new rule request.
- A rule that fires on legitimate config. That is a false positive report.
--deepexecuting a malicious server's command. That is documented behaviour: starting a server is what deep mode does. Only use it on configs whose commands you are willing to run.
These are properties the project intends to keep, and any regression against them is a bug:
- Static scanning performs no execution and no network access.
- There is no telemetry of any kind. Nothing is ever transmitted anywhere.
- Child processes in deep mode are spawned with
shell: false. - The runtime dependency count stays minimal. A tool that flags supply-chain risk should not be one.