A nyílt forráskód – nem kis részben a Linuxról kialakult közvélekedés hatására is – sokak szemében a magas fokú biztonság és megbízhatóság szinonimájává vált. Pedig az open source fejlesztők sem kezelik mindig megfelelően a biztonsági kockázatokat.
Hirdetés
 
Rengeteg alkalmazásfejlesztő úgy spórol munkát magának, hogy a kódolás során felhasznál nyílt forráskódú komponensek, olykor akár többet is, a saját munkájában. Ez még nem lenne probléma, csak arról már kevesen győződnek meg, hogy a felhasznált rész vajon nem tartalmaz-e valamilyen biztonsági rést. Pedig egy komponens biztonsági rése az egész alkalmazás biztonságát veszélyeztetheti. Innen jött az ötlet a Sonatype (http://www.sonatype.com/ ) cég kutatásához: azt vizsgálták, hogy a fejlesztőcégek milyen körültekintően járnak el a nyílt forráskódú összetevők kiválasztása, felhasználása és frissítése során.

A felmérésben – melyről a Biztonságportál készített összefoglalót – 3500 fejlesztőnek és mérnöknek tettek fel kérdéseket a szoftverfejlesztési életciklus minden egyes szakaszéra vonatkozóan. Így derül fény arra, hogy a nyílt forráskódú komponensekre nem szentelnek kellő figyelmet. Ez már csak azért is aggasztó, mert rendkívül elterjedt problémáról van szó, ugyanis a Java-alapú alkalmazások 80 százaléka tartalmaz ilyen összetevőket.



Mindössze a negkérdezettek 24 százaléka dolgozik előzetesen jóváhagyott
kóddal (forrás: Sonatype, a grafikon nagyítható)

Csak tiszta forrásból? A kutatók először arra voltak kíváncsiak, hogy a megkérdezettek milyen módon biztosítják azt, hogy csak megbízható komponenseket használjanak fel a munkájuk során. Kiderült, hogy a válaszadóknak mindössze a 24 százaléka dolgozik kizárólagoson előzetesen jóváhagyott kódokkal. (Ezek olyan kódok, melyeknél bizonyítani kell, hogy tartalmaznak ismert sérülékenységet.) A válaszolók 44 százalékánál szabályozzák ugyan a kódfelhasználást, csak épp senki sem kéri számon, hogy a fejlesztők be is tartják-e. És akkor ott van a maradék 32 százalék: náluk se előírások, se különösebb megfontolások nincsenek e tekintetben, azaz a fejlesztő azt használ, amit akar.

Nem jobb a helyzet akkor sem, ha a fejlesztők alkalmazásbiztonsági kérdésekhez való egyéni hozzáállását vizsgáljuk. Pedig amúgy a válaszadók 40 százaléka állította, hogy prioritást élveznek a biztonsági kérdések, és sok időt szánnak a biztonságos alkalmazásfejlesztésre. A 29 százalékuknál azonban ez nem követelmény, ráadásul úgy is vélekednek, hogy a védelmi kérdésekért nem ők, hanem alapvetően a biztonsági csoport felel. 26 százalékuk viszont kijelentette, hogy bár tisztában van a probléma fontosságával, nincs ideje ezzel foglalkozni. A maradék 5 százalék nem is tekinti releváns szempontnak az alkalmazásbiztonságot!



Kik felelnek a nyílt forráskódú komponensek biztonságáért? 
(forrás: Sonatype, a grafikon nagyítható)


Kik mondják mindezt?
Ha csak a válaszokat nézzük, is aggasztó a kép. Ám még félelmetesebb, ha azt is megvizsgáljuk, milyen körből került ki a három és félezer megkérdezett. Negyedük jelentős, iparágában meghatározó vállalatnál dolgozik. Többek között a Netflix, a HSBC, a FedEx, a Disney, a Goldman Sachs, a Barclays, az eBay, a GE, az Alcatel-Lucent fejlesztőit kérdezték a kutatók, de olyan cégek alkalmazottai is bekerültek a mintába, mint az RSA, a Facebook vagy a LinkedIn.

A kutatás vizsgálta azt is, hogy a fejlesztőcégek miként tartják számon az általuk felhasznált szoftveres komponenseket. Az derült ki, hogy szervezeteknek mindössze a 35 százaléka vezet megfelelő letárt. Ez azért probléma, mert ha fény derül egy összetevő biztonsági résére, a cég nem tudja visszaellenőrizni, hogy bárhol is felhasználta-e az adott komponenst.

A fenti problémák ráadásul mind olyanok, melyeket viszonylag kis energiabefektetéssel orvosolni lehet. Mindenekelőtt olyan szabályokat kell kidolgozni a nyílt forráskódú komponensek használatára vonatkozóan, melyek a kiterjednek azok biztonsági, licencelési és architekturális jellemzőire is. A fejlestőket meg kell tanítani e szabályok betartásának fontosságára. Utána pedig ellenőrizni kell, hogy betartják-e az előírásokat. Végül a felhasznált komponensekről pontos leltárt kell vezetni.

Szoftverfejlesztő start-up a leggyorsabban növekvő magyar cég
Bízhatunk-e a nyílt forráskódú szoftverlicencekben?

Ez az alkalmazás figyelmeztet rá, ha valaki a közelben okosszemüveget használ

A hobbiprojektként kiadott Nearby Glasses azokat az egyedi azonosítókat keresi, amelyeket a minősített Bluetooth-termékekhez rendelnek.
 
Hirdetés

Produktivitás mint stratégiai előny: mit csinálnak másként a sikeres cégek?

A META-INF által szervezett Productivity Day 2026 idén a mesterséges intelligencia és a vállalati produktivitás kapcsolatát helyezi fókuszba. Az esemény középpontjában a META-INF nagyszabású produktivitási kutatásának bemutatása áll, amely átfogó képet nyújt a magyar vállalatok hatékonyságáról és működési kihívásairól.

Vezetői példamutatás és megfelelő oktatás, vállalatikultúra-váltás nélkül gyakorlatilag lehetetlen adatvezérelt működést bevezetni. Cikkünk nemcsak a buktatókról, hanem azok elkerülésének módjairól is szól.

EGY NAPBA SŰRÍTÜNK MINDENT, AMIT MA EGY PROJEKTMENEDZSERNEK TUDNIA KELL!

Ütős esettanulmányok AI-ról, agilitásról, csapattopológiáról. Folyamatos programok három teremben és egy közösségi térben: exkluzív információk, előadások, interaktív workshopok, networking, tapasztalatcsere.

2026.03.10. UP Rendezvénytér

RÉSZLETEK »

A Corvinus Egyetem és a Complexity Science Hub kutatói megmérték: a Python kódok közel harmadát ma már mesterséges intelligencia írja, és ebből a szenior fejlesztők profitálnak.

Rengeteg ország áll át helyi MI-platformra

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2026 Bitport.hu Média Kft. Minden jog fenntartva.