Scan categories

Vulnara runs several independent scanners over your repositories. You do not choose between them by name; you choose a category, the kind of problem you want found, and every finding they report is classified into one of those categories too. All of them are brought into one set of findings with one severity scale, so you can compare and triage them together.

What it is for

A category tells you what a finding is without you having to know which tool reported it, and it is also what you choose when you start a scan. In the web app, a scan from the New Scan form has every category your workspace may run selected by default, which gives you the fullest picture. Keep fewer when you only care about one kind of issue or want a faster scan.

The categories

The web app labels each category in plain words; the API, the CLI and the GitHub Action use the value in brackets. They are the same categories everywhere.

• Code analysis (SAST): static analysis of your own code.
• Dependencies (SCA): dependencies with known vulnerabilities, read from the package manifests and lock files in the repository.
• Secrets (SECRETS): credentials and tokens committed to the repository, such as keys and access tokens.
• Personal data (PII): personal data in the repository, such as email addresses, credit card numbers, social security numbers and IP addresses.
• Web application (DAST): testing a running web application from the outside, rather than reading a repository. Enabled per workspace on request. You scan a web application by adding it as a web application, not from the repository scan or schedule forms. See Scan a web application.

A category is a property of the finding, not of the tool that reported it. A single scanner often serves more than one category, and the same tool can report both a vulnerable dependency and a secret, so a finding's category says what the finding is and never which scanner found it.

Which categories a workspace is entitled to is decided per workspace. The GraphQL API returns yours through scanCategories, and the CLI through vulnara scan_categories. DAST appears there only once web application scanning is enabled for your workspace. A finding recorded before categories existed may have none. The web app shows it as uncategorised rather than guessing one from the scanner, and a category filter does not match it.

How it works

• A scan is one scanner against one repository on one branch, with its own result. Choosing a category starts one scan per scanner serving it, and keeping several categories starts more.
• Each commit is checked out and the scanners run over the files in it. The .git directory is kept out of the scan, so nothing ever sees your git history or credentials. Files matching your ignore paths are removed first.
• Vulnara locates each result in the file it came from, recording the line, column and line content.
• File paths are made consistent across scanners, so the same file reported twice is recognised as the same file.
• Every scanner's own vocabulary is mapped onto one scale:
  • Severity: Critical, High, Medium, Low, Info or Unknown.
  • Confidence: High, Medium or Low.
• Rules from different scanners that check the same thing are recognised as the same finding, so a secret that two scanners both report shows once. See Deduplication.
• Secret and personal-data findings are recorded for every commit scanned. Dependency findings are recorded for the last commit only, the head of the default branch.

How personal data is graded

• Credit card and social security numbers: Critical, lowered to High when confidence is low.
• Email addresses and IP addresses: Medium.

A severity the scale does not recognise is passed through as it was reported, rather than guessed.

What a dependency finding carries

Each dependency finding names the package, its ecosystem, the installed version, the version that fixes it where one exists, and the vulnerability identifier with its aliases.

What you can set

• What to scan for: in the scan form, keep or remove categories. Every category your workspace may run is selected by default, and each one you keep queues every scanner serving it. See Run a scan.
• Ignore paths: keep vendored code, generated files and test fixtures out of every scan. See Ignore paths.

Do it

1. Choose New Scan in the sidebar and pick a repository.
2. Under What to scan for, keep the categories you want. All the ones you may run are selected by default.
3. Choose Start scan.

From GraphQL, startRepositoryCategoryScan takes a category and queues every scanner serving it that your workspace may run, just like the form, and the CLI's start_repository_category_scan --category does the same. The older id path, startRepositoryScan with one scanner id, still works, and it is what the GitHub Action's scan-tools input and the CLI's start_repository_scan --dockerScanToolId send. See Run a scan.

Good to know

• A repository with no package manifest or lock file gives dependency analysis nothing to check, so it reports no SCA findings.
• If a scan fails on a commit, that commit is counted as failed and the rest of the scan carries on. A scan fails only when no commit could be scanned.
• A category that starts three scanners uses roughly three times the scan minutes of one that starts one. See Plans and billing.
• Invalid ignore patterns are skipped and the scan runs without removing anything.
• Secret values are masked in the product. See Triage findings.