OSV

OSV (Open Source Vulnerabilities) to dwie powiązane rzeczy: otwarty format opisu podatności w pakietach open source oraz zbudowana na nim baza OSV.dev. Serwis przedstawia się jako otwarte, precyzyjne i rozproszone podejście do tworzenia i wykorzystywania informacji o podatnościach w open source ^[1]. Specyfikacja formatu definiuje standardowy format wymiany opisów podatności w pakietach open source ^[2]. Najważniejszą cechą rekordu OSV jest dokładny zakres wersji albo commitów, którego dotyczy błąd, zapisany tak, aby dało się go sprawdzić maszynowo ^[1].

Jak działa

Rekord OSV to dokument JSON. Wymagane są w nim tylko identyfikator i data ostatniej modyfikacji, a od wersji schematu wyższych niż 1.0.0 także numer wersji schematu ^[2]. Identyfikator składa się z prefiksu bazy macierzystej i numeru nadanego przez tę bazę, na przykład „GHSA-vp9c-fpxx-744v” albo „CVE-2021-3114” ^[2]. Pole aliases wskazuje ten sam błąd w innych bazach, dzięki czemu wpis z bazy GitHub da się połączyć z numerem CVE ^[2].

Sercem rekordu jest pole affected. Wymienia pakiet w danym ekosystemie i zakresy wersji opisane zdarzeniami: introduced (od której wersji błąd występuje), fixed (w której go usunięto) i last_affected (ostatnia podatna wersja) ^[2]. Typ zakresu mówi, jak porównywać wersje: SEMVER dla wersjonowania semantycznego, ECOSYSTEM dla reguł danego menedżera pakietów i GIT dla zakresów commitów ^[2].

{
  "id": "GHSA-xxxx-xxxx-xxxx",
  "aliases": ["CVE-2026-0000"],
  "affected": [{
    "package": { "ecosystem": "Packagist", "name": "example/biblioteka" },
    "ranges": [{ "type": "ECOSYSTEM",
      "events": [{ "introduced": "0" }, { "fixed": "2.4.1" }] }]
  }]
}

Rekordy zmieniają się w czasie. Jeśli dwa wpisy mają ten sam identyfikator, rozstrzyga ten z późniejszą datą modyfikacji ^[2]. Wycofany rekord dostaje pole withdrawn z datą, a uzasadnienie trafia do podsumowania ^[2]. Skaner powinien więc pobierać dane na bieżąco, a nie z jednorazowej kopii.

Przykład jest opisowy: mówi, że wszystkie wersje biblioteki przed 2.4.1 są podatne. Skaner porównuje z takim zakresem wersję zapisaną w pliku blokady projektu.

RYS. 1Dopasowanie zależności do OSV

Skąd pochodzą dane

OSV.dev nie jest jedną bazą redagowaną centralnie. Agreguje rekordy z wielu źródeł, które publikują dane w formacie OSV, między innymi z GitHub Advisory Database, PyPI Advisory Database, Go Vulnerability Database, Rust Advisory Database i Drupal Advisory Database ^[3]. Zbiór jest też eksportowany w całości do publicznego zasobnika w Google Cloud Storage ^[3].

Google uzasadniał powstanie OSV tym, że schematy wersji w istniejących standardach, takich jak CPE, słabo pasują do wersjonowania w open source, czyli do tagów i skrótów commitów ^[4]. Skutkiem były przeoczone podatności u odbiorców pakietów ^[4].

W WordPressie

Specyfikacja OSV definiuje ekosystem WordPress z trzema przyrostkami: :Core dla rdzenia (nazwa pakietu to wordpress), :Plugin dla wtyczek i :Theme dla motywów ^[2]. Nazwą wtyczki lub motywu jest slug, czyli unikalny identyfikator z katalogu WordPress.org ^[2]. Na liście ekosystemów obsługiwanych przez OSV.dev WordPress jednak nie występuje, jest natomiast Packagist, czyli ekosystem pakietów PHP ^[3]. Format jest więc gotowy na rekordy o wtyczkach, ale zbiorcza baza ich na razie nie zbiera.

Dla stron WordPress OSV ma największe znaczenie tam, gdzie projekt korzysta z Composera. Skaner OSV-Scanner czyta plik composer.lock ^[5], a także pliki blokady narzędzi JavaScript, takie jak package-lock.json ^[5]. Pozwala to wychwycić podatne biblioteki dołączone do własnego motywu lub wtyczki, zanim trafią na serwer. Informacje o błędach w samych wtyczkach z katalogu WordPress.org trzeba nadal czerpać z baz branżowych i biuletynów bezpieczeństwa.

Zastosowanie

OWASP w wydaniu Top 10 z 2025 roku wymienia OSV obok CVE i NVD jako źródło, które należy stale monitorować pod kątem podatności w używanych komponentach ^[7]. Zaleca też centralne prowadzenie wykazu składników (SBOM) i śledzenie zależności pośrednich ^[7]. OSV dobrze pasuje do tego modelu, bo odpowiada na pytanie, czy konkretna wersja pakietu jest podatna.

Oficjalnym klientem bazy jest OSV-Scanner, dostępny jako narzędzie wiersza poleceń do terminala lub potoku CI/CD oraz jako biblioteka Go ^[8]. Autorzy wskazują zalety otwartej bazy: każde ostrzeżenie pochodzi z otwartego i miarodajnego źródła, każdy może zgłosić poprawkę, a format jednoznacznie zapisuje dotknięte wersje ^[8]. Efektem mają być mniej liczne i bardziej konkretne powiadomienia ^[8].

API OSV obsługuje zapytanie o pojedynczy pakiet lub commit, zapytanie zbiorcze i pobranie rekordu po identyfikatorze ^[6]. Dokumentacja podaje, że obecnie API nie ma limitów zapytań, a odpowiedź przez HTTP/1.1 jest ograniczona do 32 MiB ^[6]. Typowe zastosowania to:

• skanowanie podatności zależności w potoku CI przed wdrożeniem;
• skanowanie obrazów kontenerów z aplikacją;
• ocena, czy łatka (patch) w nowej wersji biblioteki usuwa znany błąd.

Trafienie w OSV nie przesądza o realnym zagrożeniu, bo podatna funkcja może nie być używana. Wynik jest wejściem do zarządzania podatnościami, a nie gotową decyzją. Wśród źródeł OSV.dev jest też baza OpenSSF Malicious Packages ^[3], więc wynik obejmuje znane złośliwe pakiety. Nie obejmuje natomiast nowego, jeszcze nieopisanego ataku na łańcuch dostaw.

Historia

Google ogłosił uruchomienie OSV 5 lutego 2021 roku jako pierwszy krok do lepszej oceny podatności w open source ^[4]. Celem było podanie dokładnych danych o tym, gdzie błąd wprowadzono i gdzie go naprawiono ^[4]. Pierwszy zbiór obejmował podatności wykryte przez fuzzing w usłudze OSS-Fuzz ^[4]. Aktualna wersja specyfikacji formatu, 1.9.0, pochodzi z 6 sierpnia 2026 roku ^[2].