Agentic security analysis · runs in your infrastructure
Not another scanner.
All of them.
scanpack runs the scanners your team already trusts — then does the job you'd otherwise do by hand: working out which findings an attacker can actually reach, and writing down why the rest can't.
- Semgrep
- Trivy
- Gitleaks
- Checkov
- Nuclei
- ZAP
- sqlmap
- Syft
- tfsec
- ffuf
- Joern
- Schemathesis
- + more
Runs where your code already lives. Use a cloud model, or keep every byte on your own hardware — air-gapped works.
The problem
Your scan found 462 things.
Which do you do on Monday?
Finding problems was never the hard part. Deciding which ones are real, in your deployment, is — and it's the part that lands on an engineer who has other work to do.
Scanned 1 target; found 462 findings. 261 require action, 201 need no action (22 not applicable, 0 marked ignorable, 179 info-only).
The ones that need you
Ranked by what an attacker could actually do in your deployment — not by the upstream CVSS number. The report opens with the top five, so the first page is a to-do list, not a database dump.
Contextual severity only ever moves down from the upstream rating, never up, and the original is never overwritten — so you can always see what moved. A CVE on CISA's Known Exploited list is held at a floor: it never drops below high, and if it was rated below high to begin with it isn't demoted at all.
The one deliberate exception is a VEX statement that the vulnerable component isn't present in your build. Code you don't ship can't be exploited, however actively it's being exploited elsewhere.
Ranked on
- Reachability from attacker input
- EPSS — probability of exploitation
- CISA KEV — exploited in the wild
- Practicality of the attack in your deployment
The ones that don't — with the reason written down
Every set-aside finding carries a sentence explaining why, written to be read by someone who wasn't in the room: what the upstream rating was, what we found, and what we did about it. That's the artefact you hand an auditor when they ask why you left 201 things alone.
- The upstream CVE severity was 'high', but the affected file is a devcontainer artifact and is not part of the shipped product, so the severity was adjusted to 'info'.
- The upstream CVE severity was 'high', and reachability analysis found the vulnerable code is reachable from a publicly accessible entry point, but the preconditions needed to exploit it are costly relative to the payoff, so the severity was adjusted to 'medium'.
- The upstream CVE severity was 'low', but reachability analysis found the vulnerable code is only reachable once a security gate has been passed, so the severity was adjusted to 'info'.
An honest note on the numbers. Plenty of tools promise to delete 90% of your backlog. On this run scanpack cut the pile you must act on by 44%, and what it actually changed was the order — plus a written, checkable reason attached to all 201 it set aside. A number you can verify in a demo beats a number you can't.
How it works
Detection is a solved problem.
Judgement isn't.
scanpack doesn't re-implement scanners. It orchestrates them, then spends its reasoning budget on the expensive question: does this one actually matter here?
- 01
Run the pack
Every scanner that applies to your target runs against it — code, dependencies, containers, infrastructure definitions, and optionally the running application. You keep the detection quality of the established tools, because it is the established tools doing the detecting.
- 02
Treat each hit as a candidate, not a finding
A CVE that matches a dependency is a question, not an answer. Specialist agents try to prove — or refute — that the vulnerable code is reachable from something an attacker controls, and read the deployment to see whether the precondition even exists.
- 03
Ship one report a person can act on
Ranked actions first, then everything set aside with the reason attached. One audit-ready PDF for the exec and the auditor; SARIF for your existing tooling.
The pack
You don't have to pick a scanner.
Buying a security tool usually means betting on one engine and hoping it covers your stack. scanpack runs them all and makes them agree — so the question stops being which tool and starts being what do I fix.
Source code
- Semgrep
- Joern
- Gitleaks
- Custom AST + call-graph
Injection paths, authentication and session handling, CSP weaknesses, hardcoded secrets, unvalidated request-to-sink data flow.
Dependencies & containers
- Trivy
- Syft
- Dockle
- Dockerfile analysis
Dependency CVEs, OS package vulnerabilities, SBOM, image misconfiguration — running as root, shipping vulnerable-but-unused libraries.
Infrastructure as code
- Checkov
- tfsec
- KICS
- Terraform graph
Misconfigured Terraform and Kubernetes, plus threat modelling over the deployment graph to reason about attacker movement.
Running application
- Nuclei
- OWASP ZAP
- ffuf
- sqlmap
- Schemathesis
- WhatWeb
- TLS checks
Bounded, authorised probing of a live target: endpoint discovery, technology fingerprinting, contract fuzzing, injection and authorisation testing.
DAST runs only against a target you have explicitly authorised, inside a scope and network policy you set.
Cross-referenced against public threat intelligence
- NVD
- OSV.dev
- GitHub Advisory DB
- CISA KEV
- EPSS (FIRST.org)
- CWE
- OWASP
- MITRE ATT&CK
Ranking uses EPSS — the statistical probability a vulnerability is exploited in the wild — and CISA's Known Exploited Vulnerabilities catalogue, not severity alone.
Trust
The failure mode of an AI security tool
is confident nonsense.
A tool that quietly dismisses a real vulnerability is worse than no tool. So the interesting engineering in scanpack isn't the reasoning — it's the constraints around it.
“openssl is in the os ecosystem; no walker available for that
ecosystem. Reachability is left as unknown so the upstream CVE severity
stands.”
It abstains instead of guessing
Absence of evidence produces “unknown”, never a confident all-clear. “Unknown” is a first-class verdict that leaves the upstream severity untouched.
A verdict never deletes a finding
Reasoning can reorder and demote. It cannot make something disappear from the report. Anything excluded needs a positive signal and lands in an explicit “excluded, with reason” list.
Known-exploited bugs have a floor
A CVE on CISA's Known Exploited Vulnerabilities catalogue never falls below high severity. One model verdict cannot bury it.
The record is append-only
Findings and triage decisions are immutable events. Undoing a suppression writes a new event; nothing is ever quietly rewritten. The history is the audit trail.
Deterministic orchestration, judgement at the edges
The pipeline, the scoring arithmetic and the executive summary are ordinary code with tests. The model is used for small, bounded judgements inside that scaffolding — not to drive the run.
One demotion authority, not many
Exactly one component may lower a severity, through exactly one channel. The original scanner severity is never overwritten, so you can always see what moved and why.
Where it runs
Inside your network.
Including the ones with no way out.
Most tools in this category are SaaS: you send them your source and they send back a verdict. For a regulated buyer that's the end of the conversation. scanpack runs where your code already lives.
Your infrastructure
A single command-line tool or container image, running in your CI, on a build server, or on an engineer's machine. No hosted backend to depend on, no cloud account to create.
Your choice of model
Anthropic's Claude when convenience wins, or a fully local model through Ollama or any OpenAI-compatible endpoint when nothing may leave the network. Air-gapped, single-container operation is a design constraint, not an afterthought.
Credentials stay yours
Secrets never enter the datastore, the process arguments, the logs, or an error message. Targets hold references that are resolved fresh for each scan; git credentials pass through an ephemeral helper.
Two outputs, both boring on purpose
One audit-ready PDF that an executive can sign off and an auditor can read without a security background — and SARIF, so your existing dashboards, code-scanning views and ticket automation keep working.
- report.pdf
- results.sarif
Register interest
Find out what your
number is.
scanpack is in private development. Leave your details and we'll be in touch as places open up — including the chance to have it run against a codebase you choose, so you can check the numbers yourself.
- No newsletter. We contact you about scanpack, nothing else.
- Your details go to a database we run. They are not sold or shared.
- One line in a reply gets you removed, permanently.