2022 augusztusában az Enterprise Strategy Group (ESG) kiadta „Walking the Line: GitOps és Shift Left Security”, egy többkliens fejlesztői biztonsági kutatási jelentés, amely az alkalmazások biztonságának jelenlegi állapotát vizsgálja. A jelentés legfontosabb megállapítása a szoftver-ellátási lánc kockázatainak elterjedtsége a felhőalapú alkalmazásokban. Jason Schmitt, a Synopsys Software Integrity Group vezérigazgatója megismételte ezt, és kijelentette: „Mivel a szervezetek szemtanúi vannak annak, hogy a szoftver-ellátási lánc biztonsági rése milyen potenciális hatást gyakorolhat üzleti tevékenységükre nagy horderejű címszavakon keresztül, ezért a A proaktív biztonsági stratégia ma már alapvető üzleti követelmény.”
A jelentés azt mutatja, hogy a szervezetek felismerik, hogy az ellátási lánc több, mint pusztán függőségek. Fejlesztői eszközök/folyamatok, repók, API-k, infrastruktúra-kódként (IaC), konténerek, felhőkonfigurációk és még sok más.
Bár a nyílt forráskódú szoftverek jelenthetik az eredeti ellátási láncot, a felhőalapú alkalmazások fejlesztése felé való elmozdulás miatt a szervezetek aggódnak az ellátási láncuk további csomópontjait érintő kockázatok miatt. Valójában a szervezetek 73%-a számolt be arról, hogy „jelentősen növelte” szoftver-ellátási lánc biztonsági erőfeszítéseit, válaszul a közelmúltbeli ellátási lánc támadásokra.
A jelentésben szereplő felmérésre válaszolók kulcsfontosságú biztonságként említették az erős többtényezős hitelesítési technológia valamilyen formájának elfogadását (33%), az alkalmazásbiztonsági tesztelési ellenőrzésekbe való befektetést (32%), valamint a szervezetük támadási felületének frissítése érdekében a jobb eszközfelderítést (30%). kezdeményezések, amelyeket az ellátási lánc támadásaira válaszul folytatnak.
A válaszadók 42 százaléka az API-kat jelölte meg a szervezetükben manapság a támadásokra leginkább kitett területként. Az adattárolási adattárakat 34% tartotta a leginkább veszélyeztetettnek, az alkalmazástároló-képeket pedig XNUMX% jelölte meg a legérzékenyebbnek.
A jelentés azt mutatja, hogy a nyílt forráskódú menedzsment hiánya fenyegeti az SBOM összeállítását.
A felmérés kimutatta, hogy a szervezetek 99%-a nyílt forráskódú szoftvereket használ vagy tervez használni a következő 12 hónapon belül. Míg a válaszadóknak sok aggályaik vannak ezeknek a nyílt forráskódú projekteknek a karbantartásával, biztonságával és megbízhatóságával kapcsolatban, a legtöbbet idézett aggodalmuk a nyílt forráskód alkalmazásfejlesztésben való felhasználásának mértékével kapcsolatos. A nyílt forráskódot használó szervezetek 75 százaléka úgy gondolja, hogy szervezetük kódja legfeljebb XNUMX%-ban nyílt forráskódú – vagy fog – állni. A válaszadók XNUMX százaléka a nyílt forráskódú szoftverekkel kapcsolatos problémaként vagy kihívásként említette, hogy „az alkalmazáskódok nagy százaléka nyílt forráskódú”.
A szinopszis tanulmányok szintén összefüggést találtak a nyílt forráskódú szoftverek (OSS) használatának mértéke és a kapcsolódó kockázatok jelenléte között. Az OSS-használat mértékének növekedésével természetesen az alkalmazásokban való jelenléte is növekedni fog. A szoftverellátási lánc kockázatkezelésének javítására irányuló nyomás a figyelem középpontjába került szoftverszámla anyagok (SBOM) összeállítása. A robbanásszerű OSS-használat és a hiányos OSS-kezelés miatt azonban az SBOM-összeállítás összetett feladattá válik – és az ESG-vizsgálatban a megkérdezettek 39%-a kihívásként jelölte meg az OSS használatát.
Az OSS kockázatkezelés prioritást élvez, de a szervezetek nem határozzák meg egyértelműen a felelősségi köröket.
A felmérés rámutat arra a valóságra, hogy míg a közelmúlt eseményei (például a Log4Shell és a Spring4Shell sebezhetősége) nyomán a nyílt forráskódú javításokra való összpontosítás az OSS kockázatcsökkentő tevékenységeinek jelentős növekedését eredményezte (a fent említett 73%), a felelős fél ezek a mérséklő erőfeszítések továbbra is tisztázatlanok.
Egyértelmű többsége DevOps csapatok az OSS-kezelést a fejlesztői szerep részeként tekinti, míg a legtöbb IT-csapat a biztonsági csapat felelősségének tekinti. Ez jól megmagyarázhatja, hogy a szervezetek miért küzdenek sokáig az OSS megfelelő javításával. A felmérés kimutatta, hogy az IT-csapatok jobban aggódnak, mint a biztonsági csapatok (48% vs. 34%) az OSS-kód forrása miatt, ami az IT szerepét tükrözi az OSS sebezhetőségi javításainak megfelelő karbantartásában. Tovább sározva a vizet, az IT és a DevOps válaszadói (49% és 40%) a biztonsági csapat felelősségének tekintik a sérülékenységek telepítés előtti azonosítását.
A fejlesztői lehetőségek bővülnek, de a biztonsági szakértelem hiánya problémás.
A „balra váltás” kulcsfontosságú mozgatórugója volt annak, hogy a biztonsági felelősséget a fejlesztőre hárítsa. Ez a váltás nem volt kihívások nélkül; bár a válaszadók 68%-a kiemelten fontosnak tartja a fejlesztők engedélyezését a szervezetében, a biztonsággal kapcsolatos válaszadóknak csak 34%-a érezte magát magabiztosnak a biztonsági tesztelésért felelős fejlesztői csapatok felelősségére.
Úgy tűnik, hogy a fejlesztők által vezetett AppSec erőfeszítések legnagyobb akadályát az olyan aggályok jelentik, mint a fejlesztőcsapatok további eszközökkel és felelősségekkel való túlterhelése, az innováció és a sebesség megzavarása, valamint a biztonsági erőfeszítések felügyelete. A biztonsági és AppDev/DevOps válaszadók többsége (65% és 60%) rendelkezik olyan házirendekkel, amelyek lehetővé teszik a fejlesztők számára, hogy a biztonsági csapatokkal való interakció nélkül tesztelhessék és javítsák kódjukat, és az informatikai válaszadók 63%-a mondta azt, hogy szervezetüknek olyan szabályzatai vannak, amelyek megkövetelik a fejlesztők bevonását. biztonsági csapatok.
A szerzőről
Mike McGuire a Synopsys vezető megoldási menedzsere, ahol a nyílt forráskódú és a szoftverellátási lánc kockázatkezelésére összpontosít. Szoftvermérnöki pályafutásának megkezdése után Mike termék- és piacstratégiai szerepkörökbe lépett át, mivel szívesen érintkezik azon termékek vásárlóival és felhasználóival, amelyeken dolgozik. A szoftveriparban szerzett több éves tapasztalatát kihasználva Mike fő célja az, hogy összekapcsolja a piac összetett AppSec-problémáit a Synopsys biztonságos szoftverek létrehozására szolgáló megoldásaival.
