Unknown bugs,
with the way in.

Bugs nobody has filed yet, by weakness type, each with the path an attacker takes to it. From the compiled binary alone, no source, no device, nothing executed.

Drop a binarySee real findings
FINDINGS · /USR/SBIN/HTTPD · ELF ARM · 212 FUNCTIONS · STRIPPED14 FINDINGS · 6 REACHABLE FROM MAIN · SARIF
By weakness typeBugs listed by CWE id, 72 types, 71 with a detector.
With the pathEach finding says whether a path from the program's start reaches it, and shows that path.
ConfirmedA fuzzer runs the handler and returns the input that triggers the bug.

A warning is not a bug.
A path is.

A static scanner lists every dangerous call and leaves the reading to you. Most of the list is code the program never reaches.

Under the Cyber Resilience Act you answer for every binary you ship, source or not.

Findings by weakness type, with the path from main.

Unknown bugs in compiled codeBugs nobody has filed yet, found in the code itself. A stripped binary with no source or symbols is enough.
Reachable from main, or notEvery finding says whether a call path from the program's start reaches it, and shows that path. It also says whether the path passes a login check first.
SARIF to GitHub code scanningOne SARIF report per binary, per source tree and per firmware image, built to GitHub code scanning limits.
Attack surface and fuzzing
Ways in, with the handlerNetwork, file, IPC and XPC entry points, each with the function that receives the input. Linux, Windows and macOS binaries.
Any handler on generated inputsPick a handler, or any function. openbinary feeds it generated inputs in its emulator, a stand-in for the device, on every architecture it reads.
A bug with its inputA crash comes back as a weakness type, the input that triggers it and a replay.
From the API and the agentStart a run from the web app, the API or an AI agent.
Secrets, hardening, source
Embedded keys and credentialsPrivate keys, passwords and API tokens found in the binary, each checked for validity. Shown to your workspace only.
Build hardeningPIE, stack canaries, fortify, NX and PAC checked per binary. A missing flag is listed with the binary that lacks it.
Source audit alongsideSource in the same upload is read as well. C, C#, Go, Java, JavaScript, Kotlin, Perl, PHP, Python, Ruby and Swift, with their dependency manifests.

Anatomy of one finding.

Every finding carries the same five facts, so a false one is dismissed in a minute.

WeaknessCWE-121 Stack buffer overflow1024 bytes received into a 256 byte buffer
Functionhttp_parse_request()int n = recv(fd, buf, 1024, 0);1024 into 256strcpy(out, buf);dangerous call
Path from mainmain→ http_server_loop→ accept_client→ http_parse_requestbefore any login
Fuzz inputCrash after 1.8 s1,031 bytes, saved, replays without the device
SARIF"ruleId": "CWE-121","level": "error"one report per binary, GitHub code scanning
Where it stops, it says so
Not reachableReported as found, no path from main. The finding stays. A bug in code nobody calls is still a bug.
Not triggeredA fuzz run that finds nothing says not triggered, with the coverage it reached. Never refuted.
Held at the handlerA confirmed bug says whether it held for the handler alone or from the entry point.
UnsupportedA binary the engine cannot read is marked unsupported, with the reason. No findings are invented for it.

Built for. The people who answer for the bug.

Device makersFix what is reachable before the release ships, and report the rest with its evidence.
Security teamsDecide whether the build you run reaches the function named in the advisory.
Red teamsPick the first bug to chase, the one reachable before any login.
72weakness types referenced71 with a detector
20of MITRE's Top 25 coveredcwe_checker checks 18
11kinds of secret found in binarieseach kind with a validator
48architectures decodedGhidra 37, IDA 12

Binary vulnerability analysis, asked plainly.

Short answers. Docs has the long ones.

Read the docs
  1. 01

    How do I get a binary analysed?

    Drop a file, call the API, or install the GitHub App and every release asset is analysed on publish. Source files in the same upload are read too.

  2. 02

    Does it find CVEs or unknown bugs?

    Known CVEs come from the components inside and sit on the SBOM page. This page lists bugs nobody has filed yet, found in the code itself.

  3. 03

    How many false positives?

    Each finding carries its function, the dangerous call and the path, so a false one is quick to dismiss. Findings are labelled beta until precision on real binaries is published.

  4. 04

    What does reachable mean here?

    A call path from the program's start to the bug, shown in full, and whether it crosses a login check. CVE matches on the SBOM page carry no such path.

  5. 05

    Does the fuzzer run my binary?

    Only inside openbinary's emulator, a stand-in for the device. A crash comes back as a weakness type with the input that triggers it and a replay.

  6. 06

    Can it go into GitHub code scanning?

    Yes, one SARIF report per binary, per source tree or per firmware image, built to GitHub's limits. The GitHub App analyses every release asset when it is published.

  7. 07

    Can an agent read the findings for me?

    Yes. Findings, paths and the fuzzer are agent tools. One command installs all 69 into the agent you already use.

Drop a binary.

Mach-O, ELF, PE, DEX, WASM, firmware, container and archive images. Up to 2 GB. The report is public unless you sign in.

Choose a fileSet up an agent