Skip to main content

​
How a Scan Runs

A scan reads your code, fingerprints it, matches it against the SCANOSS knowledgebase, and then enriches what it found. You can watch each stage as it runs.

​
Starting a Scan

Scans start in three ways:
  • Automatically, when a repository is first connected.
  • Automatically on merge, to the default branch, if you enable it.
  • On demand, with + New scan, from a connected repository, by uploading a folder or a .zip/.tar.gz archive, or by importing an existing CycloneDX or SPDX SBOM document (JSON only).
An imported SBOM lists declared components only. There’s no code to match, so the run always lands as partial coverage.
A component’s licence, when the document declares one, is kept and shown as From SBOM, distinct from a licence SCANOSS detected itself. Where both exist for the same component, the licence SCANOSS detected always takes precedence.

​
How Your Source Reaches Earnie

A folder upload doesn’t zip your tree in the browser. Earnie first lists every file it can reach, then applies the same keep rules as a Git scan and sends only the retained files. Generated source under directories such as node_modules is normally omitted, but Earnie may retain a dependency manifest inside one of those directories because later scan stages need it, so the file viewer can show that directory with the retained manifest, without the skipped source beside it.
  • A Git scan clones the repository on the server and applies the same keep rules.
  • An archive you supply is unpacked through those rules; the stored scan is the kept files, not the original zip.
A large keep-set can take a while to transfer, that’s expected. You can Cancel scan from the progress page at any in-progress stage; that stops the transfer and every job for that run. A folder or archive receive that sits with no files arriving is failed after one hour.
When your workspace has optional scanners enabled, source scans show a Scanners section listing them. Cryptography is selected by default; you can change the selection for each new scan, but at least one scanner must remain selected. The scan summary lists scanners (OSS, Cryptography) separately from intelligence layers, and a completed run’s Identity card names the same scanners from the stages that actually ran. SBOM imports don’t show scanner choices, since they process the supplied document rather than source code.

​
The Stages of a Run

A standard scan runs through receiving files (folder, Git, and archive keep-set transfers), then fingerprinting, matching against the SCANOSS index, then finalising. Folder and Git scans skip a fat extract of the original tree, you won’t see an Extracting archive stage on those runs; an archive you uploaded still unpacks through the keep engine before fingerprinting. The optional scanners you selected, with Cryptography on, a Detecting Cryptography stage, start as soon as the source is ready and run alongside matching rather than queueing behind it, so a long cryptography scan no longer adds its time to the run. After them comes one stage per intelligence layer you enabled. A scanner stage still sits at Pending until its turn comes, so you can see it’s queued rather than stalled. Each stage reports Done, Running, Skipped, or Failed, so a partial failure tells you exactly which layer to re-run.
An optional intelligence layer can fail without failing the whole scan. The live progress view and the completed run both show the same cause beneath that layer, for example enrichment failed: SCANOSS service unavailable. Your core scan results remain available; re-run the scan after the service recovers to fill that optional intelligence.
Because those stages run together, a scan that fails stops both: whichever stage failed reports its own cause, and the one that was still running is marked Failed with the warning cancelled: sibling phase failed, it was stopped because the run was already over, not because of anything it found. Re-submit the scan once the real cause is addressed; a failed run changes none of your findings. The cryptography scan reports its own steps underneath, as it reaches them: Cryptography — Scanning Source, Cryptography — Scanning Dependencies, and Cryptography — Building Call Graph. A large repository can spend a long time in one of them, so this is how you tell a working scan from a stalled one. A step only appears once the scan actually reaches it, and a step that’s skipped says why, for example, when the project has no dependency manifest the scan can read. An imported SBOM runs a shorter pipeline. There’s no archive to extract and no code to fingerprint, so it shows Importing SBOM, then finalising, then the intelligence layers.
If the document contained anything Earnie couldn’t read, a component with neither a name nor a package identifier, for instance, the Importing SBOM stage carries a warning naming it rather than dropping it silently.

​
When a Run Doesn’t Finish Cleanly

A run that ends without results opens on its own page rather than a bare “Scan failed” line. A run you stopped is labelled Cancelled and says so plainly, nothing was kept and nothing in the project changed. A genuine failure is labelled Failed and describes the cause in ordinary language together with what to do about it, a folder transfer that timed out, for instance, asks you to keep the tab open until receiving finishes. Run details names the stage the run stopped in and how far it got, the source, when it started and ended, the reason code, and the scan id, the thing to quote when you ask an administrator to check the logs. Start a new scan and Back to activity sit in the header; if your role can’t start scans, the page names the role that can instead.

​
Activity: Every Run, Kept

Activity Activity is the history of the project. Every run is kept, filterable by status, and searchable by source.

​
Coverage: Full vs Partial

Coverage is the column to notice. A partial run only ever adds and updates what it saw, it never marks anything absent, because it cannot tell you what isn’t there. That’s why an imported SBOM can never remove a finding an earlier full scan established. The Dashboard and Review Workspace both prefer your most recent full-coverage run. If a project only has partial ones, they fall back to the latest of those and say so, so an imported SBOM still gives you a posture to work with. Treat it as a floor rather than a complete picture, it lists what the document declared, and nothing about the code the document never mentioned.
Re-scanning is cheap, and safe. Decisions you’ve already recorded survive a re-scan. A new run tells you what was added, what’s still present, and what has gone away. It never asks you to triage the same component twice.

​
Crypto Changes Between Scans

When the current run measured cryptography in full, Earnie compares it with the nearest earlier completed run that also has a full cryptography measurement. A nearer run that skipped cryptography or covered only part of the project is skipped rather than blocking an older valid baseline. If no earlier eligible run exists, Earnie omits the comparison rather than turning missing evidence into zero. Crypto changes groups stable identities into four buckets:
  • New
  • Resolved (absent from the current run)
  • Re-detected (reopened, if previously resolved)
  • Still open

​
What’s Next

With a full-coverage scan complete, the next step is reading the Dashboard, the one screen that tells you whether you can ship, what needs a human, and what’s actually dangerous.