How do I connect OSV to Lodol?

Authenticate OSV once from your workspace and every action and trigger it supports becomes available to drop into a workflow. There is no glue code to write or maintain.

All integrations

OSV

Compliance & SecurityCode Repositories

Find out whether the software you depend on has known security vulnerabilities, using OSV, the open vulnerability database run by Google's Open Source Security Team. One query reaches every source at once: GitHub advisories, the CVE catalogue, PyPI, Go, Rust and npm's own feeds, and the security trackers of Debian, Ubuntu, Alpine, Red Hat, SUSE, Android and the Linux kernel.

Check a single package, a Package URL from a bill of materials, a source repository at a tag, or a Git commit for code with no release at all; audit a whole lockfile or SBOM in one step; and read any advisory in full by its CVE or GHSA number. Setup is a single click: the API is keyless, so there is no account, no API key and no rate limit to manage.

Every answer says how bad the worst finding is and which release fixes it, in plain CRITICAL/HIGH/MEDIUM/LOW terms with a CVSS score beside it, so a scheduled workflow can raise a ticket or post to a channel the day something lands. Every vulnerability carries a link straight to its page on osv.dev.

Get Started Browse all integrations

8 actions

Actions

Steps your workflow can run in OSV.

Check a packageCheck one package against every vulnerability OSV knows about, and get back how bad the worst one is and which release fixes each. Covers every ecosystem OSV tracks, from npm and PyPI to Debian and Alpine. Leave the version empty to see everything ever recorded against the package. A name OSV does not recognise comes back with nothing found rather than an error, so the spelling has to match the registry.

Check a Package URLCheck one Package URL (purl), the identifier a CycloneDX or SPDX bill of materials writes every component as. The way in for a workflow that starts from a generated SBOM rather than a name someone typed.

Check a source repositoryCheck a release of a project that has no package registry entry, by its repository and tag. This is how C and C++ libraries, firmware and anything else vendored straight from source get checked.

Check a commitCheck one Git commit, for code pinned to a hash rather than a release: a submodule, a vendored tree, or a build that records the commit it shipped. The question no version number can answer.

Check many packagesAudit a whole lockfile in one step: hand it up to 100 'name@version' entries and get back which ones are affected, how bad the worst finding is and what to upgrade each to.

Check many Package URLsAudit a whole bill of materials in one step: hand it up to 100 Package URLs, straight out of a CycloneDX or SPDX file, and get back which components are affected and what to upgrade each to. The purls may mix ecosystems freely.

Get vulnerability detailsRead one vulnerability in full: what it is and how it works, its CVSS score and vector, its CWE classes, every package and version range it covers, the commits that fixed it, and every advisory, patch and discussion linked to it. Takes a CVE number as readily as a GHSA.

Get details for many vulnerabilitiesRead up to 50 vulnerabilities in full at once, worst first. Made to be fed the ids an audit step turned up, so a report can quote each finding's description, references and fix without a step per identifier.