Your First Scan

​

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 archive, or by importing an existing CycloneDX or SPDX SBOM document (JSON only).

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. 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. 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 extracting the source, fingerprinting files, matching against the SCANOSS index, then finalising. The optional scanners you selected, with Cryptography on, a Detecting Cryptography stage, start as soon as extraction finishes and run alongside that matching work 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. 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.

​

Activity: Every Run, Kept

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.

​

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.