Skip to main content
This guide walks you through evaluating SCANOSS against your own codebase: what each dataset detects, how the tools work, and how to fit them into your existing workflow. Each section is hands-on, you’ll run real scans and see real results, not a simulated demo.

What’s Covered

Each section includes step-by-step instructions, configuration examples, and practical use cases to help you evaluate how SCANOSS fits your organisation’s needs.

How Scanning Works

Before you run your first scan, it’s worth understanding what actually happens to your code, since this is usually the first question a security or legal team asks. SCANOSS never uploads your source code. Every scan runs through the same three steps:
  1. Fingerprint locally. Every SCANOSS tool follows the same procedure: it reads your files on your own machine or build runner and generates a Winnowing fingerprint, a compact set of hashes that represents each file’s content, not the content itself.
  2. Send fingerprints, not files. Only those fingerprints and hashes are sent to the SCANOSS API. There’s no step where your source code, file names, or repository contents leave your environment.
  3. Match and return. SCANOSS compares the fingerprints against its open-source knowledgebase and sends back matched components, licences, vulnerabilities, and cryptography, whichever datasets you enabled.
Every SCANOSS tool covered in this guide is open source, under github.com/scanoss, so you can verify how scanning works yourself rather than take our word for it. Contributions are welcome. See Fast Winnowing & Fingerprinting for how the algorithm itself works.

Where to Start

If you’re new to SCANOSS, Getting Started routes you to the right section based on what you want to evaluate first.