Security
Please report security issues privately. Do not open a public issue.
Reporting
- GitHub (preferred): use private vulnerability reporting. It keeps the report, the fix and the advisory in one place.
- Email: security@3329lens.dev, if you would rather not use GitHub.
Include the 3329lens version, the command you ran, the input that triggered the problem (a minimal manifest, lockfile or advisory file is ideal) and what you expected instead.
What to expect
| Acknowledgement | Within 3 working days |
|---|---|
| Initial assessment | Within 10 working days: whether it is in scope, and a severity |
| Fix or mitigation | Target 90 days from acknowledgement, sooner for high severity |
| Credit | Offered in the advisory and release notes unless you ask us not to |
We follow coordinated disclosure and do not operate a paid bug bounty. Security fixes are issued for the latest published version only.
What counts as a security issue
For a scanner, the security-relevant failure is usually not memory safety. It is reporting the wrong answer about someone else's security. These are treated as vulnerabilities, not ordinary bugs:
- Silent false negatives: a vulnerable package that isn't reported, or
--fail-onpassing when it should have failed. - An advisory database that loads no advisories without an error.
- Cross-ecosystem mismatches, such as a crates.io advisory matching a same-named npm package.
- Path traversal or unintended writes while scanning or writing output.
- Crashes, hangs or unbounded memory on hostile manifests, lockfiles or advisory databases.
- Any network traffic at all: the scanner is offline by design.
The full policy, including what is out of scope, is in SECURITY.md. Machine-readable contact details are in security.txt.