🔐 Tudatos kódolás és biztonsági kultúra – tanulságok a Hack és Lángos 387–388. epizódjaiból

A Hack és Lángos podcast régóta a kedvencem, ezért úgy döntöttem, hogy mostantól rendszeresen beszámolok az adások legérdekesebb témáiról, tanulságairól és megmosolyogtató pillanatairól.

Az alábbi cikkben két egymást követő részt foglalok össze, amelyek bár különböző aspektusból közelítik meg az IT-biztonság kérdését, mégis remekül kiegészítik egymást.

I. Secure coding – amikor a kód nem csak fut, de véd is (HnL387)

🧑‍💻 Fejlesztők a mikrofon mögött

A 387-es adás vendégei Dev és Helm, két fejlesztő, akik nem csak a napi munkájukban, de most a podcastban is programkódokról, architektúrákról és biztonságról beszéltek. Helm neve egyébként a Gyűrűk Ura „Helms Deep” helyszínéből ered, amit a többiek nem ismertek – „NEM kultúrlények vagytok!” – jegyezte meg Antenna tréfásan.

🔐 Miért nem beszélünk eleget a biztonságos kódolásról?

Dev szerint sokszor teljesen hiányzik a secure coding kultúrája:

„Én lennék a legboldogabb, ha lenne szó róla, de nincs.”

A problémák gyökere mélyen gyökerezik a fejlesztői mentalitásban: a cél az, hogy „készüljön el”, nem pedig az, hogy jól vagy biztonságosan.

🏗️ Architektúra vs. YouTube-tutorial

Helm rámutatott, hogy a fejlesztők gyakran YouTube-videókból és Medium-cikkekből építik fel tudásukat, ahol a biztonság nem elsődleges szempont. Az egyik konkrét példája:

„JWT tokeneket nyakra-főre használnak anélkül, hogy értenék, hogyan működik.”

Ez különösen veszélyes lehet, ha saját autentikációs rendszert írnak – főleg production környezetbe. A beszélgetés során abban is egyetértenek, hogy a cégek csak akkor költenek biztonságra, ha már megtörtént a baj.

🛠️ Eszközök és gyakorlatok – mit lehetne jobban csinálni?

Helm kiemelte a GitHub dependency-értesítéseit és a Daily.Dev feedeket, míg Dev a SonarQube-ot említette, mint automatizált biztonsági ellenőrzőt. Ugyanakkor elismerte:

„A Sonar néha olyan hibát jelez, amit ha kijavítunk, rosszabb lesz a végeredmény.”

Egy másik érdekes gondolat a cloud szolgáltatások „shared responsibility” modellje volt: a keretrendszer biztonsága a szolgáltatóé, a konfiguráció viszont a fejlesztő felelőssége.

II. Awareness vagy zavarness? – Amikor a kampány kicsit túltol (HnL388)

🎣 Túl jó a phishing?

A 388-as rész könnyedebb, ám annál tanulságosabb: Béla, Z és Antenna boncolgatták az IT-biztonsági awareness kampányok hatékonyságát és morális határait.

Béla említ egy korábbi kampányt, ahol egy kamu „refurbished iPhone” nyereményjátékkal csalták csapdába a dolgozókat:

„Mocskos szemét dolog volt, de működött.”

A cél persze nem a megtévesztés öncélúan, hanem a figyelemfelkeltés – ugyanakkor a HR osztály nem mindig értékeli az ilyen kreatív ötleteket.

⚖️ Meddig mehet el az awareness?

Z etikai aggályokat vet fel: a támadóknak nincs etikai korlátjuk, de egy vállalatnak igenis van – például nem küldhet olyan e-mailt, amiben Ukrajnának való segítségnyújtással próbálkozik. Ez HR- vagy PR-katasztrófába is torkollhat.

A kampányokban felhasznált sablonok is rizikósak: egy Microsoft platform sablonja miatt több száz telefon érkezett egy valódi jegyirodába – hiszen az e-mail a valódi logójukat és címüket használta.

😵‍💫 Kattintók és következmények

Felmerül a kérdés: kell-e és lehet-e „áldozathibáztatni”? A visszaeső „kattintókat” egyes cégeknél külön oktatásra hívják be, de a beszélgetés során világossá válik, hogy a túl sok kötelező tréning is kontraproduktív lehet.

„Az emberek agyfaszt kapnak a sok tréningtől.”

Z szerint a tréningeket pozíció és tudásszint szerint kellene szegmentálni, hogy ne mindenki ugyanazt kapja. A szenior fejlesztők gyakran túl „basicnek” érzik az oktatásokat, és nem is veszik komolyan.

🧠 Félelem alapú tanulás?

Béla elmeséli, hogy egy cégnél elkezdték mérni a visszatérő kattintókat, és beszélgetést kezdeményeztek velük – ezt ő „félelem alapú tanulásnak” nevezi, de hozzátette:

„Ez csak egy bizonyos csapatméretig működik.”

Antenna saját tapasztalata: egyszer összecsukta egy nyitva hagyott laptop képernyőjét, amit a portára vitt. Az ügy akkora port kavart, hogy egészen a CSO-ig jutott. A régi „poénok” – mint például eldugni a nem lekensingtonozott laptopot – szintén fegyelmezési célt szolgáltak, de ma már kérdéses, meddig lehet ezekkel elmenni.

🧩 Két rész – egy tanulság

A két epizód egymást kiegészítve mutatja be a fejlesztői oldal és az IT-biztonsági oktatás kihívásait. A secure codingról gyakran megfeledkezünk a projektleadás nyomása alatt, miközben az awareness kampányok hatása gyakran elvész a túlzott egyszerűsítés vagy a túltolt „kreativitás” miatt.

Végső soron a megoldás valahol félúton van: strukturált, tudásszintre szabott képzésekben, ahol a fejlesztők megértik a biztonság alapjait, a felhasználók pedig megtanulnak kritikusan kattintani – és nem csak reflexből.