SBOM, ievainojamības un VEX: no signāla līdz lēmumam

Sāc ar precīzu sakritību

Kad parādās paziņojums par ievainojamību, pirmais uzdevums ir noteikt, vai tas attiecas uz izmantoto pakotni un versiju. Nosaukumu sakritība vien var maldināt, īpaši starp dažādām ekosistēmām. Salīdzini pakotnes identifikatoru, izcelsmi, versijas diapazonu un piegādātāja paziņojumu. Ja dati nav pietiekami, atzīmē nenoteiktību, nevis izveido drošības secinājumu.

SBOM šajā posmā darbojas kā produkta inventārs. Tas ļauj sasaistīt komponenti ar atbalstītajiem laidieniem un atrast atbildīgo komandu. Saglabā izmantotā SBOM redakciju un ievainojamības avota pārbaudes datumu. Vēlāks paziņojuma labojums vai precizēta versijas robeža var mainīt sākotnējo vērtējumu, pat ja pats produkts nav mainīts.

Komponentes klātbūtne vēl neizskaidro ietekmi

Tālāk jānoskaidro, vai ievainojamais kods ir produktā un kādos apstākļos tas var tikt izmantots. Svarīga var būt konfigurācija, sasniedzamība, piekļuves tiesības un izmantotās funkcijas. Piemēram, bibliotēka var būt iekļauta, bet konkrētā funkcija netiek izsaukta. Šāds pieņēmums ir jāpārbauda, un pierādījums jāsaista ar noteiktu produkta versiju.

Nepietiek ar paskaidrojumu “to neizmantojam”, ja nav zināms, kas to pārbaudījis un uz kā pamata. Pieraksti tehnisko pamatojumu, ierobežojumus un apstākļus, kuru maiņa prasītu atkārtotu izvērtēšanu. Ja nav iespējams iegūt pietiekamu pārliecību, saglabā atvērtu izpētes uzdevumu un vienojies par pagaidu riska mazināšanu. Nepārvērt nenoteiktību par pozitīvu statusu.

Ko pievieno VEX

VEX jeb Vulnerability Exploitability eXchange ir veids, kā strukturēti paziņot par ievainojamības ietekmi konkrēta produkta kontekstā. CycloneDX VEX skaidrojums uzsver tieši ekspluatējamību produkta lietojumā. Šāda informācija var palīdzēt prioritizēt darbu, taču tās vērtība ir atkarīga no izdevēja, pamatojuma, aktualitātes un precīzas saiknes ar produktu.

VEX nav atļauja automātiski ignorēt paziņojumu. Pārbaudi dokumenta izdevēju, attiecīgo produktu, laidienu, ievainojamības identifikatoru un statusa pamatojumu. Noskaidro, vai ziņojums ir atjaunināts un vai tas aptver tavu konfigurāciju. Ja piegādātāja apgalvojums neatbilst tavai izvietošanas videi, eskalē atšķirību, saglabājot abus informācijas avotus.

Izveido triāžu ar skaidru iznākumu

• Reģistrē signālu un norādi tā avotu, pārbaudes laiku un sākotnēji skartos produktus.
• Pārbaudi komponentes identitāti un ievainojamības versiju diapazonu, nepaļaujoties tikai uz nosaukumu.
• Dokumentē produkta kontekstu, piegādātāja skaidrojumu un VEX pierādījumus, ja tie ir pieejami.
• Vienojies par atjaunināšanu, konfigurācijas maiņu vai turpmāku izpēti, piešķirot atbildīgo un termiņu.
• Pārbaudi rīcības rezultātu un saglabā slēgšanas pamatojumu; vajadzības gadījumā atjauno SBOM.

SPDX projekts apraksta, kā tā 3. versijā ievainojamību informāciju var sasaistīt ar programmatūras datiem. Neatkarīgi no izmantotā formāta uzturi saikni starp avotu, produktu un komandas lēmumu. Kad mainās konfigurācija, produkta sastāvs vai paziņojuma informācija, iepriekšējais vērtējums var būt jāpārskata. Nosaki, kurš seko šīm izmaiņām.

Kur beidzas šīs vietnes pārskats

SBOM.lv lokālais rīks neizsauc ievainojamību datubāzes, neveic CVE salīdzināšanu un nepārbauda VEX apgalvojumus. Tas apskata komponenšu metadatus, kas var būt noderīgi pirms turpmākā darba. Trūkstoša versija ir datu jautājums; aizpildīta versija nav drošības atzinums. PDF kontrolsaraksts palīdz sadalīt pārskatīšanas uzdevumus.

Ja produkts ietilpst CRA tvērumā, atsevišķi izvērtē arī ziņošanas un ievainojamību apstrādes pienākumus. Tehniskais triāžas process ir jāsasaista ar organizācijas atbildību un saziņu. Sagatavots inventārs saīsina meklēšanu, taču efektīvai reaģēšanai joprojām vajadzīgi cilvēki, uzticami avoti un pārbaudāma darba secība.