Fortolkning af beskeder fra scannerværktøjer

  • 11 minutter

Værktøjer til analyse af softwaresammensætning genererer adskillige advarsler om sårbarheder, licensproblemer og problemer med kodekvalitet i afhængigheder. Effektiv fortolkning af disse beskeder kræver forståelse af alvorsgradsscorer, vurdering af udnyttelsesmuligheder, administration af falske positiver og prioritering af afhjælpningsindsatser baseret på den faktiske risiko for dine programmer. Uden ordentlig fortolkning og prioritering står teams over for alarmtræthed og spilder tid på problemer med lav indvirkning, mens de går glip af kritiske sårbarheder.

Forstå sværhedsgraden af sårbarhed

Sværhedsgrader for sårbarheder giver standardiserede risikovurderinger:

CVSS-scoringssystem

Common Vulnerability Scoring System (CVSS) giver standardiserede numeriske scorer, der angiver sværhedsgraden af sårbarheden.

CVSS-metrikker kategorier:

  • Grundlæggende målinger: Iboende sårbarhedskarakteristika uafhængigt af specifikke miljøer.
  • Tidsmæssige målinger: Sårbarhedskarakteristika, der ændrer sig over tid (udnyttelsestilgængelighed, tilgængelighed af programrettelser, tillid).
  • Miljømæssige målinger: Sårbarhedskarakteristika, der er specifikke for bestemte miljøer og installationer.

Beregning af CVSS v3 basisscore: Basisresultater kombinerer flere målinger:

Målinger af udnyttelse:

  • Angrebsvektor (AV): Netværk (N), tilstødende (A), Lokalt (L) eller Fysisk (P).
  • Angrebskompleksitet (AC): Lav (L) eller Høj (H) sværhedsgrad ved at udnytte sårbarheden.
  • Påkrævede rettigheder (PR): Ingen (N), Lav (L) eller Høj (H) rettigheder kræves for at udnytte.
  • Brugerinteraktion (UI): Ingen (N) eller påkrævet (R) for vellykket udnyttelse.

Målinger af effekt:

  • Indvirkning på fortrolighed (C): Offentliggørelse af oplysninger om ingen (N), lav (L) eller høj (H).
  • Integritetspåvirkning (I): Ingen (N), lav (L) eller høj (H) dataændringsfunktion.
  • Påvirkning af tilgængelighed (A): Ingen (N), Lav (L) eller Høj (H) tjenesteafbrydelse.

Eksempel på CVSS-vektor:

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

Dette repræsenterer en sårbarhed, der kan udnyttes på netværket, med lav angrebskompleksitet, ingen privilegier påkrævet, ingen brugerinteraktion og stor indvirkning på fortrolighed, integritet og tilgængelighed.

Klassifikationer af alvorsgrad

CVSS-score kortlægges til sværhedsgrader:

Alvorlighed CVSS-score Betegnelse Prioritet
Alvorlig 9.0 - 10.0 Sårbarheder, der let kan udnyttes, og som forårsager omfattende systemkompromittering. Øjeblikkelig afhjælpning kræves.
Høj 7.0 - 8.9 Alvorlige sårbarheder, der muliggør væsentlig afsløring af oplysninger eller tjenesteafbrydelse. Afhjælpning kræves inden for få dage.
Middel 4.0 - 6.9 Moderer sårbarheder med begrænset udnyttelse eller indvirkning. Afhjælpning kræves inden for få uger.
Lav 0.1 - 3.9 Mindre sårbarheder med minimal sikkerhedspåvirkning. Afhjælpning, når det er praktisk.
Ingen 0.0 Informationsresultater uden egentlig indvirkning på sikkerheden. Valgfri afhjælpning.

Eksempler på fortolkning af alvorsgrad:

Kritisk sårbarhed (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

Høj sårbarhed (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

Medium sårbarhed (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

Vurdering af udnyttelsesmuligheder

CVSS-score fortæller ikke hele historien - udnyttelsesvurdering bestemmer den faktiske risiko:

Udnyttelse af løbetid

Udnyttelse af tilgængelighedsfaser:

Uprøvede:

  • Status: Teoretisk sårbarhed uden kendt udnyttelse.
  • Risikoniveau: Lavere risiko – udnyttelse kræver en betydelig indsats fra hackeren.
  • Handling: Overvåge for udnyttelsesudvikling; planlægge afhjælpning, men ikke haster.

Bevis for koncept:

  • Status: Proof-of-concept exploit-kode offentliggjort, men ikke bevæbnet.
  • Risikoniveau: Moderat risiko – sofistikerede angribere kan bruge udnyttelsen som våben.
  • Handling: Prioriter afhjælpning; udvikle afbødningsstrategier.

Funktionel:

  • Status: Fungerende exploit-kode er offentligt tilgængelig.
  • Risikoniveau: Høj risiko – udnyttelse tilgængelig for moderat dygtige angribere.
  • Handling: Fremskynde afhjælpning; Implementer midlertidige afhjælpninger, hvis patching er forsinket.

Aktiv udnyttelse:

  • Status: Sårbarhed udnyttes aktivt i naturen.
  • Risikoniveau: Kritisk risiko – udnyttelse sker nu.
  • Handling: Afhjælpning i nødstilfælde; gennemføre øjeblikkelige afbødningsforanstaltninger; overvåge for kompromittering.

Eksempel på vurdering af udnyttelsesmuligheder:

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

Analyse af angrebsoverfladen

Find ud af, om sårbarheden kan nås:

Tilgængelige faktorer:

  • Brug af kode: Udføres den sårbare kodesti faktisk af dit program?
  • Eksponering af netværk: Er den sårbare komponent udsat for netværksadgang?
  • Krav til godkendelse: Kræver udnyttelse godkendt adgang?
  • Afhængigheder af konfiguration: Kræver sårbarheden, at specifikke konfigurationer kan udnyttes?

Eksempel på tilgængelighed:

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

Miljømæssig kontekst

Overvej dit specifikke miljø:

Segmentering af netværk:

  • Internet-vendt: Sårbarheder i internetvendte komponenter har højeste prioritet.
  • Internt netværk: Sårbarheder, der kun er interne, har lavere prioritet, hvis netværket er segmenteret.
  • Isolerede systemer: Air-gapped eller isolerede systemer har minimal risiko for netværkssårbarheder.

Datafølsomhed:

  • Følsomme oplysninger: Sårbarheder i systemer, der håndterer følsomme data, kræver hurtig afhjælpning.
  • Offentlige oplysninger: Sårbarheder i forbindelse med offentliggørelse af oplysninger har lavere prioritet, hvis data allerede er offentlige.
  • Testmiljøer: Sårbarheder i ikke-produktionsmiljøer har typisk lavere prioritet.

Kompenserende kontrolelementer:

  • Firewall for webapplikationer: WAF-regler kan afbøde forsøg på udnyttelse.
  • Registrering af indtrængen: IDS/IPS kan registrere og blokere udnyttelsesforsøg.
  • Segmentering af netværk: Netværksisolering begrænser udnyttelseseffekten.
  • Mindste privilegium: Begrænsede tilladelser reducerer udnyttelseseffekten.

Administration af falske positiver

Ikke alle rapporterede sårbarheder påvirker faktisk dine applikationer:

Almindelige falske positive årsager

Forkert identificerede komponenter:

  • Navngivningskonflikter: Forskellige komponenter med lignende navne matchede forkert.
  • Fejl i versionsregistrering: Forkert versionsidentifikation, der fører til falske sårbarhedsmatches.
  • Forvirring om pakkenavneområde: Pakker i forskellige økosystemer, der fejlagtigt er identificeret som samme pakke.

Eksempel på falsk positiv:

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

Ubrugte kodestier:

  • Død kode: Sårbar kode importeret, men aldrig udført.
  • Valgfrie funktioner: Sårbarheder i valgfrie funktioner, som dit program ikke aktiverer.
  • Udviklingsafhængigheder: Sårbarheder i pakker, der kun bruges under udvikling, ikke i produktion.

Fejl i versionsinterval:

  • Rapportering af fast version: Scannere rapporterer sårbarhed i versioner, der allerede er rettet.
  • Backport-rettelser: Leverandører tilbagefører sikkerhedsrettelser til ældre versioner uden at ændre versionsnumre.
  • Brugerdefinerede patches: Sårbarheder, der allerede er rettet gennem brugerdefinerede ændringer.

Falsk positiv bekræftelse

Undersøgelsesproces:

  1. Bekræft komponentidentitet: Bekræft, at scanneren har identificeret komponenten korrekt.
  2. Tjek versionsnøjagtigheden: Kontrollér, at den registrerede version stemmer overens med den faktiske installerede version.
  3. Gennemse oplysninger om sårbarheder: Forstå, hvad sårbarheden påvirker.
  4. Analysér kodebrug: Find ud af, om der rent faktisk bruges sårbare kodestier.
  5. Se leverandørvejledninger: Kontrollér, om leverandøren giver yderligere kontekst.
  6. Test udnyttelse: Forsøg at genskabe sårbarheden i testmiljøet.

Krav til dokumentation: Når du undertrykker falske positiver, skal du dokumentere:

  • Begrundelse: Hvorfor fundet er en falsk positiv.
  • Oplysninger om undersøgelsen: Trin, der er taget for at bekræfte falsk positiv.
  • Godkender: Medlem af sikkerhedsteamet, der godkender undertrykkelsen.
  • Dato for gennemgang: Dato for at revurdere undertrykkelsen.

Eksempel på undertrykkelsesfil (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>

Rammer for prioritering

Effektiv sårbarhedshåndtering kræver systematisk prioritering:

Risikobaseret prioritering

Prioriteringsfaktorer:

Sværhedsgrad (25% vægt):

  • CVSS-basisscore giver grundlag for risikovurdering.
  • Højere score indikerer mere alvorlige potentielle virkninger.

Udnyttelsesmuligheder (35% vægt):

  • Aktiv udnyttelsesstatus er den mest kritiske faktor.
  • Tilgængelighed af offentlig udnyttelse øger risikoen betydeligt.
  • Proof-of-concept-udnyttelser indikerer mulig udnyttelse.

Aktivets kritikalitet (20% vægt):

  • Internetvendte applikationer har højere prioritet.
  • Systemer, der behandler følsomme data, kræver hurtig patching.
  • Forretningskritiske programmer kan ikke tolerere forlænget nedetid.

Miljøfaktorer (20% vægt):

  • Eksisterende kompenserende kontroller reducerer den effektive risiko.
  • Netværkssegmentering begrænser eksplosionsradius.
  • Overvågningsfunktioner muliggør trusselsregistrering.

Prioriteringsmatrix:

Udnyttelse Kritisk sværhedsgrad Høj sværhedsgrad Medium sværhedsgrad Lav sværhedsgrad
Aktiv udnyttelse P0 (Nødsituation) P0 (Nødsituation) P1 (kritisk) P2 (Høj)
Funktionel udnyttelse P0 (Nødsituation) P1 (kritisk) P2 (Høj) P3 (Medium)
Bevis for koncept P1 (kritisk) P2 (Høj) P3 (Medium) P4 (Lav)
Uprøvede P2 (Høj) P3 (Medium) P4 (Lav) P5 (valgfrit)

SLA'er til afhjælpning

Definer serviceaftaler til afhjælpning:

Nødsituation (P0):

  • Tidsramme: Øjeblikkelig (inden for 24 timer).
  • Kriterier: Kritiske sårbarheder under aktiv udnyttelse i internetvendte systemer.
  • Proces: Akut ændringsproces med ledelsesmeddelelse.
  • Eksempel: Log4Shell (CVE-2021-44228) i offentlig applikation.

Kritisk (P1):

  • Tidsramme: 7 dage.
  • Kriterier: Høj/kritisk alvorsgrad med funktionelle udnyttelser eller internetvendt eksponering.
  • Proces: Fremskyndet forandringsproces med koordinering af sikkerhedsteamet.
  • Eksempel: SQL-injektion i godkendt administratorgrænseflade.

Høj (P2):

  • Tidsramme: 30 dage.
  • Kriterier: Medium/høj alvorsgrad med proof-of-concept-udnyttelser eller intern eksponering.
  • Proces: Standardændringsproces med planlagt vedligeholdelsesvindue.
  • Eksempel: Cross-site scripting (XSS) i internt dashboard.

Mellem (P3):

  • Tidsramme: 90 dage.
  • Kriterier: Lav/medium sværhedsgrad uden kendte udnyttelser.
  • Proces: Regelmæssig opdateringscyklus med kvartalsvis patching.
  • Eksempel: Offentliggørelse af oplysninger i afhængighed af udviklingsværktøj.

Lav (P4):

  • Tidsramme: Næste store udgivelse.
  • Kriterier: Lav alvorsgrad eller falske positiver, der kræver dokumentation.
  • Proces: Medtag i regelmæssige vedligeholdelsesaktiviteter.
  • Eksempel: Denial of Service i ubrugt valgfri funktion.

Oprettelse af sikkerhedsfejllinjer

Sikkerhedsfejllinjer definerer minimumssikkerhedsstandarder, der skal opfyldes:

Definition af Udført-kriterier

Eksempel på sikkerhedsfejllinje:

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

Håndhævelse af politikker

Azure Pipelines-kvalitetsport:

- 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"

Arbejdsproces for triage af sårbarheder

Systematisk triage sikrer effektiv sårbarhedshåndtering:

Triage-proces

Trin 1: Automatiseret filtrering:

  • Scanner-værktøjer: Filtrer automatisk sårbarheder efter alvorsgrad.
  • Analyse af tilgængelighed: Fjern sårbarheder, der ikke kan nås, fra triagekøen.
  • Kendte falske positiver: Undertryk automatisk tidligere identificerede falske positiver.

Trin 2: Indledende vurdering:

  • Gennemgang af sværhedsgrad: Bekræft CVSS-scorenøjagtigheden for dit miljø.
  • Kontrol af udnyttelse: Bestem udnyttelsestilgængelighed og aktiv udnyttelse.
  • Identifikation af aktiver: Identificer, hvilke applikationer og systemer der er berørt.

Trin 3: Risikovurdering:

  • Indvirkning på forretningen: Vurder den potentielle forretningsmæssige effekt af en vellykket udnyttelse.
  • Analyse af eksponering: Bestem netværkseksponering og angrebsflade.
  • Kompenserende kontrolelementer: Identificer eksisterende afbødninger, der reducerer risikoen.

Trin 4: Prioritering:

  • Tildel prioritet: Brug prioriteringsmatrixen til at tildele afhjælpningsprioritet.
  • Indstil forfaldsdato: Tildel afhjælpningsfrist baseret på SLA.
  • Tildel ejer: Udpeg ansvarligt team til afhjælpning.

Trin 5: Afhjælpningssporing:

  • Opret billetter: Generer arbejdselementer i sporingssystemet (Jira, Azure Boards).
  • Overvågning af fremskridt: Spor afhjælpningsstatus i forhold til deadlines.
  • Kontrol: Valider vellykket afhjælpning via genscanning.

Triage-mødefrekvens

Ugentlig sikkerhedstriage:

  • Deltagere: Sikkerhedsteam, udviklingsledere, driftsrepræsentanter.
  • Dagsorden: Gennemgå nye høje/kritiske resultater, spor afhjælpningsfremskridt, juster prioriteter.
  • Varighed: 30-60 minutter.

Månedlig sårbarhedsgennemgang:

  • Deltagere: Sikkerhedsledelse, teknisk ledelse, compliance-team.
  • Dagsorden: Gennemgå tendenser, juster politikker, vurder den overordnede sikkerhedstilstand.
  • Varighed: 60-90 minutter.

Målinger og rapportering

Spor effektiviteten af sårbarhedsstyring:

Nøglemålepunkter

Målinger af sårbarheder:

  • Gennemsnitlig tid til at detektere (MTTD): Tid fra afsløring af sårbarheder til registrering i dine systemer.
  • Gennemsnitlig tid til afhjælpning (MTTR): Tid fra registrering til vellykket afhjælpning.
  • Tæthed af sårbarhed: Antal sårbarheder pr. program eller kodelinje.
  • Afhjælpningsprocent: Procentdel af sårbarheder, der er afhjulpet i SLA.

Trendmålinger:

  • Antal åbne sårbarheder: Trendvis antal uløste sårbarheder efter alvorsgrad.
  • Nyt vs. løst: Sammenligning af nyligt opdagede og afhjælpede sårbarheder.
  • SLA-overholdelse: Procentdel af sårbarheder, der er afhjulpet inden for definerede SLA'er.
  • Falsk positiv rate: Procentdel af resultater, der er fastslået til at være falske positiver.

Eksempel på dashboard

Dashboard til håndtering af sårbarheder:

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 ✓

Notat

Du kan finde flere oplysninger om serviceaftaler (SLA'er) og afhjælpningstidslinjer under Azure-serviceaftaler.

Effektiv fortolkning og prioritering af sårbarhedsadvarsler omdanner overvældende scanneroutput til handlingsrettede sikkerhedsforbedringer. Ved at forstå alvorsgrad, vurdere udnyttelsesmuligheder, administrere falske positiver og implementere systematisk prioritering fokuserer teams afhjælpningsindsatsen på sårbarheder, der udgør en reel risiko, i stedet for at jagte alle advarsler. Denne risikobaserede tilgang muliggør bæredygtige sikkerhedsprogrammer, der beskytter applikationer uden at overvælde udviklingsteams med støj.