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 installorgo getwith 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.
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(orAttend) fails the build at that decision or worse. Exit codes: 0 ok, 1 error, 2 usage, 3 gate failed.--sarifwrites 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/ciscans 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.
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.