Run your first secure scan
Install Zedbee, inspect the proposed policy, and scan the exact change your team is preparing to commit.
By the end of this guide, your repository will have a repeatable quality gate for local development. You will also know what Zedbee inspected, what each result means, and where its security boundary ends.
Install Zedbee
Add Zedbee as a project dependency so every developer and CI environment runs the version selected by the repository.
Zedbee requires Node.js 22.13.0 or newer and a Git repository.
npm install --save-dev zedbeePreview the setup
Run the guided initializer from the repository root.
Zedbee inspects the project, recommends a policy, detects supported hook managers, and shows the exact configuration and hook changes it intends to make.
Nothing is written until you approve the proposal.
Setup also discloses network use. Vulnerability checks send package names, exact versions, and the npm ecosystem identifier to api.osv.dev, not source code or file hashes.
.zedbeerc.jsonc at the root of your project’s Git repository. After setup or any settings edit, run git add .zedbeerc.jsonc so the next local scan uses the update. For CI to use it too, commit and push the file with your code. Local and CI scans normally share the same settings.$ npx zedbee init
detected TypeScript · React 18 · npm
profile recommended (11 checks)
hooks husky detected → .husky/pre-commit
network OSV lookups only · disclosed
writes .zedbeerc.jsonc · .husky/pre-commit
? Apply this plan? [y/n]npx zedbee init --yes
npx zedbee init --format jsonStage the change you want to inspect
Zedbee treats the Git index as the proposed commit.
If you stage a file and then continue editing it, Zedbee scans the staged version. The later working-tree edits remain outside the scan.
This makes the result attributable to the change the team is actually preparing to share.
git add src/authenticate.ts
git diff --cached
npx zedbee scangit add --patch src/authenticate.ts
npx zedbee scanUnderstand the result
A completed scan has three meaningful outcomes.
- 0
- Scan completed without blocking findings
- 1
- Scan completed and repository policy blocked the change
- 2
- Required analysis could not complete
Exit code 2 does not mean the scan passed. It means Zedbee could not produce a trustworthy complete result. Resolve the reported diagnostic and run the scan again.
npx zedbee scan
case $? in
0) echo "Scan completed without blockers" ;;
1) echo "Commit blocked by repository policy" ;;
2) echo "Required analysis was incomplete" ;;
esacSave a complete report
Use explicit output formats when another system needs to consume or retain the result.
Text, JSON, and SARIF exports contain every finding and incomplete-check notification. They are deterministic, ANSI-free, and are not limited by the terminal preview size.
Secret findings are always redacted. Ordinary source excerpts follow the repository’s reporting policy and any explicit source flag.
npx zedbee scan --format text > zedbee-report.txt
npx zedbee scan --format json > zedbee-report.json
npx zedbee scan --format sarif > zedbee.sarifScan committed branch changes in CI
A clean CI checkout normally has no staged changes. Tell Zedbee which committed branch comparison to inspect.
Zedbee resolves the unique merge base between the supplied ref and HEAD, then analyzes the committed changes from that point forward.
It does not fetch branches or deepen shallow history automatically.
git fetch --no-tags origin main
npx zedbee scan \
--base origin/main \
--format sarif > zedbee.sarifYou now have a quality gate
Your repository can now evaluate exact staged changes locally and committed branch changes in CI.
Explore repository policy