Zaupate programski opremi. Kaj pa njenim komponentam? | Co.Next
Odkrivanje skritih tveganj v dobavni verigi programske opreme
Co.Next × Black Duck | NTK 2026, Portorož
Slika 1. Vizual kampanje.
| Sodobne organizacije uporabljajo bistveno več programske opreme, kot je razvijejo same. Komercialne aplikacije, odprtokodne knjižnice, vsebniki, firmware, vgrajeni sistemi in binarne datoteke dobaviteljev so postali del skoraj vsakega tehnološkega okolja. Izziv zato ni več samo vprašanje, ali zaupamo dobavitelju programske opreme. Ključno vprašanje je, ali lahko neodvisno razumemo in preverimo komponente v programski opremi, ki jo dejansko prejmemo in namestimo. |
Programi aplikacijske varnosti so bili tradicionalno osredotočeni na izvorno kodo: statično analizo, testiranje razvijalcev, varno programiranje in kontrole v CI/CD. Vse to ostaja nujno, vendar pokriva samo del dejanskega programskega okolja. Organizacije uporabljajo tudi prevedene aplikacije, naprave, firmware, vsebnike in druge artefakte, pri katerih izvorna koda pogosto sploh ni na voljo.
S tem nastane praktična slepa pega. Ranljivost v komponenti tretje strani ni nič manj pomembna zato, ker se komponenta skriva v komercialni binarni datoteki. Enako velja za zastarele knjižnice, nepodprte različice in licenčne obveznosti. Če je komponenta del programske opreme, ki jo uporabljate, njeno tveganje postane tudi vaše tveganje.
Seznam sestavnih delov programske opreme oziroma SBOM je postal eden najpomembnejših mehanizmov za večjo preglednost programske dobavne verige. Omogoča strukturiran seznam komponent, različic in njihovih povezav ter varnostnim, nabavnim in skladnostnim ekipam daje skupno osnovo za odločanje.
Toda SBOM odpira tudi pomembno operativno vprašanje: kako preveriti, da seznam dejansko ustreza dostavljenemu artefaktu? Programska oprema se lahko spremeni med pakiranjem, komponente se lahko skrivajo znotraj prevedenih datotek, dobaviteljev SBOM pa je lahko ustvarjen v drugi fazi procesa izdelave. Namen preverjanja ni nezaupanje v SBOM, temveč večja stopnja zagotovila s primerjavo deklariranega stanja z dejansko programsko opremo.
Binarna analiza doda prav to dodatno raven vidljivosti. Namesto da bi se opirali samo na repozitorije izvorne kode ali build manifeste, se analiza začne pri prevedenem artefaktu: izvršljivi datoteki, knjižnici, firmware sliki, vsebniku ali zapakirani aplikaciji. Analiza ugotovi, kaj je dejansko prisotno, identificirane komponente pa je nato mogoče oceniti z vidika znanih ranljivosti, različic in licenčnih tveganj.
Black Duck Binary Analysis (BDBA) je zasnovan prav za takšne scenarije. Analizo sestave programske opreme razširi na artefakte, pri katerih izvorna koda ni na voljo, zato je posebej zanimiv za komercialno programsko opremo, dobaviteljske rešitve, embedded okolja, IoT in OT, firmware ter container slike.
Za organizacije, ki za cloud aplikacijsko varnost uporabljajo Black Duck Polaris, BDBA doda pomembno perspektivo: Polaris pokriva programsko opremo, ki jo razvijamo in testiramo, binarna analiza pa pomaga razumeti programsko opremo, ki jo prejmemo, zapakiramo ali nameščamo. Skupaj predstavljata širši pristop k varnosti programske dobavne verige.
Predstavljajmo si preprost dobaviteljski scenarij. Dobavitelj dostavi poslovno kritično aplikacijo skupaj s SBOM-om. Organizacija lahko deklaracijo sprejme in jo uporabi za spremljanje ranljivosti. Zrelejši proces pa lahko analizira tudi dostavljeno binarno datoteko in odkrito sestavo primerja s posredovanimi podatki.
Vrednost ni samo v odkritju nepričakovane kritične ranljivosti. Preverjanje lahko razkrije dodatne komponente, zastarele različice, licenčne obveznosti ali razlike, ki so nastale v poznejših fazah izdelave in pakiranja. Nabavnim in varnostnim ekipam daje dokaz o artefaktu, ki bo dejansko prišel v produkcijo.
To je še posebej pomembno za organizacije z industrijskimi sistemi, omrežnimi napravami, vgrajenimi sistemi ali reguliranimi produkti. Programska oprema tretjih strani tam pogosto ostane nameščena več let, izvorna koda ni dostopna, sposobnost razumevanja vsebine firmware-a ali izvršljive datoteke pa lahko bistveno izboljša odziv na ranljivosti.
Tudi trg se razvija v tej smeri. Gartnerjev Magic Quadrant za Software Supply Chain Security za leto 2026 obravnava varnost programske dobavne verige kot samostojno kategorijo. Na priloženi grafiki Magic Quadranta z oznako »As of May 2026« je Black Duck uvrščen v kvadrant Leaders.
To je pomembno, ker se razprava pomika dlje od posameznih funkcij SAST ali SCA. Organizacije vse bolj potrebujejo usklajen pristop k odvisnostim tretjih strani, izvoru programske opreme, upravljanju SBOM-ov, preverjanju artefaktov, informacijam o ranljivostih ter kontrolam, ki povezujejo razvoj, nabavo in operacije.
Zaupanje ostaja bistveni del vsakega odnosa z dobaviteljem, vendar zaupanje in preverjanje nista nasprotji. Preverjanje zagotavlja dokaze. Pomaga odgovoriti na zelo praktično vprašanje: ali programska oprema, ki smo jo prejeli, vsebuje to, kar verjamemo, da vsebuje, in ali razumemo tveganja teh komponent?
Na NTK 2026 v Portorožu bo Co.Next ta izziv predstavil skozi praktične primere binarne analize in vidljivosti programske dobavne verige. Pogledali bomo dlje od pregledovanja izvorne kode ter pokazali, kako lahko organizacije analizirajo binarne datoteke, firmware in vsebnike, preverjajo podatke o komponentah ter preidejo od predpostavljenega zaupanja k merljivemu zagotovilu.
Programski opremi zaupate. Kaj pa njenim komponentam? Prvi korak je vedeti, kaj je dejansko v notranjosti.
Slika 2. Gartner® Magic Quadrant™ for Software Supply Chain Security, stanje maja 2026. Black Duck je prikazan v kvadrantu Leaders. Grafiko je zagotovil sponzor.
| Pridružite se Co.Next na NT 2026 v Portorožu in spoznajte, kako lahko binarna analiza razkrije, kaj se dejansko skriva v programski opremi, ki jo prejmete. |
