For engineers

The NextFix™ findings queue is sorted so the thing to fix first is at the top, and each finding opens with everything you need to fix it: the reason, the path, the command, and a ticket.

The queue

Everything you need to fix it, in one place

  • The reason in plain English. Line by line: what the vulnerability is, how it is reached, whether the route needs a login, whether the service is published on a port, and what the exploitation data says.
  • The call path. From the route, through each function, to the vulnerable line, with file names and line numbers, and a marker where request data enters.
  • The fix command. npm install, pip install or go get with the version that closes the finding, or the Dockerfile change for a package in the image.
  • Copy as ticket. The same text as Markdown, ready for any tracker.
  • GitHub issue or Jira ticket in one click. Connect a repository or a Jira project once in Settings; then create a ticket from a finding, or one for every finding that needs action. Created tickets are remembered, so a retry never makes a duplicate.
  • VEX download. The OpenVEX document for the scan.
The NextFix Findings screen for OWASP PyGoat: 141 findings across 34 packages, 20 needing action, sorted by decision and score, with the package, the advisory, the severity, how it is reached, the route, and the version that fixes it.
The queue for OWASP PyGoat: 141 findings, 20 that need action, sorted by decision and score. The filters at the top narrow it by decision, reachability or a search, and the filters live in the address bar so a link to a filtered queue can be shared.

Pipelines

A build gate, and SARIF for code scanning

One command runs the whole analysis and exits with code 3 when anything is decided fix now, so a build can be gated on “nothing urgent” while the full report is kept as an artefact.

nextfix scan ./my-app --json out.json --sarif out.sarif --fail-on Act
  • --fail-on Act (or Attend) fails the build at that decision or worse. Exit codes: 0 ok, 1 error, 2 usage, 3 gate failed.
  • --sarif writes SARIF 2.1.0 for GitHub code scanning: one rule per advisory, one result per finding, with the lockfile line, the entry point and the vulnerable call as locations.
  • A ready-made GitHub Actions workflow in docs/ci scans with the gate, uploads the SARIF, keeps the JSON, and posts a pull-request comment with the verdict, the decision counts and the shortest path to green.

For auditors

Every set-aside carries its evidence

The Evidence screen lists everything that was set aside, grouped by reason, and each group names the OpenVEX justification it exports. Exceptions a person approved sit in their own group with the name, the date and the reason on top.

The NextFix Evidence screen in the light theme: groups for accepted by a person, development dependency not shipped, and installed but never imported, each labelled with its OpenVEX justification, and a download VEX button.
The Evidence screen, in the light theme. Every entry is exported as an OpenVEX statement.

Per project

A small config file when the defaults are wrong

An optional nextfix.config.json in the project root names your own login guards, folders to ignore, routes that are internal despite having no login, and the container image or SBOM files to read. NextFix treats a project's own config as untrusted input: an image reference that points at a path on the host is ignored with a log line.