osv-scanner panics on empty license field (index out of range) when --licenses is enabled

[sl4x0]

Summary

osv-scanner scan --licenses <allowlist> crashes with an unrecoverable panic (index out of range) when scanning packages whose license field is empty. An empty license string reaches spdx.Satisfies("", allowlist), the tokenizer produces an empty token list, and tokens.next() dereferences ts.tokens[0] without a bounds check.

This is reachable from valid parser output, not malformed input: the APK extractor emits Licenses: []string{record["L"]} and, when an Alpine package record omits the L: field, that yields []string{""}. The license enricher preserves it and it flows into the SPDX evaluator. With no recover() anywhere in the scan path, the panic aborts the whole scan.

Affected code

internal/spdx/satisfies.go:72-77:

// next returns the next token in the list of tokens, removing it from the list in the process
func (ts *tokens) next() string {
	token := ts.tokens[0]
	ts.tokens = ts.tokens[1:]

	return token
}

No bounds check exists before ts.tokens[0], unlike peek() (:63-69) which does guard with len(ts.tokens) == 0.

Call chain: Satisfies("", ...) -> parse (:157) -> parseOr -> parseAnd -> parseExpression (:216) -> nextAndIsNextNextValid (:92) -> next (:73) -> panic.

Reproduction

At HEAD d87a911 (go 1.26+):

go test ./internal/spdx -run TestPocSatisfiesEmptyLicense -v

Observed output (poc_satisfies_test.go calling spdx.Satisfies("", []string{"MIT"})):

panic: runtime error: index out of range [0] with length 0
github.com/google/osv-scanner/v2/internal/spdx.(*tokens).next(...)
        C:/.../internal/spdx/satisfies.go:73

End-to-end: scan an Alpine repository/container image containing a package whose lib/apk/db/installed record omits the L: field with osv-scanner scan --licenses MIT <target>. The empty license reaches spdx.Satisfies("") and the process terminates.

Impact

• Complete denial of the scan whenever --licenses is enabled and any scanned package lacks a license field.
• CI pipelines fail consistently until the package or flag is removed.
• Remaining packages in the scan are never evaluated.

Root cause / suggested fix

• tokenise can legitimately produce zero tokens (empty input). next() must not index ts.tokens[0] unconditionally - return an error (or EOF token) when the stream is exhausted.
• Skip empty license strings before evaluating (e.g. treat "" as no license / not satisfied rather than crashing).
• Add regression tests for empty license expressions.
• Consider a top-level recover() around scan execution so one malformed package record cannot terminate the whole process.

[G-Rath]

do you have a real world reproduction for this?

[sl4x0]

Yes — full real-world repro at HEAD d87a911, proving both halves of the chain:

1) The scanner emits an empty license for a real Alpine package that omits L:

The scalibr APK extractor builds Licenses as []string{record["L"]} (osv-scalibr extractor/filesystem/os/apk/apk.go). When an installed DB entry has no L: field, record["L"] is "", so the package ships out with Licenses == []string{""} — untouched by the name/version checks.

Regression test against the real extractor (in internal/scalibrplugin, passes at HEAD):

// installed DB: musl has "L:MIT", no-license-pkg omits L: entirely
inv, _ := apk.Extractor.Extract(ctx, &filesystem.ScanInput{FS: DirFS(root), Path: "lib/apk/db/installed", ...})
// -> packages:
//   musl/1.2.4-r2      licenses=["MIT"]
//   no-license-pkg/1.0.0-r0  licenses=[""]

go test ./internal/scalibrplugin -run TestApkExtractorEmitsEmptyLicense -v → PASS.

2) That empty license reaches spdx.Satisfies("") and panics

pkg/osvscanner/vulnerability_result.go (the --licenses path) loops pkg.Licenses and calls spdx.Satisfies(license, allowlist) for each — so the "" above hits Satisfies("", ["MIT"]), and next() indexes ts.tokens[0] with no bounds check (unlike peek()):

panic: runtime error: index out of range [0] with length 0
github.com/google/osv-scanner/v2/internal/spdx.(*tokens).next(...)
        internal/spdx/satisfies.go:73

Verifiable with go test ./internal/spdx -run TestPocSatisfiesEmptyLicense -v (I added a poc test; it panics as expected at HEAD).

End-to-end CLI trigger: a real Alpine rootfs/container image that contains a package whose lib/apk/db/installed entry omits the L: field, scanned with osv-scanner scan --licenses MIT <rootfs> aborts the whole run with that panic. This is not a hand-crafted malformed input — it's the valid record["L"] default behaviour for packages without a license field, which is common in custom / non-annotated packages.

Fix suggestion (unchanged from the issue): guard next() when len(ts.tokens) == 0 (return an error/EOF instead of indexing), and/or skip empty license strings before evaluating. Happy to open a PR with both tests + the fix.

[Boulea7]

I would like to work on this. My proposed approach is to make an exhausted token stream return a parse error from nextAndIsNextNextValid instead of reaching tokens.next(), then add regression cases for empty and whitespace-only SPDX expressions. I would also add a focused scanner-result test with an empty package license to verify the scan continues and records the invalid license rather than panicking.

I would keep the change local to the SPDX/parser and license-result paths; a process-wide recover() should not be necessary. If this direction is acceptable, please assign the issue to me and I will prepare the PR.