How Ferralon works

Learning that a known vulnerability exists somewhere in your software is the easy part. The costly question is left to your team: can someone actually exploit it in your code, and if you patch it, does the fix hold?

Ferralon works through that question in your own repository. It finds the advisories with a real path into your code, attempts the exploit against a build of your own repository, writes a patch, and runs the same exploit again against the patched build. You review the result as a pull request, with the evidence for each step attached.

Finding where your code is exposed

Ferralon Assay runs as a GitHub Action in your own CI, on your runner, with your workflow's token. On every pull request, every push and once a day, it analyzes your entire codebase. It maps how your code moves from its entry points through your own functions and into everything it imports, and checks those paths against Ferralon's signed advisory corpus.

When Assay can trace a path from your code to vulnerable code, that advisory becomes a candidate. You see candidates in a pull-request comment, a dashboard issue in the repository, and a downloadable report. Once linked, you also see them in the Ferralon console.

Tracing depth depends on the language:

  • Go: traced at the level of individual variables, following data from your entry points to the vulnerable call.
  • Java, JavaScript/TypeScript, Python, .NET and Kotlin: traced through the call graph.

Some code only resolves at run time, such as dynamic dispatch in Python. Where the analysis can't settle a path, the report names the reason and keeps the advisory as a candidate.

You choose how far back the check looks: the last 24 hours of published advisories (the default), 7 days, 30 days, or the full corpus.

Proving exploitability, then proving the fix

For an organization admitted to Ferralon Arc, proving runs automatically on each new candidate.

  1. Build. Arc fetches your source at the analyzed commit through the Ferralon GitHub App. It builds your code from your repository's Dockerfile on a single-use machine; BuildKit features are supported.
  2. Exploit. Arc attempts the exploit against that build. If the exploit succeeds, the advisory is proven exploitable in your code.
  3. Patch. Arc writes a fix.
  4. Re-test. Arc builds the patched code and runs the same exploit again.

The fix is verified when the exploit that succeeded on your original build fails on the patched build. That is a precise claim: the demonstrated attack no longer works in the environment Ferralon tested. We hold ourselves to that narrow claim because it is the one your reviewers can check. Arc then opens a pull request with the patch, and links the evidence from each step for your reviewers to examine before they merge.

When a proof run can't finish

A proof depends on a live environment: your source, your build, a fresh machine and the analysis service. When one of those fails, the console marks the run Proof run did not complete and gives one plain reason, such as source unavailable, build failed or timeout. Each reason comes with a sentence telling you what happened and whether there is anything for you to do.

An incomplete run is reported as exactly that. Ferralon never treats it as evidence that the advisory is safe. The candidate stays open, and the next run tries again.

A corpus you can verify

Every advisory Ferralon checks comes from its published corpus. Each release since October 7, 2026 is signed. Arc's proof machines verify the signature before they use a release, and stop if verification fails, so a tampered corpus can't steer a proof.

You can run the same check yourself with one cosign command, using the identity and issuer listed in the docs.

Getting proofs

Assay is free: install the Ferralon GitHub App and it adds the workflow to your repository through a pull request you merge.

Arc is in early access. Request access from the console, and we admit organizations by hand while we learn from each one. Once your organization is admitted, proofs run automatically on every repository where the App is installed, up to a daily limit per organization.