Security policy
Report a problem in the scanner’s security boundaries privately, without sending live secrets or proprietary source.
Start with a small, safe reproduction
Email vulnerability reports to security@zedbee.dev. Use this address for a suspected security flaw in Zedbee itself, including its handling of repository inputs or analyzer output.
Include the affected Zedbee version or commit, platform, the boundary involved, expected and observed behavior, and the smallest synthetic proof of concept. For a third-party analyzer issue, also identify its package and pinned version.
Do not attach credentials, proprietary source code, or other live secrets to an initial email or a public issue. If more information is needed, the project owner may arrange a safer private transfer method.
Replace real credentials and private project content with synthetic fixtures. Do not publish an unredacted scan report or sensitive exploit details in a public issue.
Affected Zedbee version or commit:
Operating system and Node.js version:
Affected analyzer and pinned version, if relevant:
Security boundary involved:
Expected behavior:
Observed behavior:
Steps to reproduce with synthetic data:Support begins with the first public beta
Zedbee is not yet publicly released. The package’s security policy takes effect with the first public beta; this table is not an announcement that a release is already available.
| Version | Support |
|---|---|
0.1.x | Supported from the first public beta, including published 0.1.x prereleases. |
| Unpublished development snapshots | No guaranteed support. Reproduce against the latest published 0.1.x release when one is available. |
For a local installation, npm ls zedbee --depth=0 identifies the installed package version. If you are running an unpublished checkout, include its commit as well. Do not substitute the documentation website’s version or an analyzer’s version for the Zedbee version.
Distinguish a scanner flaw from a finding in your code
The package’s security policy identifies these as reportable boundary failures:
Reading or executing unstaged or out-of-snapshot repository content as scan input.
Exposing detected secret content, unintended source lines, unsafe absolute temporary paths, or raw analyzer reports.
Running online analysis without its disclosure and configured network policy.
Loading executable project analyzer configuration or running project commands or package-manager lifecycle scripts during a scan.
- Following a staged symlink outside the protected snapshot.
- Silently passing when a required check cannot complete.
Ordinary source excerpts permitted by policy, validated managed paths deliberately shown for report access or cleanup, and explicitly allowed incomplete results are documented behavior. Reports are useful when that behavior crosses its stated boundary, such as a secret appearing despite redaction or an unintended path being exposed.
A finding in your application or a known advisory in one of its dependencies is not automatically a vulnerability in Zedbee. Address it in the affected project. For a suspected scanner flaw, explain what Swarm did outside its documented behavior.
Static analysis cannot find every vulnerability. Structural rules do not provide general interfile dataflow, taint, reachability, or framework-pack analysis. A missed pattern alone does not establish that the scanner’s isolation or data-handling boundary was broken.
Review the scanner’s security boundariesReview intended data handling before preparing a report