A szoftver minden modern vállalkozás magját képezi, és a műveletek minden aspektusában kulcsfontosságú. Szinte minden vállalkozás nyílt forráskódú szoftvereket használ, tudatosan vagy más módon, mivel még a védett szoftverek is a nyílt forráskódú könyvtáraktól függenek. OpenUK A 2022-es „State of Open” jelentés megállapította, hogy a vállalkozások 89%-a nyílt forráskódú szoftverekre támaszkodott, de nem mindegyikük világos a szoftver részleteit illetően, amelyre támaszkodik.
A vállalkozások egyre több információt követelnek működés szempontjából kritikus szoftvereikről. A felelős vállalkozások részletesen érdeklődnek szoftverellátási láncuk iránt, és minden alkalmazáshoz szoftverjegyzéket (SBOM) készítenek. Ez az információszint kulcsfontosságú ahhoz, hogy amikor a szoftverükben biztonsági hibákat észlelnek, azonnal megbizonyosodjanak arról, hogy melyik szoftver és verzió van használatban, és mely rendszereket érinti az érintett. A tudás hatalom ezekben a helyzetekben!
Önkéntesekre támaszkodás
2021 végén egy biztonsági rés ún Log4Shell egy széles körben használt Java naplózási keretrendszerben, a Log4j-ben azonosították. Mivel ez egy széles körben használt, nyílt forráskódú könyvtár, a sérülékenység nagy nyilvánosságot kapott, és javítások várhatók. Azonban a a projekt fenntartói önkéntesek voltak. Napi munkájuk volt, és nem voltak készenlétben sürgős biztonsági javítások miatt, még akkor sem, ha sok rendszer érintett. Ez a sérülékenység önmagában a becslések szerint a vállalati felhőkörnyezetek 93%-át érintette.
Abban az időben volt néhány negatív sajtó a nyílt forráskóddal kapcsolatban, de az igazság az, hogy ha ez egy zárt forráskódú összetevő volt, akkor a sérülékenység valószínűleg soha nem lett volna nyilvánosan ismert, így a szervezetek nyitva maradtak a támadásokra. A könyvtár nyílt forráskódú jellege azt jelentette, hogy megtekinthető volt, megtalálták a problémákat, és mások is tanácsot adhattak. Tehát igen, a fenntartók nem voltak készenlétben biztonsági problémák miatt önkéntes projektjükben. A nagy kérdés tehát a következő: Hogyan kerültünk abba a helyzetbe, hogy a nagyvállalatok olyan szoftverektől függtek, amelyekért valaki mást vállal a számláik kifizetéséért?
A szoftverfüggőségek figyelmen kívül hagyása kockázatos üzlet, függetlenül a szoftver licencétől, de amikor nyílt forráskódú és nagyon széles körben használják, akkor különösen veszélyessé válik. Ragaszkodunk egy sebezhetőség történetéhez; a probléma évek óta létezett a kódbázisban, de nem vették észre. Az olyan széles körben használt eszköz valójában nem volt olyan széles körben támogatott – és ami ezután történt, az már történelem.
Ez a történet újra és újra megismétlődik oly sok olyan vállalkozásnál, amelyek kritikus függőséggel rendelkeznek, de nem tesznek lépéseket sem a karbantartók, sem maguk a projektek támogatására. Az SBOM birtoklása a vállalkozások által használt szoftverekhez azt jelenti, hogy kéznél vannak az információk. Azoknál a szervezeteknél, amelyek szoftvert szállítanak másoknak, egyre inkább elvárás, hogy a kóddal együtt szállítsák az SBOM-ot.
Ismerje meg a függőségeket a kockázat felméréséhez
A függőségek ismerete megkönnyíti az egyes függőségekkel kapcsolatos kockázatok felmérését. Ezeket a nyílt forráskódú projekteket a legegyszerűbb felmérni: reagáltak-e a problémákra, és megjelentek-e mostanában kiadások? Az egyes projektek fenntartóinak és projekttevékenységeinek megtekintése jó betekintést nyújt a projekt állapotába.
A vállalkozások hozzájárulhatnak a kockázatok csökkentéséhez azáltal, hogy támogatják azokat a projekteket, amelyektől függenek. Egyes projektek közvetlenül a GitHub Sponsors rendszeren keresztül fogadják el a szponzorációt, mások ehelyett tárhelyajánlatokat vagy biztonsági auditot értékelhetnek. Minden nyílt forráskódú projekt nagyra értékeli a hozzájárulásokat. Ha az Ön vállalkozása maga hozta létre ezt a könyvtárat, akkor a vállalaton belüli mérnököknek maguknak kellene minden hibát kijavítaniuk.
A nyílt forráskód inkább egy megosztott tulajdoni rendszer. Nem kell mindannyiunknak többször megépíteni ugyanazt a dolgot, inkább hozzá tudunk járulni, ami egyrészt kevesebb erőfeszítést, másrészt jobb minőséget eredményez. Az egyik leghatásosabb dolog, amit a vállalkozások tehetnek, ha egy keveset használnak mérnöki erőforrásaikból és hozzájárulnak a projektek hibajavításaihoz vagy szolgáltatásaihoz amelyek annyira fontosak az üzletben.
Saját mérnökeinek bevonása egy projektbe számos előnnyel rendelkezik. Megismerik, és figyelemmel kísérhetik az új funkciókat, vagy ha új kiadás érhető el. Létfontosságú, hogy a vállalkozás betekintést nyerjen a függő projekt állapotába és állapotába, és része annak, ami azt egészségesen tartja, csökkentve annak kockázatát, hogy a függőséggel kapcsolatos probléma a vállalkozást fenyegeti. Számos szervezet, köztük az Aiven is rendelkezik OSPO-val (nyílt forráskódú programiroda), amelynek munkatársai elkötelezettek a szervezet által használt projektekben való közreműködésben vagy akár karbantartásban. Ezek a részlegek gyakran hozzájárulnak a vállalat általános jelenlétéhez a nyílt forráskódú ökoszisztémában, és lehetővé teszik a többi alkalmazott számára, hogy kapcsolatba lépjenek a nyílt forráskóddal.
Egy másik megközelítés a nyílt forráskódot támogató szervezetek támogatása. A OpenSSF (Open Source Security Foundation) a nyílt forráskódú projektek biztonságának javításán dolgozik, és az ezektől a projektektől függő szervezetek finanszírozzák. Kiváló tanulási forrásokat is közzétesz, hogy a vállalkozások tájékozódhassanak az általuk használt szoftverek kockázatairól. Egy másik hasonló szervezet Árapályfelvonó, amely a fenntartókkal együttműködve bizonyos alapkövetelmények teljesítését biztosítja, szintén a szervezetek finanszírozzák. A Tidelift eszközöket és oktatást is biztosít, hogy segítse a vállalkozásokat a szoftverellátási lánc kezelésében, és ezen a területen a legjobb gyakorlatok átvételében.
Biztonságosabb szoftverjövő biztosítása
A vállalkozások a szoftverektől függenek, és ez magában foglalja a nyílt forráskódú szoftvereket is, amelyeket széles körben használnak, és jellemzően biztonságosabbak, mint a szabadalmaztatott alternatívák.
Ez okos lépés, de még okosabb lépés a szoftverellátási lánc és annak függőségei világos ismerete. Ha probléma merül fel, az egészséges projektektől és a szoftver részleteinek rendelkezésre állásától függően minden szervezetnek segítséget nyújt. Ha minden szervezet megtenné ezt, akkor csökken az olyan események kockázata, mint például a Log4Shell sebezhetősége.
