Informacje o lukach w zabezpieczeniach
Klient NuGet, począwszy od wersji 6.7, może pobrać znane informacje o lukach w zabezpieczeniach pakietu do użycia w scenariuszach, takich jak sprawdzanie pakietów podczas operacji przywracania. Chociaż zasób metadanych pakietu zawiera również znane informacje o lukach w zabezpieczeniach, jeśli aplikacja musi sprawdzić dużą liczbę pakietów pod kątem znanych luk w zabezpieczeniach, znacznie szybciej jest pobierać plik znanych luk w zabezpieczeniach i wyszukiwać lokalnie, zamiast wykonywać dużą liczbę żądań HTTP. Umożliwia to na przykład przywracanie NuGet w celu szybkiego sprawdzania przywróconych pakietów pod kątem znanych luk w zabezpieczeniach, które historycznie nigdy nie pobrały szczegółów pakietu z zasobu metadanych pakietu.
Interfejs API składa się z co najmniej dwóch plików, indeksu luk w zabezpieczeniach i co najmniej jednego pliku strony luk w zabezpieczeniach. Znane dane luk w zabezpieczeniach można podzielić na wiele plików, a indeks luk w zabezpieczeniach dostarcza klientom informacje potrzebne do buforowania plików i wydajnie aktualizować pamięć podręczną.
Zasób używany do tworzenia tego adresu URL jest zasobem VulnerabilityInfo
znajdującym się w indeksie usługi.
Sugerowana strategia partycjonowania
Strony wymienione w indeksie luk w zabezpieczeniach powinny być zoptymalizowane pod kątem zmaksymalizowania buforowania, a tym samym zminimalizować aktualizacje dużych plików. Pozwoli to klientom zminimalizować częstotliwość pobierania aktualizacji.
Sugerowaną strategią partycjonowania danych luk w zabezpieczeniach jest posiadanie dwóch stron i base.json
updates.json
.
Plik base.json
jest okresowo aktualizowany (na przykład raz w miesiącu) i zawiera wszystkie znane luki w zabezpieczeniach w momencie ponownego wygenerowania pliku.
Plik updates.json
powinien zawierać wszelkie nowe biuletyny opublikowane od base.json
czasu ostatniego ponownego wygenerowania.
Dzięki temu klienci będą mogli pobierać duże base.json
pliki rzadko, podczas gdy często zmieniany updates.json
plik jest zawsze stosunkowo mały.
Klienci NuGet łączą dane z wielu plików i mogą ładować pliki w dowolnej kolejności.
Schemat pliku danych nie zezwala na modyfikowanie ani redaction znanych luk w zabezpieczeniach z innego pliku.
W związku z tym, jeśli źródło danych luk w zabezpieczeniach serwera (na przykład baza danych usługi GitHub Advisories) modyfikuje istniejący poradnik, serwer NuGet musi zmodyfikować stronę, na którą wcześniej zgłoszono informacje o lukach w zabezpieczeniach.
Jednym ze sposobów osiągnięcia tego za pomocą sugerowanego schematu partycji jest traktowanie wszystkich modyfikacji i usuwania luk w zabezpieczeniach jako wyzwalacza w celu ponownego wygenerowania kompletnego base.json
pliku i pustego updates.json
.
Wersje
Używane są następujące @type
wartości:
@type Wartość | Uwagi |
---|---|
VulnerabilityInfo/6.7.0 | Wersja początkowa |
Indeks luk w zabezpieczeniach
Indeks luk w zabezpieczeniach to tablica obiektów JSON z następującymi właściwościami:
Nazwisko | Type | Wymagania | Uwagi |
---|---|---|---|
@name | string | tak | Krótka nazwa pliku używana jako klucz pamięci podręcznej. |
@id | string | tak | Pełny (bezwzględny) adres URL pliku danych luk w zabezpieczeniach. |
@updated | string | tak | Ciąg ISO 8601 reprezentujący datę i godzinę ostatniej aktualizacji pliku, najlepiej ze strefą czasową UTC. |
comment | string | nie | Opcjonalny ciąg opisowy. |
Obowiązują następujące ograniczenia:
- Indeks musi być tablicą obiektów z zakresu od 1 do 16 elementów.
Jeśli serwer nie ma żadnych danych luk w zabezpieczeniach (zero stron), należy usunąć
VulnerabilityInfo
zasób z .ServiceIndex
@name
musi być unikatowy w indeksie, musi mieć długość od 1 do 32 znaków i może używać tylko znakówA
do , do ,a
doz
9
,0
-
lub_
.Z
@id
musi być bezwzględnym adresem URL, a nie względnym adresem URL.
Strona luk w zabezpieczeniach
Pliki stron luk w zabezpieczeniach to obiekt JSON używany jako słownik. Klucze właściwości są małymi literami identyfikator pakietu, a wartości właściwości są tablicą następującego obiektu o następujących właściwościach:
Nazwisko | Type | Wymagania | Uwagi |
---|---|---|---|
ważność | integer | tak | 0 oznacza niski, 1 oznacza średni, 2 oznacza wysoki, 3 oznacza krytyczne. |
Adres URL | string | tak | Adres URL, w którym użytkownicy mogą uzyskać więcej informacji na temat luki w zabezpieczeniach. |
versions | string | tak | Zakres wersji, który jest podatny na zagrożenia, przy użyciu składni zakresu wersji NuGet. |
Identyfikatory pakietów (klucze obiektu głównego) muszą być małymi literami String.ToLowerInvariant
.
Lista znanych luk w zabezpieczeniach pakietu powinna być posortowana w kolejności malejącej maksymalnej wersji zakresu wersji, a następnie malejącej wersji minimalnej wersji, a następnie kolejności rosnącej adresu URL. Zakresy z minimalną lub maksymalną wersją o wartości null (bez ruchu) w zakresie wersji powinny być sortowane do wersji innych niż null (ograniczone).
Pusta strona, która nie zapewnia żadnych znanych luk w zabezpieczeniach, musi być pustą tablicą JSON ([]
).
Przykłady
Oto przykład indeksu luk w zabezpieczeniach:
[
{
"@name": "base",
"@id": "https://nuget.contoso.com/v3/vulnerabilities/3bb6b300-2f74-45bc-af06-746fd21c024b.json",
"@updated": "2023-06-01T06:14:58.4159909Z",
"comment": "The base data for vulnerability update periodically"
},
{
"@name": "update",
"@id": "https://nuget.contoso.com/v3/vulnerabilities/ffd572cd-33f3-4372-8714-a9cab2e86b45.json",
"@updated": "2023-06-14T11:35:30.3155764Z",
"comment": "The patch data for the vulnerability. Contains all the vulnerabilities since base was last updated."
}
]
Oto przykład pliku danych luk w zabezpieczeniach:
{
"contoso.library": [
{
"url": "https://cve.contoso.com/advisories/1",
"severity": 1,
"versions": "(, 2.0.0)"
},
{
"url": "https://cve.contoso.com/advisories/2",
"severity": 2,
"versions": "(1.0.0, 2.0.0)"
}
],
"contoso.utilities": [
{
"url": "https://cve.contoso.com/advisories/3",
"severity": 3,
"versions": "(, 1.0.0)"
}
]
}