Interpretowanie alertów z narzędzi skanera

  • 11 min

Narzędzia analizy kompozycji oprogramowania generują wiele alertów dotyczących luk w zabezpieczeniach, problemów z licencjami i kwestii dotyczących jakości kodu w zależnościach. Skuteczne interpretowanie tych alertów wymaga zrozumienia oceny ważności, oceny eksploatowalności, zarządzania fałszywymi alarmami i priorytetyzacji działań naprawczych na podstawie rzeczywistego ryzyka dla aplikacji. Bez właściwej interpretacji i priorytetyzacji zespoły napotykają zmęczenie alertami i marnują czas na problemy o niskim wpływie, gdy brakuje krytycznych luk w zabezpieczeniach.

Zrozumienie stopnia powagi luk w zabezpieczeniach

Oceny ważności luk w zabezpieczeniach zapewniają ustandaryzowane oceny ryzyka:

System oceniania CVSS

Typowy system oceny luk w zabezpieczeniach (CVSS) zapewnia ustandaryzowane wyniki liczbowe wskazujące ważność luki w zabezpieczeniach.

Kategorie metryk CVSS:

  • Podstawowe metryki: Wewnętrzne cechy luk w zabezpieczeniach niezależnie od konkretnych środowisk.
  • Metryki czasowe: Cechy luk w zabezpieczeniach, które zmieniają się w czasie (dostępność luk w zabezpieczeniach, dostępność poprawek, pewność).
  • Metryki środowiska: Cechy luk w zabezpieczeniach specyficzne dla konkretnych środowisk i wdrożeń.

Obliczanie wyniku podstawowego CVSS w wersji 3: Wyniki podstawowe łączą wiele metryk:

Metryki możliwości wykorzystania:

  • Wektor ataku (AV): Sieć (N), sąsiadujące (A), lokalne (L) lub fizyczne (P).
  • Złożoność ataku (AC): Niska (L) lub wysoka (H) trudność w wykorzystaniu luki w zabezpieczeniach.
  • Wymagane uprawnienia (PR): Brak (N), Niskie (L) lub Wysokie (H) uprawnienia potrzebne do eksploatacji.
  • Interakcja z użytkownikiem (UI): Brak (N) lub Wymagana (R) do pomyślnego wykorzystania.

Metryki wpływu:

  • Wpływ poufności (C): Brak (N), Niskie (L) lub Wysokie (H) ujawnienie informacji.
  • Wpływ integralności (I): Brak (N), niska (L) lub wysoka (H) możliwość modyfikowania danych.
  • Wpływ dostępności (A): Brak (N), Niska (L) lub Wysoka (H) przerwy w działaniu usługi.

Przykładowy wektor CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Stanowi to lukę w zabezpieczeniach umożliwiającą wykorzystanie sieci z niską złożonością ataku, brak wymaganych uprawnień, brak interakcji użytkownika i duży wpływ na poufność, integralność i dostępność.

Klasyfikacje ważności

Wyniki CVSS mapuje się na oceny ważności:

Severity Ocena CVSS Opis Priorytet
Krytyczne 9.0 - 10.0 Łatwe wykorzystanie luk w zabezpieczeniach powoduje powszechne naruszenie systemu. Wymagane jest natychmiastowe korygowanie.
High 7.0 - 8.9 Poważne luki w zabezpieczeniach umożliwiające ujawnienie ważnych informacji lub przerwy w działaniu usługi. Korygowanie wymagane w ciągu kilku dni.
Medium 4.0 - 6.9 Umiarkowane luki w zabezpieczeniach z ograniczoną możliwością wykorzystania lub wpływu. Korygowanie wymagane w ciągu kilku tygodni.
Low 0.1 - 3.9 Drobne luki w zabezpieczeniach z minimalnym wpływem na bezpieczeństwo. Korygowanie, gdy jest to wygodne.
Brak 0,0 Wyniki informacyjne bez rzeczywistego wpływu na zabezpieczenia. Opcjonalne korygowanie.

Przykłady interpretacji surowości:

Krytyczna luka w zabezpieczeniach (CVSS 10.0):

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

Wysoka luka w zabezpieczeniach (CVSS 8.1):

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

Średnia luka w zabezpieczeniach (CVSS 5.9):

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

Ocenianie możliwości wykorzystania

Wyniki CVSS nie opowiadają pełnej historii — ocena możliwości wykorzystania określa rzeczywiste ryzyko:

Dojrzałość exploita

Etapy dostępności exploitów:

Nieudowodnione:

  • Stan: Teoretyczna luka w zabezpieczeniach bez znanego exploita.
  • Poziom ryzyka: Mniejsze ryzyko — wykorzystanie wymaga znacznego nakładu pracy osoby atakującej.
  • Akcja: Monitorowanie tworzenia programów wykorzystujących luki w zabezpieczeniach; planowanie korygowania, ale nie pilne.

Weryfikacja koncepcji:

  • Stan: Kod atakujący typu proof-of-concept został opublikowany, ale nie został przekształcony w broń.
  • Poziom ryzyka: Umiarkowane ryzyko — zaawansowani cyberprzestępcy mogą wykorzystać tę lukę.
  • Akcja: Określanie priorytetów korygowania; opracowanie strategii ograniczania ryzyka.

Funkcjonalny:

  • Stan: Działający kod wykorzystujący luki w zabezpieczeniach jest publicznie dostępny.
  • Poziom ryzyka: Wysokie ryzyko — wykorzystanie dostępne dla średnio wykwalifikowanych napastników.
  • Akcja: Przyspiesz korygowanie; zaimplementuj tymczasowe środki zaradcze, jeśli stosowanie poprawek jest opóźnione.

Aktywne wykorzystywanie:

  • Stan: Luka w zabezpieczeniach aktywnie wykorzystywana na wolności.
  • Poziom ryzyka: Krytyczne ryzyko — wykorzystywanie dzieje się teraz.
  • Akcja: Korygowanie awaryjne; implementowanie natychmiastowych środków zaradczych; monitorowanie pod kątem naruszenia zabezpieczeń.

Przykładowa ocena wykorzystania:

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

Analiza powierzchni ataków

Ustal, czy luka w zabezpieczeniach jest osiągalna:

Czynniki osiągalności:

  • Użycie kodu: Czy ścieżka kodu podatna na zagrożenia jest rzeczywiście wykonywana przez aplikację?
  • Narażenie na sieć: Czy składnik narażony na zagrożenia jest narażony na dostęp do sieci?
  • Wymagania dotyczące uwierzytelniania: Czy wykorzystanie wymaga uwierzytelnioowanego dostępu?
  • Zależności konfiguracji: Czy luka w zabezpieczeniach wymaga wykorzystania określonych konfiguracji?

Przykład dostępności:

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

Kontekst środowiska

Rozważ konkretne środowisko:

Segmentacja sieci:

  • Dostępne z Internetu: Luki w zabezpieczeniach składników mających połączenie z Internetem mają najwyższy priorytet.
  • Sieć wewnętrzna: Luki w zabezpieczeniach tylko wewnętrzne mają niższy priorytet, jeśli sieć jest segmentowana.
  • Systemy izolowane: Systemy powietrznie odizolowane lub izolowane minimalizują ryzyko podatności sieciowych.

Czułość danych:

  • Dane poufne: Luki w zabezpieczeniach w systemach obsługujących poufne dane wymagają pilnego korygowania.
  • Informacje publiczne: Luki w zabezpieczeniach ujawniania informacji mają niższy priorytet, jeśli dane są już publiczne.
  • Środowiska testowe: Luki w zabezpieczeniach w środowiskach nieprodukcyjnych zwykle mają niższy priorytet.

Kontrolki wyrównywujące:

  • Zapora aplikacji internetowej: Reguły WAF mogą łagodzić próby wykorzystania.
  • Wykrywanie nieautoryzowanego dostępu: Usługa IDS/IPS może wykrywać i blokować próby wykorzystania.
  • Segmentacja sieci: Izolacja sieci ogranicza wpływ na wykorzystanie.
  • Zasada najmniejszego uprzywilejowania: Ograniczone uprawnienia zmniejszają wpływ eksploatacji.

Zarządzanie fałszywymi alarmami

Nie wszystkie zgłoszone luki w zabezpieczeniach rzeczywiście wpływają na aplikacje:

Typowe przyczyny fałszywie dodatnie

Źle zidentyfikowane składniki:

  • Konflikty nazewnictwa: Różne składniki o podobnych nazwach są niepoprawnie dopasowane.
  • Błędy wykrywania wersji: Nieprawidłowa identyfikacja wersji prowadząca do błędnego przypisania luk w zabezpieczeniach.
  • Nieporozumienie przestrzeni nazw pakietów: Pakiety w różnych ekosystemach niepoprawnie zidentyfikowane jako ten sam pakiet.

Przykład fałszywie dodatniego wyniku:

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

Nieużywane ścieżki kodu:

  • Nieaktywny kod: Zaimportowany kod podatny na zagrożenia, ale nigdy nie został wykonany.
  • Funkcje opcjonalne: Luki w zabezpieczeniach w funkcjach opcjonalnych, które aplikacja nie włącza.
  • Zależności programistyczne: Luki w zabezpieczeniach pakietów używane tylko podczas programowania, a nie w środowisku produkcyjnym.

Błędy zakresu wersji:

  • Raportowanie wersji stałych: Skanery zgłaszają lukę w zabezpieczeniach w wersjach, które zostały już poprawione.
  • Poprawki backportowe: Dostawcy backportują poprawki zabezpieczeń do starszych wersji bez zmieniania numerów wersji.
  • Poprawki niestandardowe: Luki w zabezpieczeniach zostały już poprawione za pomocą modyfikacji niestandardowych.

Weryfikacja fałszywie dodatnia

Proces badania:

  1. Weryfikowanie tożsamości składnika: Upewnij się, że skaner poprawnie zidentyfikował składnik.
  2. Sprawdź dokładność wersji: Sprawdź, czy wykryta wersja jest zgodna z rzeczywistą wdrożoną wersją.
  3. Przejrzyj szczegóły luk w zabezpieczeniach: Omówienie wpływu luki w zabezpieczeniach.
  4. Analizowanie użycia kodu: Ustal, czy ścieżki kodu podatnego na zagrożenia są rzeczywiście używane.
  5. Zapoznaj się z poradami dostawcy: Sprawdź, czy dostawca udostępnia dodatkowy kontekst.
  6. Wykorzystywanie testów: Spróbuj odtworzyć lukę w zabezpieczeniach w środowisku testowym.

Wymagania dotyczące dokumentacji: Podczas tłumienia wyników fałszywie dodatnich należy udokumentować:

  • Uzasadnienie: Dlaczego odkrycie jest wynikiem fałszywie dodatnim.
  • Szczegóły badania: Kroki podjęte w celu zweryfikowania wyników fałszywie dodatnich.
  • Osoba zatwierdzająca: Członek zespołu ds. bezpieczeństwa zatwierdzający tłumienie.
  • Data przeglądu: Data ponownej oceny tłumienia.

Przykładowy plik pomijania (OWASP Dependency-Check):

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

Struktury priorytetyzacji

Skuteczne zarządzanie lukami w zabezpieczeniach wymaga systematycznej priorytetyzacji:

Priorytetyzacja oparta na ryzyku

Czynniki priorytetyzacji:

Wynik powagi (25% waga):

  • Ocena bazowa CVSS stanowi podstawę do oceny ryzyka.
  • Wyższe wyniki wskazują na większy potencjalny wpływ.

Możliwość wykorzystania (waga 35%):

  • Stan aktywnej eksploatacji jest najbardziej krytycznym czynnikiem.
  • Dostępność publicznych luk w zabezpieczeniach znacznie zwiększa ryzyko.
  • Eksploity typu proof-of-concept wskazują na wykonalną eksploatację.

Krytyczność zasobów (20% waga):

  • Aplikacje dostępne z Internetu mają wyższy priorytet.
  • Systemy przetwarzające poufne dane wymagają pilnego stosowania poprawek.
  • Aplikacje krytyczne dla działania firmy nie mogą tolerować dłuższych przestojów.

Czynniki środowiskowe (20% waga):

  • Istniejące mechanizmy kontroli wyrównywujących zmniejszają skuteczne ryzyko.
  • Segmentacja sieci ogranicza zakres oddziaływania.
  • Funkcje monitorowania umożliwiają wykrywanie zagrożeń.

Macierz priorytetyzacji:

Możliwość wykorzystania Ważność krytyczna Wysoka ważność Średnia ważność Niska dotkliwość
Aktywne wykorzystywanie P0 (awaryjne) P0 (awaryjne) P1 (krytyczne) P2 (wysoki)
Wykorzystanie funkcjonalne P0 (awaryjne) P1 (krytyczne) P2 (wysoki) P3 (średni)
Weryfikacja koncepcji P1 (krytyczne) P2 (wysoki) P3 (średni) P4 (niski)
Niesprawdzony P2 (wysoki) P3 (średni) P4 (niski) P5 (opcjonalnie)

Usuwanie problemów w ramach umów SLA

Zdefiniuj umowy dotyczące poziomu usług na potrzeby korygowania:

Awaryjne (P0):

  • Przedział czasu: Natychmiastowe (w ciągu 24 godzin).
  • Kryteria: Krytyczne luki w zabezpieczeniach aktywnie eksploatowane w systemach wystawionych na działanie internetu.
  • Proces: Proces zmiany awaryjnej z powiadomieniem kierownictwa.
  • Przykład: Log4Shell (CVE-2021-44228) w aplikacji dostępnej publicznie.

Krytyczne (P1):

  • Przedział czasu: 7 dni.
  • Kryteria: Wysoka/krytyczna ważność z lukami funkcjonalnymi lub narażeniem na dostęp do Internetu.
  • Proces: Przyspieszony proces zmiany dzięki koordynacji zespołu ds. zabezpieczeń.
  • Przykład: Wstrzyknięcie kodu SQL w uwierzytelniony interfejs administratora.

Wysoki (P2):

  • Przedział czasu: 30 dni.
  • Kryteria: Średnia/wysoka ważność z wykorzystaniem luk w zabezpieczeniach weryfikacji koncepcji lub ekspozycji wewnętrznej.
  • Proces: Standardowy proces zmiany z zaplanowanym oknem obsługi.
  • Przykład: Skrypty między witrynami (XSS) na wewnętrznym pulpicie nawigacyjnym.

Średni (P3):

  • Przedział czasu: 90 dni.
  • Kryteria: Niska/średnia ważność bez znanych luk w zabezpieczeniach.
  • Proces: Regularny cykl aktualizacji z kwartalnymi poprawkami.
  • Przykład: Ujawnienie informacji w zależności narzędzia programistycznego.

Niski (P4):

  • Przedział czasu: Następne główne wydanie.
  • Kryteria: Niski poziom ważności lub fałszywe alarmy wymagające dokumentacji.
  • Proces: Uwzględnij to w regularnych działaniach konserwacyjnych.
  • Przykład: Odmowa usługi w nieużywanej funkcji opcjonalnej.

Ustanawianie pasków usterek zabezpieczeń

Progi błędów bezpieczeństwa definiują minimalne standardy zabezpieczeń, które muszą być spełnione:

Kryteria Zakończenia

Przykładowy pasek usterek zabezpieczeń:

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

Egzekwowanie zasad

Brama jakości usługi Azure Pipelines:

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

Przepływ pracy klasyfikacji luk w zabezpieczeniach

Systematyczne klasyfikacja zapewnia wydajne zarządzanie lukami w zabezpieczeniach:

Proces triage

Krok 1. Automatyczne filtrowanie:

  • Narzędzia skanera: Automatycznie filtruj luki w zabezpieczeniach według ważności.
  • Analiza dostępności: Usuń nieosiągalne luki w zabezpieczeniach z kolejki klasyfikacji.
  • Znane wyniki fałszywie dodatnie: Automatycznie pomijaj wcześniej zidentyfikowane fałszywie dodatnie wyniki.

Krok 2. Wstępna ocena:

  • Przegląd ważności: Sprawdź dokładność oceny CVSS dla danego środowiska.
  • Sprawdzanie możliwości wykorzystania: Określanie dostępności i aktywnego wykorzystywania luk w zabezpieczeniach.
  • Identyfikacja zasobu: Określanie aplikacji i systemów, których dotyczy problem.

Krok 3. Ocena ryzyka:

  • Wpływ na działalność biznesową: Ocena potencjalnego wpływu działalności biznesowej na skuteczne wykorzystanie.
  • Analiza ekspozycji: Określ narażenie sieci i powierzchnię ataków.
  • Kontrolki wyrównywujące: Zidentyfikuj istniejące środki zaradcze zmniejszające ryzyko.

Krok 4. Priorytetyzacja:

  • Przypisz priorytet: Użyj macierzy priorytetyzacji, aby przypisać priorytet korygowania.
  • Ustaw datę zakończenia: Ustal termin remediacji zgodnie z SLA.
  • Przypisz właściciela: Wskaż odpowiedzialny zespół do usunięcia problemów.

Krok 5. Śledzenie korygowania:

  • Tworzenie zgłoszeń: Generowanie elementów roboczych w systemie śledzenia (Jira, Azure Boards).
  • Monitorowanie postępu: Śledzenie postępu korygowania względem terminów ostatecznych.
  • Weryfikacja: Zweryfikuj pomyślną naprawę za pomocą ponownego skanowania.

Częstotliwość spotkań triage

Cotygodniowa klasyfikacja zabezpieczeń:

  • Uczestnicy: Zespół ds. zabezpieczeń, liderzy rozwoju, przedstawiciele ds. operacji.
  • Porządek dzienny: Przejrzyj nowe wyniki o wysokim/krytycznym znaczeniu, śledź postęp korygowania, dostosuj priorytety.
  • Czas trwania: 30–60 minut.

Comiesięczny przegląd luk w zabezpieczeniach:

  • Uczestników: Kierownictwo ds. zabezpieczeń, zarządzanie inżynierią, zespół ds. zgodności.
  • Porządek dzienny: Przejrzyj trendy, dostosuj zasady, oceń ogólny stan zabezpieczeń.
  • Czas trwania: 60–90 minut.

Metryki i raportowanie

Śledzenie skuteczności zarządzania lukami w zabezpieczeniach:

Kluczowe metryki

Metryki luk w zabezpieczeniach:

  • Średni czas wykrywania (MTTD): Czas od ujawnienia luk w zabezpieczeniach po wykrywanie w systemach.
  • Średni czas korygowania (MTTR): Czas od wykrycia do pomyślnego korygowania.
  • Gęstość luk w zabezpieczeniach: Liczba luk w zabezpieczeniach na aplikację lub wiersz kodu.
  • Szybkość korygowania: Procent luk w zabezpieczeniach skorygowanych w ramach umowy SLA.

Metryki trendu:

  • Liczba otwartych luk w zabezpieczeniach: Trendy liczby nierozwiązanych luk w zabezpieczeniach według ważności.
  • Nowe a rozwiązane: Porównanie nowo wykrytych i skorygowanych luk w zabezpieczeniach.
  • Zgodność z umową SLA: Procent luk w zabezpieczeniach skorygowanych w ramach zdefiniowanych umów SLA.
  • Współczynnik wyników fałszywie dodatnich: Procent wyników określonych jako fałszywie dodatnie.

Przykład pulpitu nawigacyjnego

Pulpit nawigacyjny zarządzania lukami w zabezpieczeniach:

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

Uwaga / Notatka

Aby uzyskać więcej informacji na temat umów dotyczących poziomu usług (SLA) i osi czasu korygowania, zobacz Umowy dotyczące poziomu usług platformy Azure.

Efektywna interpretacja alertów dotyczących luk w zabezpieczeniach i priorytetyzacja przekształca przytłaczające dane wyjściowe skanera w możliwe do działania ulepszenia zabezpieczeń. Dzięki zrozumieniu ocen ważności, ocenie możliwości wykorzystania, zarządzaniu fałszywymi alarmami i wdrożeniu systematycznej priorytetyzacji, zespoły koncentrują wysiłki korygujące na lukach w zabezpieczeniach, które stwarzają rzeczywiste ryzyko, zamiast gonić każdy alarm. Takie podejście oparte na ryzyku umożliwia tworzenie trwałych programów zabezpieczeń, które chronią aplikacje bez przeciążania zespołów programistycznych zbędnym hałasem.