A nyílt forráskódú szoftverek biztonsága felkeltette az ipar figyelmét, de a megoldásokhoz konszenzusra van szükség a kihívások és az együttműködés terén a megvalósításban.
A probléma összetett, és sok szempontot le kell fedni, az ellátási láncból, a függőségkezelés, az identitás, többek között. Ennek érdekében a Google nemrégiben kiadott egy keretrendszert („Ismerje meg, akadályozzon meg, javítson”), amely elmagyarázza, hogy az ipar hogyan gondolkodhat a nyílt forráskódú sebezhetőségekről és olyan konkrét területekről, amelyekkel először foglalkozni kell.
A Google elmagyarázza annak okait:
„A közelmúlt eseményei miatt a szoftvervilág mélyebben megértette az ellátási lánc támadások valós kockázatát. A nyílt forráskódú szoftvereknek biztonsági szempontból kevésbé kockázatosaknak kell lenniük, mivel az összes kód és függőség nyitott és elérhető ellenőrzésre és ellenőrzésre. És bár ez általában igaz, feltételezzük, hogy az emberek valóban elvégzik ezt az ellenőrzési munkát. Ennyi függőség esetén lehetetlen mindegyiket figyelemmel kísérni, és sok nyílt forráskódú csomag nincs megfelelően karbantartva.
„Gyakori, hogy egy program közvetlenül vagy közvetve a csomagok és könyvtárak ezreitől függ. Például a Kubernetes most körülbelül 1000 csomagtól függ. A nyílt forráskód valószínűleg függőségeket használ, nem pedig saját szoftvereket, és a gyártók szélesebb köréből származik; a megbízható független entitások száma nagyon nagy lehet. Ez rendkívül megnehezíti annak megértését, hogy a nyílt forrást hogyan használják a termékekben, és milyen sérülékenységek lehetnek relevánsak. Nincs garancia arra sem, hogy ami épül, meg fog egyezni a forráskóddal.
A Google által javasolt keretek között javasoljuk, hogy ezt a nehézséget három nagyrészt független problématerületre osszák fel, amelyek mindegyikének konkrét céljai vannak:
Ismerje szoftverének sebezhetőségét
A szoftveres sebezhetőségek ismerete bonyolultabb, mint amire számíthat sok ok miatt. igen ok léteznek mechanizmusok a sebezhetőségek jelentésére, nem világos, hogy valóban befolyásolják-e a használt szoftver konkrét verzióit:
- Cél: Pontos biztonsági rés-adatok: Először is elengedhetetlen a pontos sebezhetőségi metaadatok rögzítése az összes rendelkezésre álló adatforrásból. Például annak ismerete, hogy melyik verzió hozta be a biztonsági rést, segít meghatározni, hogy a szoftver érintett-e, és annak ismerete, hogy mikor javították, pontos és időszerű javításokat eredményez (és egy szűk ablakot jelent a lehetséges kihasználáshoz). Ideális esetben ezt az osztályozási munkafolyamatot automatizálni kell.
- Másodszor, a legtöbb sebezhetőség a függőségekben rejlik, nem pedig a közvetlenül írt vagy irányított kódban. Tehát akkor is, ha a kódja nem változik, a szoftvert érintő sérülékenységek területe folyamatosan változhat - egyesek javításra kerülnek, mások pedig hozzáadódnak.
- Cél: Szabványos séma a sebezhetőségi adatbázisokhoz Az infrastruktúra és az iparági szabványok szükségesek a nyílt forráskódú sebezhetőségek nyomon követéséhez és fenntartásához, azok következményeinek megértéséhez és azok enyhítésének kezeléséhez. A szabványos sebezhetőségi séma lehetővé tenné a közös eszközök számára, hogy több sebezhetőség-adatbázison fussanak, és egyszerűsítse a nyomon követés feladatát, különösen akkor, ha a biztonsági rések több nyelvet vagy alrendszert kereszteznek.
Kerülje az új biztonsági rések hozzáadását
Ideális lenne elkerülni a sebezhetőségek kialakulását És bár a tesztelési és elemzési eszközök segíthetnek, a megelőzés mindig nehéz téma lesz.
itt A Google azt javasolja, hogy két konkrét szempontra összpontosítson:
- Értse meg a kockázatokat, amikor új függőségről dönt
- Javítsa a kritikus szoftverfejlesztési folyamatokat
Javítsa vagy távolítsa el a biztonsági réseket
A Google elismeri, hogy a javítás általános problémája meghaladja a hatáskörét, de a kiadó úgy véli, a szereplők sokkal többet tehetnek a probléma megoldása érdekében specifikus a függőségek sebezhetőségének kezelésére.
Megemlíti továbbá:
„Ma kevés segítség van ezen a fronton, de ahogy javítjuk a pontosságot, érdemes új folyamatokba és eszközökbe fektetni.
„Az egyik lehetőség természetesen a biztonsági rés közvetlen javítása. Ha ezt visszafelé kompatibilis módon tudja megtenni, a megoldás mindenki számára elérhető. De a kihívás az, hogy nem valószínű, hogy rendelkezik tapasztalattal a problémával vagy a változtatások közvetlen képességével. A biztonsági rés elhárítása azt is feltételezi, hogy a szoftver karbantartásáért felelős személyek tisztában vannak a problémával, és rendelkeznek ismeretekkel és erőforrásokkal a biztonsági rés feltárására.
forrás: https://security.googleblog.com
Az angol nyelvű eredeti azt mondja:
Itt két konkrét szempontra összpontosítunk:
- A kockázatok megértése, amikor új függőségről dönt
- A kritikus szoftverek fejlesztési folyamatainak javítása
A "LinuxAdictos" verzió így szól:
Itt a Google azt javasolja, hogy két konkrét szempontra összpontosítson:
- Értse meg a kockázatokat, amikor új függőséget választ.
- A kritikus szoftverfejlesztési folyamatok fejlesztése
Új függőség!?