Check a dependency list before it ships.

Upload an SBOM or lockfile. Every package is checked against malware and vulnerability databases, its publishing history, and its install code. Nothing is installed or run.

CycloneDX
SPDX
requirements.txt
package.json
package-lock.json

Drop a file hereor click to choose one, up to 5 MB

Paste the contents instead

No input yet.

Try a sample

Options

Search the web for reportsOnly for flagged packages. A result counts when the page is about that exact package. Written summary by an LLMExplains each finding and gives a second opinion on false positives. Never changes the verdict. Ignore malware databasesShows what package signals and code inspection catch on their own, as for a package nobody has reported yet.

In Finnish folklore every place has a haltija, a guardian spirit that watches over a house, a sauna or a forest. This one watches over your build.

How a verdict is reached

Every package in the SBOM is checked three ways: against databases of known threats, against its own publishing history, and, when something already looks off, by reading its code. Evidence from the web can raise suspicion but never decides on its own.

Databases and fixed rules decideThe same SBOM gets the same verdict. The LLM explains and second-guesses, but never changes a verdict or the gate.

Every reason is shownEach signal, its weight, the code line it came from, and every false-positive veto appear next to the verdict.

Destructive steps need proofOnly confirmed malware or a vulnerability exploited in the wild fails the build. Suspicion leads to review, not removal.

The pipeline

A scan parses the file into exact package versions, then gathers four kinds of evidence. Known threats and package signals run for every package; the slower checks only run where there is already a reason to look.

Your SBOMCycloneDX, SPDX, requirements.txt, package.json, package-lock.json

ParseExact name and version for every package, nested ones included

Known threatsOSV.dev malware reports and CVEs, CISA's exploited list (KEV), EPSS exploit probabilityevery package

Package signalsRegistry history: age, releases, install hooks, publisher changes, look-alike namesevery package

Code inspectionReads install and import-time code in memory, never runs itonly with a warning sign

Outside evidenceSource repository, web reports, hosts in the code, security write-upscontext, can't decide alone

Score and verdictMalicious, suspicious, vulnerable or no issues, with every reason listed

CI gateFails on malware or an exploited vulnerability

Response checklistWhat to do, in order of urgency

Solid boxes can decide a verdict. The dashed box only adds weight to a package that already shows warning signs. The LLM sits beside the pipeline: it writes summaries and briefs from the same evidence.

Verdicts and the gate

Each package goes through the same questions in the same order. The first "yes" sets its verdict; the verdicts then decide the gate.

Is there a malware report for this exact version?OSV malware advisories, including OpenSSF's malicious-packages list

yes

Malicious

Is the package-signal score at least 0.5, with at least one sign that isn't about age?Being new alone never flags a package

yes

Suspicious

Does this version have a known vulnerability?CVEs and GitHub advisories via OSV

yes

Vulnerable

Nothing found

No issues

The gate

FailAny malicious package, or any vulnerability on CISA's exploited listHTTP 409

WarnSuspicious packages, nothing confirmedHTTP 200

PassEverything else, including ordinary CVEs (they go into the patch)HTTP 200

How the package-signal score works

Each warning sign has a weight between 0 and 1: roughly, how likely it is on its own that a package showing it is malicious. Signs are combined so that several weak ones add up, but no pile of weak ones reaches certainty:

score = 1 − (1 − w₁) × (1 − w₂) × …Example: acme-internal-billing@999.0.0 has an implausible version (0.50) and isn't on the registry (0.50): 1 − 0.5 × 0.5 = 0.75, so it's suspicious.

Weights for signals that occur often enough in the evaluation data were fitted on a development split, aiming for the most caught malware at a false-positive rate of at most 0.5%. Rare signals keep their hand-set value. Current weights:

Loading…

False-positive guards

Popular look-alikes are not squats.A name close to a popular package is ignored when the package itself is widely used or long established.
Age is never enough.New, few releases and fresh release only count alongside a sign that isn't about age.
Missing repository links only count for long-tail packages,because old versions of popular packages often lack them.
Code rules ignore comments, docstrings, tests and docs,and credential theft needs reading and sending in the same file.

Code inspection

Downloading every archive would be slow and noisy, so only long-tail packages that already show a warning sign (or have install hooks) are read. Nothing is extracted to disk and nothing is executed.

Pick candidatesLong-tail packages with a warning sign

Download into memorySize-capped, with a zip-bomb guard

Read, never runsetup.py, .pth files, install scripts, entry modules

Mask noiseComments, docstrings, tests and docs are blanked out first

Match rulesExfiltration, reverse shells, decoded exec, credential theft, persistence

Signals with evidenceEach one cites file, line and snippet

Ranking vulnerabilities

Severity alone is a poor guide: most critical CVEs are never exploited. Haltija combines how bad a vulnerability is (CVSS) with how likely it is to be exploited in the next 30 days (EPSS), and anything on CISA's list of vulnerabilities already exploited in the wild goes straight to the top.

priority = 0.6 × CVSS / 10 + 0.4 × min(1, 4 × EPSS)An EPSS of 25% or more already counts as fully likely. Exploited in the wild (KEV) sets priority to at least 0.95 and fails the gate.

NowExploited in the wild, or CVSS ≥ 7 with EPSS ≥ 10%

BatchA patch or minor upgrade fixes it: low risk, apply together

PlanOnly a major upgrade fixes it: schedule and test

No fix yetCheck whether you use the affected feature

The upgrade target is the nearest release that fixes every advisory on that package, so one change clears them all.

Evidence from outside the package

These checks look beyond the package itself. Each has a strict rule for what counts, because the web is full of pages that mention a package without being about it.

Source repository

Fetches the manifest of the GitHub repository the package links to. If that repository publishes a different, popular package, the link borrows someone else's credibility ("starjacking").

Counts: declared name differs and is popular. Monorepos and forks don't count.

Web reports

For flagged packages, searches Exa and context.dev for reports.

Counts: the page is about this exact package (name in title or address) and says it's malicious. For popular packages the page must also name the version.

Hosts in the code

Domains and IPs found by code inspection are looked up in stored write-ups and on the web: far more specific than searching a name.

Counts: the page names that exact host near a threat word. Shared platforms (GitHub, Discord, clouds) are skipped.

Security write-ups

Recent articles by supply-chain researchers are read regularly, and the packages and indicators they call malicious are stored.

Counts: the article names the package as malicious, not as the one being imitated. Names not in the text are dropped.

How write-ups are used

SearchRecent write-ups via Exa and context.dev

ReadFull article text

ExtractMalicious packages and indicators, by the LLM or conservative rules

ScansA named package gets a weighted signal

Live feedEarly labels, before OSV catches up

Earlier scansRe-checked for newly named packages

The LLM's role

It does

Write the summary for each flagged package from the collected evidence
Give a second opinion on likely false positives
Write incident briefs: what malware takes and what to rotate
Extract package names and indicators from security write-ups

It never

Changes a verdict or a score
Decides the CI gate (the gate doesn't call it at all)
Adds names that aren't in the source text: extracted names are checked against the article

Response

The response step turns findings into a checklist in order of urgency. Reversible steps (notify, patch) can happen straight away; blocking and removal need confirmed evidence, and deploying past a failed gate needs a recorded reason.

1. Respond to malwareRemove it, treat machines as compromised, rotate what it takes

2. Fix vulnerabilitiesNow, batch, plan

3. Decide on suspicious packagesOne guided question each

4. VerifyRe-run the gate

The CI gate

The gate runs the deterministic part of the pipeline only (no web search, no LLM), so the same SBOM always gets the same answer and a flaky provider can't break a build.

Your CI jobUploads the SBOM with curl

Gate scanDatabases, package signals, code, repository check

HTTP 409Prints what blocks the deploy; the build fails

HTTP 200Pass or warn; the build continues

Both answers end with a link to the findings page.

Or from a terminal, without a server: haltija check sbom.cdx.json runs the same checks locally and exits 1 when the deploy should be blocked (pip install -e . in the repository registers the command).

Measuring it

Two independent checks keep the numbers honest. The evaluation replays known malware with the malware databases switched off; the live feed scores packages nobody has judged yet and waits to see which turn out malicious.

Evaluation

Malware: OSV malicious-package advisories for PyPI, split into a development and a test set
Benign: 1,000 long-tail PyPI packages
Each package is scored as of its advisory date, so later deletions don't leak the answer
Weights are fitted on development and reported on test, with 95% confidence intervals

Live feed

New uploadsEvery new PyPI release and npm package

Score and storeWith a timestamp, before anyone has judged it

Check outcomesOSV advisories, write-ups, registry removals

Precision, recall, lead timeOn the Live feed tab

Limits

A compromised release of an established package shows few package signals; diffing it against the previous release would help.
Reachability isn't checked: a vulnerable function you never call still counts.
The evaluation set is PyPI only; npm is covered by the same signals but not separately measured.
Outside evidence is time-dependent, so it isn't part of the evaluation numbers and can only be measured going forward.
Package signals catch about a third of live malware with no false positives on the test set; the rest needs database reports or outside evidence.

Check a dependency list before it ships.

Try a sample

Options

Scanning

Response

How a verdict is reached

The pipeline

Verdicts and the gate

The gate

How the package-signal score works

False-positive guards

Code inspection

Ranking vulnerabilities

Evidence from outside the package

Source repository

Web reports

Hosts in the code

Security write-ups

How write-ups are used

The LLM's role

It does

It never

Response

The CI gate

Measuring it

Evaluation

Live feed

Limits