Sa velikom moći dolazi i velika odgovornost
I, kao što su mnogi programeri nedavno otkrili kada su otkriveni višestruki bezbednosni propusti u biblioteci otvorenog koda za evidentiranje Apache Java log4j2, takođe donosi i velike glavobolje. Problemi sa log4j2 su onoliko loši koliko loše može biti. Prema skali Nacionalne baze podataka o ranjivosti (National Vulnerability Database – NVD), ocenjena je kao 10,0 CVSSv3. Njegova prava nevolja nije toliko u samom otvorenom kodu. Bezbednost je proces, a ne proizvod, to jest, potrebna je stalna budnost da bi se obezbedio sav softver. Ipak, pravi problem sa log4j je to kako Java skriva koje biblioteke koristi njen izvorni kod i binarne datoteke u brojnim varijacijama Java arhive (JAR).
Rezultat? Možda koristite ranjivu verziju log4j-a i ne znate sve dok je ne upotrebite. Na sreću, postoje log4j skeneri koji vam mogu pomoći da uočite neispravne log4j biblioteke u upotrebi. Ali – oni nisu savršeni. Iza log4j nereda je još jedan problem, a to je „Kako znate koje komponente otvorenog koda vaš softver koristi?“
Odgovor je onaj koji je zajednica otvorenog koda počela ozbiljno da shvata poslednjih godina: stvaranje softverskih lista materijala (Software Bills of Material – SBOM). SBOM tačno navodi koje softverske biblioteke, rutine i drugi kod su korišćeni u bilo kom programu. Naoružani ovim, možete ispitati koje se verzije komponenti koriste u vašem programu. Na taj način, ako se pronađe bezbednosna rupa u komponenti, možete je jednostavno zakrpiti. Reproducibilni build je onaj koji uvek proizvodi iste izlaze sa istim ulazima tako da se rezultati build-a mogu verifikovati. Verifikovani reproducibilni build je proces u kojem nezavisne organizacije proizvode build iz izvornog koda i potvrđuju da rezultati potiču iz izvornog koda. Da biste to uradili, vi i vaši programeri morate da pratite svoje programe u SBOM-u, koristeći format za razmenu podataka softverskog paketa (Software Package Data Exchange – SPDX) Linux fondacije.
Zatim, da biste dodatno zaštitili da je vaš kod zaista ono što tvrdi da jeste, potrebno je da overite i verifikujete svoj SBOM pomoću usluga kao što su Codenotary Community Attestation Service i Tidelift Catalogs. Sve ovo je lako reći i mnogo teže uraditi. U 2022. godini, skoro svi programeri otvorenog koda će potrošiti dosta vremena na proveru problema u svom kodu, a zatim na pravljenje SBOM-ova zasnovanih na SPDX-u. Korisnici, zabrinuti zbog katastrofa tipa Solarwind i bezbednosnih problema log4j, će to zahtevati. U isto vreme, Linux programeri rade na daljem obezbeđivanju operativnog sistema tako što će Rust Linux učiniti drugim jezikom. Zašto? Jer, za razliku od C-a, primarnog jezika Linux-a, Rust je mnogo sigurniji u rukovanju greškama u memoriji. Ostaje da vidimo kako će sve to proći. Bez obzira kako se odvijaju pojedinosti, jedna stvar je sigurna – obezbeđivanje koda postaje glavno pitanje za Linux i programere otvorenog koda u 2022.
Izvor: PCpress / Zdnet
