Block deploys before they leak.
Protect Your Vibes scans every push and pull request, uploads SARIF to GitHub Code Scanning, and fails the build when new findings exceed your severity threshold. Baseline accepted risks, gate on critical, and keep secrets out of your bundle without slowing down shipping.
Three integration paths
Pick whichever fits your stack. They all talk to the same API and respect the same threshold semantics.
Threshold options
The fail-on input controls when the build breaks. Default is critical so you can add scanning to any repo without immediately breaking main.
| Threshold | Behaviour |
|---|---|
| critical | Fails on any critical finding. The safe default. |
| high | Fails on any critical or high finding. |
| medium | Fails on critical, high, or medium. |
| low | Fails on critical, high, medium, or low. |
| any | Fails on ANY failing check, including info-level. |
| none | Never fails. Scan-only / observation mode. |
Accepted-risk exclusions
When a finding has been triaged, add its check ID to exclude. Excluded IDs are dropped from pass/fail logic, and don't block future builds until you remove them. The full report in the dashboard still shows everything.
exclude: hsts_missing,deep_csp_/dashboardSARIF + GitHub Code Scanning
The action writes a SARIF 2.1.0 file after every run. Pipe it into github/codeql-action/upload-sarifand every failing finding lands in the repository's Security tab with full dedupe across runs.
Needs security-events: write and a repository on a plan that includes Code Scanning (public repos free; private repos require GitHub Advanced Security).
Other CI systems
GitLab CI
security_scan:
image: node:20
script:
- npx -y @protectyourvibes/scan $STAGING_URL --junit --output=pyv-junit.xml --fail-on=high
artifacts:
when: always
reports:
junit: pyv-junit.xml
variables:
PYV_API_KEY: $PYV_API_KEYCircleCI
version: 2.1
jobs:
security-scan:
docker:
- image: cimg/node:20.0
steps:
- run:
name: Protect Your Vibes
command: npx -y @protectyourvibes/scan https://staging.example.com --fail-on=critical
workflows:
ci: { jobs: [security-scan] }Jenkins
pipeline {
agent any
environment { PYV_API_KEY = credentials('pyv-api-key') }
stages {
stage('Scan') {
steps {
sh 'npx -y @protectyourvibes/scan https://staging.example.com --junit --output=pyv.xml'
junit 'pyv.xml'
}
}
}
}Vercel
# In a GitHub Action that triggers on vercel deploy preview
- run: npx -y @protectyourvibes/scan $VERCEL_PREVIEW_URL --fail-on=high
env:
PYV_API_KEY: ${{ secrets.PYV_API_KEY }}PR comment bot
Coming in v1.1A hosted bot that posts the Markdown summary as a PR comment, updates it across force-pushes, and hides it when findings resolve. Today you can replicate this in 15 lines of actions/github-script — see the Action README for the snippet.
FAQ
Does the scan hit my production site?
By default it runs at the passive tier — anonymous-safe GETs, no writes, no auth bypass attempts. Verified-ownership scans (which pull sample rows) require the active tier and a verified domain claim.
Can I self-host?
Team and Enterprise plans support self-hosted deploys. Set --base-url / base-url on the CLI or Action to point at your instance.
How long does a scan take?
30–90 seconds for most apps. Deep crawl is enabled by default (up to 10 discovered pages). Increase your CI job timeout to 180s for large apps.
What happens if the scanner can't reach my site?
You get a critical `unreachable` finding plus fetch diagnostics. Common causes are Cloudflare bot protection, IP allowlists, or auth-gated staging — allowlist our egress IPs or scan a publicly-reachable preview environment.
Does the API key need any special scopes?
`scan:write`. The /settings page creates keys with that scope by default.