A nyílt forráskódú összetevők sérülékenységei – például a 10 hónappal ezelőtt a Log4j 2.0-ban feltárt széles körben elterjedt hibák – arra kényszerítették az adatkutatókat, hogy újraértékeljék az elemzésekben és a gépi tanulási modellek létrehozásában gyakran használt nyílt forráskódot.
Az Anaconda, egy adattudományi platform cég jelentése szerint az elmúlt évben a megkérdezett adattudósok, üzleti elemzők és hallgatók 40%-a csökkentette a nyílt forráskódú összetevők használatát, míg egyharmad változatlan maradt, és csak 7 % több nyílt forráskódot épített be projektjeikbe. A megkérdezettek többsége nem az informatikai osztályon jelentkezik (18%), hanem saját adattudományi vagy kutatás-fejlesztési csoportjában dolgozik (47%) – derül ki az Anaconda „2022. Az adattudomány állapota” múlt héten közzétett jelentés.
Míg a szoftverfejlesztők és az informatika már megkezdte a biztonságos kód ellenőrzését, a nyílt forráskódú szoftverek biztonságával kapcsolatos aggodalmak viszonylag új trendet jelentenek az adattudományi világban – mondja Peter Wang, az Anaconda társalapítója és vezérigazgatója.
„Az emberek nagy részét látjuk olyan szervezeteknél, ahol az IT nagyon szigorú álláspontot alakított ki a nyílt forráskóddal és a Pythonnal kapcsolatban” – mondja. „Ezek nem szakértő fejlesztők. … Ők adattudósok és gépi tanulással foglalkozó emberek, akik talán egyáltalán nem túl tapasztalt fejlesztők, és bármit felhasználnak az elemzéshez, amit csak tudtak letölteni, majd ezt átadták az IT-nek.”
A nyílt forráskódú összetevők – és általában a szoftverellátási lánc – biztonsága az elmúlt két évben elsődleges szempont lett a szoftverfejlesztők, a vállalkozások és a nemzeti kormányok körében. Májusban például az Egyesült Államok Nemzeti Szabványügyi és Technológiai Intézete (NIST) útmutatót adott ki a szoftverellátási lánc kockázatainak kezelésére. Ezen túlmenően, egyre több szoftvergyártó csatlakoztak a Linux Foundation Open Software Security Foundation nevű szervezetéhez (OpenSSF).
Összességében a szervezetek biztonsági erőfeszítéseinek érettsége javult. A cégek körülbelül fele rendelkezik nyílt forráskódú biztonsági politikával, ami jobb teljesítményt eredményez a biztonsági felkészültség terén, a júniusi felmérés szerint. Ezenkívül a nyílt forráskódú kockázatok ellenőrzésére irányuló erőfeszítések 51%-kal ugrottak meg az elmúlt 12 hónapban, a biztonsági érettségről szóló tanulmány megállapította szeptember 21.
"A szoftverellátási láncokra fordított figyelem miatt a legtöbb vállalati szervezet kockázatalapú megközelítést alkalmaz az alkalmazások biztonsága terén" - mondta Jason Schmitt, a Synopsys Software Integrity Group vezérigazgatója a tanulmányt bejelentő közleményében. „Egy ilyen megközelítés elismeri, hogy a biztonság nem korlátozódik a kódbázisra; magában foglalja a szoftverfejlesztési folyamatot, ahol a biztonsági felülvizsgálatok és tesztelések „mindenhol eltolódnak”, hogy folyamatosan javítsák a biztonsági eredményeket.”
A fejlesztők kiterjesztik a nyílt forráskód használatát
Más adatok szerint a szoftvercégek nem tapasztalnak semmiféle csökkenést a nyílt forráskód használatában. Ehelyett a fejlesztő szervezetek a nyílt forráskódú szoftverek biztonságának javítására összpontosítanak, és a biztonságot használják elsődleges útmutatóként az összetevők kiválasztásánál.
Ban,-ben "A szoftverellátási lánc állapota 2021. A jelentésben például a Sonatype megállapította, hogy a négy legjobb nyílt forráskódú ökoszisztéma – a Maven Central Repository (Java), a Node.js (JavaScript), a Python Package Index (Python) és a NuGet galéria (.NET) – 37 millió embernek ad otthont. nyílt forráskódú projektek és összetevők, ami 20%-os növekedést jelent az előző évhez képest. Az ilyen komponensek iránti kereslet is növekszik: több mint 2.2 billió komponenst töltöttek le, ami 73%-os éves növekedés.
Tracy Miranda, a Chainguard nyílt forráskódú részlegének vezetője szerint, ha az adattudományi közösség saját bevallása szerint eltávolodik a nyílt forráskódú csomagoktól, az valószínűleg azt jelzi, hogy nagyobb a tudatosság a biztonsági problémákkal kapcsolatban, és kevesebbet kell elhagyni a nyílt forráskódú összetevőket a fejlesztés során.
Míg az adattudományi csapatok és a fejlesztőcsapatok eltérően reagálhattak a fő biztonsági problémákra – mint például a Log4j 2.0 – A vállalatoknak nem sok lehetőségük van egy nyílt forráskódú csomagtól való elszakadáshoz, mint egy másik csomag elfogadásához, amelynek karbantartói nagyobb hangsúlyt fektetnek a biztonságra – mondja.
„A vállalatok kihasználják a nyílt forráskódot, hogy növeljék sebességüket, így ha visszalépnek, mire lépnek vissza? Házon belül kódot írni? Harmadik féltől származó, összecsomagolt verziókat használ? Miranda ehelyett hozzáteszi: "Szerintem azt várhatjuk, hogy a vállalatok jobban odafigyeljenek az általuk használt nyílt forráskód minőségére, különösen a biztonsági funkciókkal kapcsolatban."
Az adattudósok felzárkóznak
A két oldal közötti kapcsolat megszakadása valószínűleg a különböző felmérések eltérő közönségének köszönhető. Az Anaconda felmérése az adattudományi szakemberekre összpontosított, amint az a válaszadók programozási nyelvválasztásából is kitűnik – 58%-uk Pythont és 42%-uk SQL-t, míg csak 26%-uk JavaScriptet.
A szoftverfejlesztői érzelmek jobb mércéje a StackOverflow „2022 -es fejlesztői felmérés”, amely megállapította, hogy míg a „kódolni tanuló emberek” 58%-a használ Pythont, addig a professzionális fejlesztőknek csak 44%-a kódol ezen a nyelven. A StackOverflow felmérése szerint viszont a professzionális fejlesztők 68%-a használ JavaScriptet.
Ezen túlmenően, míg az adattudományi szakemberek túlnyomórészt (87%) a nyílt forráskódú szoftvereket engedélyező vállalatoknál dolgoznak, körülbelül egynegyedük (26%) minimálisan felügyeli a nyílt forráskódú választásait az IT-részleg – áll az Anaconda jelentésében. A cégek további 18%-ában az informatikai részleg az elérhető nyílt forráskódú komponensek körülbelül felét határozza meg.
A legkritikusabb projektek karbantartóinak – amelyekből több száz, ha nem több ezer van – biztonságos függőséget kell használniuk, saját kódjukat tesztelniük kell, és ellenőrizniük kell a közreműködők megbízhatóságát. A fenntartóknak biztonsági eredménymutatót is közzé kell tenniük – a Google által létrehozott kezdeményezés, amelyet most az Open Source Security Foundation (OpenSSF) kezel, amely közel 20 különböző szempont alapján ad biztonsági fokozatot egy projektnek.
Bár a tudatosság valószínűleg növekszik, nincs gyors megoldás, mondja Miranda.
„A valóság az, hogy a biztonságosabb lehetőségek korábban nem léteztek” – mondja. "A szükségtelen függőségek levágása a támadási felület csökkentése érdekében ésszerű, de nehéz megtenni, ha a függőségi fa már nagyra nőtt."
