Know What's In Your Artifacts
Before You Ship Them
NeonScan tells you whether the software you are about to deploy, or already run, contains malicious code. It investigates each artifact instead of looking it up in an advisory list, and returns a clear verdict with the reasoning behind it, for your own policy to act on.
It works alongside your SCA and CVE scanners. They tell you what is known. NeonScan tells you what is true.
Four checks, behind every verdict
NeonScan looks past the manifest and inspects what actually ships.
Malware in the artifact
Every binary on the entrypoint path is scanned by the PolySwarm engine network, so known and emerging malware is caught before the image or package reaches production.
Behavior in a sandbox
Packages are installed and imported for real inside a Firecracker microVM with a real network stack. Canary credentials in the guest make exfiltration unambiguous. Container images are scanned, not run.
Source Security Analysis
We analyze the upstream repository for flaws before any advisory exists. For packages, we also flag shipped files that are in neither the tagged source nor an expected build output.
Threat-actor context
Risk is scored against active campaigns targeting your stack and ecosystem, so a package under live attack is weighted higher when it matters most.
How it works
Submit an artifact
Scan an OCI or Docker image, a package from npm, PyPI, Go, Maven, NuGet or Cargo, or a lockfile, from your CI pipeline, your registry, your cluster, or the API.
We inspect what ships
Packages are scanned file by file, detonated in a Firecracker microVM, and compared against their tagged source. For container images, the files the entrypoint can reach are scanned and their source analyzed, without running the image. Every finding is correlated against active threats.
Get one clear verdict
You get a Risk Assessment from 0 to 100 and a Source Verification score, with the rationale behind them, scored against your policy so your team decides what ships.
What a result looks like
Illustrative examples. Every scan returns a Risk Assessment from 0 to 100, a Source Verification percentage, a verdict your policy can act on, and the findings behind it.
acme-web:2.4.1- No malware found on the entrypoint path
- Source behind the entrypoint scanned clean
- No active campaigns targeting this image
[email protected]- Files in the release that are not in the tagged source and are not an expected build artifact (potentially injected at release time)
- High and critical flaws in the source behind the package
- Flagged by multiple engines in the PolySwarm network
Inside NeonScan
Screens from the NeonScan app. Select any image to see it full size.
NeonScan questions
For every container image or open-source package, a Risk Assessment, a Source Verification score, a verdict scored against your policy, and the reasoning behind it.
No, it works alongside them. Those tools report vulnerabilities that are already known and disclosed. NeonScan investigates the artifact itself to find what has no advisory yet: a backdoor added to a package at publish time, an implant added to an image after the build, or a flaw introduced and patched inside a single sprint.
Packages from npm, PyPI, Go, Maven, NuGet and Cargo are scanned and detonated, and so are the entries in supported lockfiles. OCI and Docker images, Zarf packages and UDS bundles are scanned but not run. Ruby, PHP and Windows containers are not supported today.
In your CI/CD pipeline or registry, before a cluster pulls an image, with your own policy deciding what each verdict means. As a watcher inside your cluster that checks running workloads and re-checks them as our intelligence improves. Or directly over the API. It can also run fully disconnected for air-gapped environments.
Request a demo and tell us about your stack and what you need to scan. Our team will follow up directly and get you set up.
Get started with NeonScan
Tell us about your stack and what you need to scan, and we will get you set up.