Does it upload my code?
No. The analysis runs where the file already is. The only thing the main scan sends is the list of package names and versions your application declares, to check them against published advisories, and that can be switched off entirely.
The one exception is opt-in and obvious: if you tick the deep pass, the files it reads go to the provider you chose and paid for. It is off by default, asked per scan, and the report lists exactly which files were sent.
Can it tell me an application is safe?
No, and it will never say so. Static analysis can demonstrate that bad patterns are present. It cannot demonstrate that none are.
A deliberately malicious application will usually read cleaner than a sloppy honest one, because someone hiding something writes carefully. So the best result Halation prints is "No known issues found", which is a statement about the checks that ran, not about the application. There is a test in the codebase asserting that no band label ever contains the words "safe" or "install".
My application works fine and it scored badly
Three things are worth checking, in order.
- Is it a dependency finding? Those are published advisories against the exact versions you ship. They say nothing about whether your code reaches the vulnerable path, and they are usually fixed by an upgrade rather than by a change to your own code.
- Is it under "What this application can do"? Updating itself and starting with Windows are capabilities, not defects. They are listed separately and score nothing.
- Is it a real finding you had not thought about? One critical caps the score at 39 no matter how much else passed, deliberately. A live API key in a shipped bundle is not offset by fifty things done correctly.
If a capability is central to what your application is for, Halation asks about it directly rather than making you argue with a number, and prints your answer back in the report.
It scored 100 and I don't believe it
Check the coverage figure, and check whether the report says a class of check could not run. A shipped application with no lock file cannot have its dependencies checked at all, and that caveat is printed beside the score for exactly this reason.
100 means the checks that ran found nothing. It does not mean much when very few of them could run, which is why coverage is never folded into the number.
Can I compare two applications by their scores?
Cautiously, and only at similar coverage. Two source trees both read at 95% are roughly comparable. A source tree at 95% and a native binary at 4% are not: the second was barely read, which is why it gets no score at all rather than a flattering one.
The number itself is designed to be comparable in one specific way: it comes from the deterministic checks alone, so it means the same thing in everybody's report regardless of what AI model, if any, they had configured.
It's free. What's the catch?
There isn't one. One build, everything unlocked, MIT licensed, no account, no licence keys, no tiers, no telemetry.
The only thing that costs money is the optional deep pass, and that money does not come here: you bring your own credential and pay your own provider, or run a model on your own machine and pay nobody. There is no hosted relay, deliberately, which also means there is no server holding a list of what anyone scanned.
Is there a Mac or Linux version?
Not today. The interface is WPF, which is Windows-only. The analysis engine underneath it is a plain .NET library with no Windows dependency, so a port is possible in principle, but nothing is in progress.
Can I run it in CI?
Not yet, honestly. Halation is a desktop application. You can pass it a path on the command line, which opens it with that scan already running and is useful for a "Send to" shortcut, but it opens a window and it does not set an exit code or write a report to a pipe. There is no headless mode.
Reports export to Markdown and JSON from the results screen, so the data is available; it just needs a person to press the button today.
Why does Windows warn me when I download it?
Because the release is not code-signed yet. SmartScreen is telling you it cannot identify the publisher, which is true and is a fair thing to tell you.
Signing is the next thing on the list. In the meantime the source is public, the build is
one dotnet publish away from it, and you are welcome to build it yourself
rather than trust a download.
The same missing signature is why Halation will not install its own updates. It applies to itself the rule it applies to everyone else.
Is this an antivirus?
No, and it is not a substitute for one. An antivirus recognises known-bad files and watches what a program does while it runs. Halation reads code and reports patterns, without ever executing anything.
There is some overlap: a handful of checks look for behaviour with few honest uses, such as reading saved browser passwords or cryptocurrency wallet storage, and those are the only ones that can advise against installing on their own. But novel malware that does nothing on that list will pass, and that is a real limit rather than a caveat.
Do I need the deep pass?
No. The main scan is the product; the deep pass is a second opinion. It earns its place on questions a pattern cannot express, such as whether a guard is complete or whether untrusted input actually reaches a dangerous call.
It is worth most when you have the source, and worth least against a decompiled binary, because decompiling destroys every comment and the AI half reasons about intent. It cannot move the score, and it cannot trigger a do-not-install verdict.
It said it couldn't read my application
Then it will say that rather than report an empty result, which is the intended behaviour. The likely causes:
- A native binary. Go, Rust, C and C++ executables have nothing to decompile. Nothing can read those, not just this.
- An Inno Setup installer, or an NSIS one using solid compression. Not supported yet.
- An obfuscated build. It decompiles into thousands of files of
a.b(c), which are not understood and so do not count towards coverage.
If you wrote the application, scan the source tree instead of the release. You will get full coverage and a much better deep pass.
Why OSV.dev and not the NVD?
OSV is built around package ecosystems, which is the shape of the question being asked: "is this exact version of this exact package known to be vulnerable". It answers in one batched request, has no API key, and does the version-range matching itself, so there is no semver arithmetic here to get subtly wrong.
Findings still carry CVE identifiers and link through to the NVD entry, so you land in the same place; the lookup route is just better suited.
I think a finding is wrong
Please report it. False positives are treated as defects rather than noise, because a
developer told three times that apiKey = process.env.API_KEY is a hardcoded
credential stops reading, and the true positive goes unread with them.
Quote the rule identifier and the line it fired on. Open an issue.