Most of Ci systems can handle reports in JUnit format.
I believe it is a good feature to visualize OSV scan reports by CI system.

I've created a CycloneDX SBOM JSON file using syft in the file system detection mode.
I then passed it to osv-scanner 1.0.1 and got the following error message:

# osv-scanner --sbom sbom.cyclonedx.json                                                                                                                                                            
Scanned CycloneDX SBOM                                                                                                                                                                                      
scan failed server response error: {"code":3,"message":"Invalid Package URL."}    

Can you please make this error more detailed so it's clearer which Package URL is invalid?

(I think I know what the reason is; syft created 59 sections looking like this:

       "externalReferences": [
         {
           "url": "",
           "hashes": [
             {
               "alg": "SHA-1",
               "content": "SOMESHA1"
             }
           ],
           "type": "build-meta"
            }                                                                                                                                                                                                 
       ],

and one like this:

       "bom-ref": "77d4884a4c0c2f96",
       "type": "library",
       "name": "",
       "cpe": "cpe:2.3:a:python-:python-:*:*:*:*:*:*:*:*",
       "purl": "pkg:pypi/",
       "properties": [
...

when I deleted these, osv-scanner didn't report this error any longer.)
(I'll file a bug report for syft next.)

Hi,
I've tried to use the repo and saw that the parser can't be located on my windows computer.
after a short debug I saw it fails on this function:

func FindParser(pathToLockfile string, parseAs string) (PackageDetailsParser, string) {
	if parseAs == "" {
		parseAs = path.Base(pathToLockfile)
	}

	return parsers[parseAs], parseAs
}

When it sees the directory it don't extract the base and therefore don't find the name of the file (and the parser type).

I suggest changing it to filepath.Base(pathToLockfile) in order to support both.

Does osv-scanner support vulnerability scan of OSS source code?
By reading the documentation and testing, I think it is not supported, but I would like to do a double confirm, thanks !

Currently the scanner works by using the OSV.dev API, which ensures the matching against latest live DB with little (targeted <15 minute latency from the upstream source)

We should support a local mode, which supports taking in a local OSV DB.

One of the key prerequisites here is:

• Implementing version comparison rules for all our supported ecosystems. This is necessary for precise vulnerability matching based on the OSV version matching algorithm (@G-Rath has something for this that does this for the many of our ecosystems)

This will have some limitations:

• Commit based matching will not work -- the API indexes all commit hashes ingested, and it's not feasible to replicate this index locally.
• Potential performance issues?

Hello,

After installing the osv-scanner using "Install from Source", getting a osv-scanner not found error message.
Didn't find enough information in articles/blogs related to this issue

../go/github.com/spdx/[email protected]/rdfloader/xmlreader/xmlreader.go:213:27: WHITESPACE (untyped int constant 4294977024) overflows int
>>> ERROR: osv-scanner: build failed

i'm trying to add osv-scanner to aports for alpinelinux.

the pipelines are mostly fine except for armhf, armv7 and x86 with the above error

any idea why?

https://gitlab.alpinelinux.org/tuananh/aports/-/pipelines/147834

I don't know, where i may report about this. Report here.
yarn.lock.txt

For example, Kubernetes go.mod has these lines:

require k8s.io/client-go v0.0.0
...
k8s.io/client-go => ./staging/src/k8s.io/client-go

and osv-scanner will incorrectly show all vulnerabilities for client-go that have introduced 0.

The osv-scanner should be able to scan .jar files.

I'm not very familiar with this, but we could potentially match .jar files by hash against the Maven registry to get the package + version.

I think .jar files can also embed other .jar files inside as well.

I had a CI script that just broke because logs are not sent to stdout when they were not before, I think a change in #3

osv-scanner -r . | tee /tmp/vulns
2022/11/23 18:56:22 Scanning dir .
2022/11/23 18:56:22 Scanning /app/ at commit f187e875250ec11be568d5f00974ebcddba51aa3
2022/11/23 18:56:22 Scanned /app/go.mod file and found 37 packages
! [ -s /tmp/vulns ]

This used to exit 0, now it exits 1 because those log lines actually get piped to /tmp/vulns so the file is not empty.

How should osv-scanner be properly used in CI?

Thanks!

When using the default textual output and the SOURCE path is long enough, the output is truncated.

All lines end with a ≈ and are truncated which make the output unusable because it misses the OSV URL entirely.

╭────────────────────────────────────────────────────┬───────────┬─────────────────────────┬───────────────────────────────────┬───────────────────────────── ≈
│ SOURCE                                             │ ECOSYSTEM │ AFFECTED PACKAGE        │ VERSION                           │ OSV URL (ID IN BOLD)         ≈
├────────────────────────────────────────────────────┼───────────┼─────────────────────────┼───────────────────────────────────┼───────────────────────────── ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│

I know about the JSON output, but I'd like to have an untruncated textual output too because it is more readable.

Improve JSON output so that it encodes alias information so that the number of vulnerabilities are not artificially increased by the number of different advisories publishing the same vulnerability.

https://pkg.go.dev/golang.org/x/vuln/vulncheck does static analysis to check callgraphs etc. Perhaps we can re-use this in our osv-scanner.

Currently Pipfile.lock is not a support lock file, please add support.

The project has a high chance of gaining a lot of adoption.
To help with adoption, the project could provide other ways to install besides go install or download binaries. This facilitates to use of the osv-scanner in different machines, servers, CI/CD, etc.

My proposal is that the project could have the following:

• docker image
• brew package
• arch linux package
• alpine linux
• debian based (.deb)
• red hat based (.rpm)
• snap
• scoop

All this can be done using the goreleaser.
I can help with PRs if these features make sense!

If markdown was supported as an output format, you could just pipe the output to $GITHUB_STEP_SUMMARY

There is no strict requirement on requirements.txt as the filename for requirements files. We should be able to detect more cases like these.

Improve action.yml to fail the action if there are vulnerabilities.

Also determine additional requirements for a standalone Github action.

$ go install github.com/google/osv-scanner/cmd/osv-scanner@v1

go: downloading github.com/google/osv-scanner v1.0.1
go: downloading github.com/jedib0t/go-pretty/v6 v6.4.3
go: downloading github.com/package-url/packageurl-go v0.1.0
go: downloading github.com/urfave/cli/v2 v2.23.7
go: downloading github.com/CycloneDX/cyclonedx-go v0.7.0
go: downloading golang.org/x/term v0.3.0
go: downloading github.com/spdx/tools-golang v0.3.0
go: downloading golang.org/x/exp v0.0.0-20221212164502-fae10dda9338
go: downloading golang.org/x/sys v0.3.0
go: downloading github.com/mattn/go-runewidth v0.0.13
go: downloading github.com/spdx/gordf v0.0.0-20201111095634-7098f93598fb
go: downloading github.com/cpuguy83/go-md2man/v2 v2.0.2
go: downloading github.com/xrash/smetrics v0.0.0-20201216005158-039620a65673
go: downloading github.com/russross/blackfriday/v2 v2.1.0
# internal/unsafeheader
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/itoa
compile: version "go1.19" does not match go tool version "go1.19.2"
# unicode/utf8
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/goarch
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/goos
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/race
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/goexperiment
compile: version "go1.19" does not match go tool version "go1.19.2"
# math/bits
compile: version "go1.19" does not match go tool version "go1.19.2"
# encoding
compile: version "go1.19" does not match go tool version "go1.19.2"
# unicode/utf16
compile: version "go1.19" does not match go tool version "go1.19.2"
# container/list
compile: version "go1.19" does not match go tool version "go1.19.2"
# crypto/internal/subtle
compile: version "go1.19" does not match go tool version "go1.19.2"
# unicode
compile: version "go1.19" does not match go tool version "go1.19.2"
# crypto/subtle
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/nettrace
compile: version "go1.19" does not match go tool version "go1.19.2"
# vendor/golang.org/x/crypto/cryptobyte/asn1
compile: version "go1.19" does not match go tool version "go1.19.2"
# vendor/golang.org/x/crypto/internal/subtle
compile: version "go1.19" does not match go tool version "go1.19.2"
# golang.org/x/exp/maps
compile: version "go1.19" does not match go tool version "go1.19.2"
# sync/atomic
compile: version "go1.19" does not match go tool version "go1.19.2"
# golang.org/x/exp/constraints
compile: version "go1.19" does not match go tool version "go1.19.2"
# internal/cpu
compile: version "go1.19" does not match go tool version "go1.19.2"
# github.com/spdx/tools-golang/spdx
compile: version "go1.19" does not match go tool version "go1.19.2"
# crypto/internal/boring/sig
compile: version "go1.19" does not match go tool version "go1.19.2"

It would be great if there were some severity levels so we could prioritize the fixes.
for example critical high medium low

Connect osv-scanner with

1. google/osv.dev#561
2. google/osv.dev#783

To provide C/C++ dependency detection and vuln management.

I think we're long overdue on a CONTRIBUTING.md file :)

We can likely move a lot of things from the main README.md there too.

sharing because it may warrant a mention in the readme or other response

despite increasing ulimit repeatedly there keeps a 'too many open files' happening when scanning the /home folder

ulimit was 1024
ulimit is now 4096

once 'ulimit -n' is over 3072 there are no immediate messages on 'too many open files'

Unfortunately, CVSS information is missing. This information could be very helpful in vulnerability management process.

Currently the focus of OSV-Scanner is on lockfiles, with preliminary support for Debian container scanning.

We will extend this to better container scanning as well:

• Better package extraction from container images .
• Filesystem scanning.
• More distro support.

Hi,

right now osv-scanner_1.0.2_windows_amd64.exe is flagged by the Google AV engine in Virustotal:
https://www.virustotal.com/gui/file/ac9c77d9a5e91e8050b2aa5af9e13c5547775ae969d51ae957e08a8dc3804764

Codesigning of the binaries wouldn't hurt.

greetings
Carsten

Is there a way we can find if a dependency is transitive or not?

Automatically generate VEX statements based on call graph analysis or ignored vulnerabilities set in the scanner config.

Meta-issue to track the feature of doing callgraph analysis as part of vulnerability scanning to help reduce false positives (or at least help prioritize vulnerabilities). Vulnerability databases are starting to include metadata about which functions need to be called to actually be considered vulnerable (GHSA, Go at the very least).

Related idea from @jonathanmetzman: We can even go further with this analysis: We can completely disable the vulnerable code path to completely remove any possibly of the vulnerability being reached.

Current open issues:

• Go: #10

Automatically suggest the minimal package upgrades required to remediate all vulns.

Feature request to add support for scanning dependencies from bazel definitions. This is similar to dependabot/dependabot-core#2196. It'd make it a lot easier rather than bazel-generating POMs for osv-scanner to scan.

Currently requirements.txt parsing does not resolve the full dependency graph.

One option here may be to integrate pip-audit into this tool (though that introduces an external dependency from a different ecosystem)

Currently the releases do not include artifacts for use on ARM-based darwin systems.

I have generated a valid spdx file from VCPKG, then I try to use it with osv-scanner, but it generates no package sources found.
Can you please help me with this issue?
vcpkg.spdx.zip

In case this information is available, it will be great to add exploitability information, for example:

• Not Defined
• Proof of Concept
• Unproven
• In the wild
  etc
  This information could be very helpful in vulnerability management process

$ osv-scanner --lockfile /lib/apk/db/installed 
could not determine parser for /lib/apk/db/installed

It seems osv.dev has alpine data available so it seems like a good match. :)

Hello,

Can you support pre-commit-hook - just add .pre-commit-hook.yaml to repo and, if possible, use git tags for versioning.

Thanks

For running osv-scanner

Currently pom.xml support does not support resolving the full dependency graph.

Report on nuget package usage that has a vulnerability.

• packages.config
• packagereference nodes in
  • *.*proj
  • *.props files

https://devblogs.microsoft.com/nuget/how-to-scan-nuget-packages-for-security-vulnerabilities/

Currently, if you wish to generate the JSON report, the CLI report will be disabled, and there is no way to re-enable it without disabling the JSON report.

The CLI report can be useful for debugging any issues with the JSON report not being properly ingested by the CI/CD server.

It would be great to have the possibility to specify which report you wish to have enabled.

We should integrate https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/go/README.md in to the release process.

To allow vulnerabilities to be ignored.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• fix(deps): update osv-scanner minor (golang.org/x/exp, google.golang.org/protobuf)
• chore(deps): lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update golang docker tag to v1.22
• chore(deps): update workflows (major) (golangci/golangci-lint-action, slsa-framework/slsa-github-generator)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

It would be helpful to read the lockfile from STDIN. For the Python use case, that would enable something like this:

python -m pip freeze -r requirements.txt | osv-scanner -L -

By allowing pip to identify the transitive dependencies, I get a more complete scan.

I would expect that this enhancement would be stuck behind #94, as STDIN removes the naming hints for the lockfile type.

I've found three situations in which the following message is provided when running osv-scanner --docker someimage:

Scanned docker image with 0 packages
No package sources found, --help for usage information.

These situations are:

• the image name is incorrect
• the image is in a private registry that requires authentication
• the Docker client is installed, but the Docker daemon is not running

I would have expected an unambiguous error message to help with troubleshooting.