VICE: a two-mode security auditor that scores your web app and gates pull requests

Two modes, and they are different instruments

VICE is a security auditing CLI tool that finds vulnerabilities in web applications, and the design decision that shapes everything is that it has two modes with different evidence bases. A remote scan gives it a URL. It crawls the site with a real browser, inspects public client resources, qualifies exposed services, checks Supabase access controls, and runs bounded read-only security probes within the selected target scope. The word bounded matters, since the probes are read-only and confined to the scope you selected. A local audit points it at your project directory. It reads your source code, checks your .env files, runs npm audit, analyses your Supabase migrations for missing row level security, finds SQL injection and XSS in your code, and tells you what to fix. The distinction is the interesting part. The black-box mode can only see what an outside attacker could see, which is why the browser and the client resources matter. The white-box mode reads the actual source, so it can find injection points in a route that has no discoverable entry point.

The score caps are published, which is the unusual part

Most scanners hand you a list of findings and leave you to decide what matters. VICE does something more opinionated and, unusually, documents it. Version 3.5.0 is described as improving observed application discovery, detection evidence and scoring, and the README states the caps: confirmed critical and high findings cap the score at 39 and 69 respectively. Partial coverage caps it at 89, and incomplete coverage caps it at 49. Existing reports keep their original scores, so a stored report does not change meaning when the tool is upgraded. Two things follow from those numbers. The first is that a low score has a diagnosis, whether it came from a confirmed critical finding or from the run not covering enough of the application. The second is that the difference between 89 and 49 is the difference between a scan that saw most of the app and one that did not, and reading the coverage state before quoting a score is what stops a badge from meaning less than it appears to. The project is built by Webba Creative Technologies, is MIT licensed, and the last push to the repository was on 2026-09-23 with the v3.5.0 release the same day.

Installing is one global npm command, and Node 22 is the floor

The quick start is short. Node.js 22.12 or later is required, and the README is direct about the order of operations, saying to upgrade Node before updating VICE. The install is a single command:

# Install globally
npm install -g vice-security

# Interactive mode
vice

# Or run directly
vice scan              # Remote scan (black-box)
vice audit .           # Local audit (white-box)
vice audit . --ci      # CI mode (exit code 0 or 1)
vice history           # View saved reports

The package is published to npm as vice-security, and the package.json confirms the shape. The main entry and the bin entry both point at bin/vice.js, the module is an ES module, and the files array ships only bin/, src/, scan.js and the three documentation files, so the published package is the CLI and nothing else. The engines field requires Node 22.12 or newer, and the runtime dependencies are small: chalk for output colouring, inquirer for the interactive prompts, ora for the spinner, and tldts for top-level-domain parsing, which is what lets the tool reason about which parts of a URL are in scope. Puppeteer is an optional dependency, and the README is explicit that Chromium remains optional for local audits while remote scans need it for full browser coverage, with an HTTP fallback reported as incomplete coverage.

The GitHub Action is a three-permission pull request gate

VICE ships as a GitHub Action that scans your code on every pull request and push, posts findings as a pull request comment, and maintains a security badge. The workflow file to add asks for three permissions, and the job itself is short:

name: Security
permissions:
  contents: write
  pull-requests: write
  security-events: write
jobs:
  vice:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: Webba-Creative-Technologies/vice@v3

The trigger block is on push to main and on pull requests. Each permission has a job. contents: write is for committing the badge file on push events, pull-requests: write is for posting and updating the comments, and security-events: write is for uploading SARIF findings to Code Scanning. The action inputs are what you would expect and are all documented with defaults: path defaults to the project directory, min-score defaults to 70, and fail-on-score, comment-pr, update-badge and upload-sarif all default to true, with badge-path defaulting to .github/vice-badge.json. The outputs are score, grade, total-findings, critical-findings, high-findings and report-path, and the README notes you can chain them in later steps through the step id syntax. The badge file is committed to your default branch on push, and the README gives the Markdown snippet for embedding it.

SARIF findings show up next to CodeQL in the Security tab

The Code Scanning integration is where the tool meets GitHub's existing security surface, and the README is specific about where results land. Findings are uploaded as SARIF, the Static Analysis Results Interchange Format, on every run, and they appear in three places: the Security tab under Code scanning alerts, alongside CodeQL and other scanners, inline annotations on the changed lines of pull request diffs, and the organisation's Security overview for repos that enable it. That inline annotation point is the one that changes how a team works, because a finding on a line someone just changed in a pull request is read by the person who introduced it, in the place they are already looking. The workflow needs security-events: write for this, which the quickstart already includes, and for private repositories GitHub Advanced Security must be enabled, while public repos get it for free. If you only want the pull request comments, the upload-sarif input set to false turns the SARIF path off. There is also a diff against the base branch, so when a badge already exists on the base, the comment shows the score delta.

Twenty-seven modules, and a category list that will not match every stack

The badge in the README reports 27 modules, and the package keywords list what they cover: supabase, pentest, xss, sql-injection, owasp, rls, headers and csp. That keyword list is a fair summary of the scope. The Supabase support is unusually deep for a scanner, since the local audit analyses your migrations for missing row level security and the remote scan checks Supabase access controls, which is a specific and hard problem that generic scanners miss. The rest is a conventional web application checklist: cross-site scripting, SQL injection, security headers, content security policy. The limitation follows from that scope. The tool is pointed at web applications and at Supabase in particular, and the module count is fixed at 27, so if your stack exposes something the checklist does not cover, no configuration will add it. There is also a .viceignore file at the repository root, which is the exclusion mechanism for paths you do not want scanned, and the fact that it exists is a reminder that a scanner reading a whole repository will find things in directories that are not your application. The keyword list also includes pentest, so this is positioned as an auditing tool that touches offensive technique, which is worth noting if your organisation has a policy on running such scanners against infrastructure it does not own.

Editorial conclusion

VICE suits a team that wants a repeatable security check in the pull request loop, that prefers a published score and grade over an unbounded list of findings, and that is willing to fix the categories the tool checks rather than treat it as a complete audit. It is the wrong choice if you need a broad standards-based assessment against a framework, and it is the wrong choice for an application whose framework is not in its module list. Verify first which of the 27 modules apply to your stack, that the score thresholds in the action match the bar you actually want, and that the coverage caps in the scoring rules reflect the scan you ran before you publish a badge from it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Webba-Creative-Technologies/vice on GitHub