DevSecOps aktuális helyzete
A DevSecOps lényege, hogy a biztonsági kockázatokat a szoftverfejlesztési életciklus (SDLC) minden egyes szakaszában azonosítani kell, és reagálni kell rájuk. A Datadog elemzői több tízezer alkalmazást és konténer image-et elemeztek több ezer felhőkörnyezetben, annak érdekében, hogy felmérjék, milyen típusú kockázatokkal kell tisztában lenniük a kiberbiztonsági szakembereknek, és milyen gyakorlatokat alkalmazhatnak a biztonsági helyzetük javítása érdekében.
A Datadog eredményei azt mutatják, hogy a webes alkalmazásokat számos kockázat érinti, beleértve az ismert, kihasználható sérülékenységeket, az ellátási láncot érő támadásokat és a CI/CD-ben a nem biztonságos identitáskonfigurációkat. Az olyan üzemeltetési legjobb gyakorlatok, mint a kisebb konténer image-ek választása, az infrastruktúra mint kód (IaC) használata és a szolgáltatások gyakori telepítése általában csökkentik az alkalmazások kockázati kitettségét, és erős alapot nyújtanak a biztonságos SDLC-hez.
A kihasználható sérülékenységek elterjedtek a webes alkalmazásokban, különösen azokban, amelyek Java-t használnak
A Datadog azt találta, hogy a szolgáltatások 15 százalékát érintik ismert sérülékenységek a szervezetek 30 százalékánál. A sérülékenységek különösen elterjedtek a Java-alapú szolgáltatások körében, amelyek 44 százaléka tartalmaz ismert, kihasználható sérülékenységet. A következő legmagasabb a Go 5 százalékkal, az összes nem Java-szolgáltatás átlaga pedig 2 százalék.
A kiberszereplők továbbra is a szoftverellátási láncot veszik célba
A kiberszereplők amellett, hogy a webes alkalmazásokat ismert sebezhetőségek után kutatják, a fejlesztőket is gyakran megpróbálják rávenni arra, hogy töltsenek le és telepítsenek rosszindulatú csomagokat nyílt forráskódú könyvtárakból. A Datadog 2024-ben több ezer rosszindulatú PyPI és npm-könyvtárat azonosított. A csomagok némelyike typosquatting technikát alkalmazott, azaz megpróbált egy legitim csomagot utánozni (például a passports-js, amely a legitim passport könyvtárat utánozta).
A hosszú élettartamú hitelesítő adatok használata a CI/CD-pipeline-okban még mindig túl magas
A sérülékeny kódok és a rosszindulatú nyílt forráskódú csomagok mellett a hosszú élettartamú, nem lejáró hitelesítő adatok használata a felhőbiztonsági incidensek gyakori oka. A hosszú élettartamú hitelesítő adatok használata a CI/CD-pipeline-okban különösen kockázatos lehet, mivel a hozzájuk tartozó jogosultságok gyakran privilegizáltak.
A kritikus sérülékenységek priorizálása
A könyvtárak sérülékenységek, a rosszindulatú nyílt forráskódú csomagok, a hibás IAM konfigurációk és egyéb problémák nagy gyakorisága zajos környezetet teremt a védők számára. Ebben az összefüggésben a biztonsági csapatoknak meg kell érteniük, hogyan kell rangsorolniuk a biztonsági hibákat, és meg kell határozniuk, melyeket kell először orvosolniuk. Ezek a döntések gyakran a sérülékenység súlyossága alapján történnek meg – jellemzően a CVSS alapján. A Datadog megállapította, hogy egy átlagos szolgáltatás 13,5 magas vagy kritikus sérülékenységgel rendelkezik, szemben a 2024-es 11,9-es pontszámmal. A sérülékenységek súlyossága mellett viszont elengedhetetlen a megfelelő futási kontextus – például, hogy a sérülékenység érint-e termelési környezetet, vagy hogy az alkalmazás elérhető-e az internet felő – mivel a CVSS ezeket nem veszi figyelembe.
A könyvtárak naprakészen tartása komoly kihívást jelent a fejlesztők számára
A Datadog jelentése szerint a függőségek 215 nappal (medián) vannak elmaradva a legutóbbi főverzióhoz képest. Az elavult könyvtárak növelhetik annak valószínűségét, hogy egy függőség javítatlan, kihasználható sérülékenységet tartalmaz. A JVM függőségek esetében ez a medián 401 nap, a Go esetében pedig 168 nap.
A kisebb konténer image-ek javítják a biztonsági helyzetet
Az elmúlt években a mérnöki csapatok a minimális méretű konténer image-ek bevezetése felé mozdultak el, hogy javítsák rendszereik hatékonyságát. Ez a trend az olyan disztribúciókkal kezdődött, mint az Alpine Linux, és még kisebb disztribúció nélküli és from-scratch image-ek felé fejlődött, amelyek mindegyike drasztikusan csökkenti a konténerkép méretét. Például a python:3.11 alapértelmezett Docker image-e több mint 1 GB, míg a python:3.11-alpine minimális verziója 58 MB, ami 95 százalékkal kisebb. Ez a „kevesebb több” megközelítés a biztonság szempontjából is előnyös. Több ezer konténerkép elemzése alapján a Datadog azt találta, hogy egy 100 MB-nál kisebb méretű konténerkép átlagosan három magas vagy kritikus sérülékenységet tartalmaz, míg egy 500 MB-nál nagyobb méretű konténerkép átlagosan 20 ilyen sérülékenységet.
Az AWS-ben az IaC használata magas, de sok csapat még mindig a ClickOps-ot is használja
Az infrastructure-as-code (IaC) azért vált uralkodó gyakorlattá a felhőkörnyezetekben, mert általában jobb működési eredményekhez vezet, például jobb verzióellenőrzéshez és nyomon követhetőséghez. Emellett az IaC a legjobb biztonsági gyakorlatok kulcsfontosságú eleme, mivel segíti a szakértői felülvizsgálat érvényesítését, és megkönnyíti az infrastruktúra átvizsgálását a hibás konfigurációk azonosítása érdekében. Az AWS-en a szervezetek 59 százaléka használja a Terraformot, és 57 százalékuk a CloudFormationt. Összességében a szervezetek 80 százaléka használ legalább egy IaC-eszközt.
