HUP

Nem jó ötlet aláaknázni a kódot, érdemes megnézni honnan is ered a felhasznált lib.

A különböző keretrendszerek és szabad szoftverek nagyon sok munkát megspórolnak a fejlesztés folyamán. De gyakran nem figyelünk arra, hogy honnan ered a library, csak arra, hogy funkcionalitásra tudja-e amit keresünk. Erre pedig figyelni kell, mert az utóbbi időben egyre gyakrabban használják a támadók a különböző fejlesztési eszközöket és szoftverfüggősségeket a támadó kód bejuttatására. Vinkovits Márk (Ericsson) biztonsági szakember a HWSW free! meetup-sorozat 2021. május 19-i, biztonságos szoftverfejlesztéssel foglalkozó állomásán elhangzott és alább megtekinthető előadásában röviden vázolja, melyek az alapvető higiéniás szabályok a libek kiválasztása során.

A téma iránt érdeklődők a biztonságos szoftverfejlesztés alapjaival a HWSW 2021. május 31-én kezdődő, 10 alkalmas, 30 órás gyakorlatorientált online képzésén közelebbről is megismerkedhetnek. A tanfolyam órái utólag felvételről bármikor visszanézhetők.

Egy egyszerű fejlesztői figyelmetlenségből sokszor hatalmas probléma lehet.

Rengeteg alkalmazás tartalmaz valamilyen formában PDF vagy más formátumú exportálási lehetőséget (HTML). Ezek a rendszerek a változó adatok miatt különböző template-k használatával dolgoznak, amivel kapcsolatosan kevésbé ismert IT security problémák merülnek fel az auditokon. Ilyen probléma a szerveroldali template injection.

Módly Márk biztonsági szakember a HWSW free! meetup-sorozat 2021. május 19-i, biztonságos szoftverfejlesztéssel foglalkozó állomásán elhangzott és alább megtekinthető előadásában megismerjük mit okozhat akár egy kis figyelmetlenség, és hogyan előzzük meg a fent ismertetett problémát.

Tanulnál Márktól? Az érdeklődők a biztonságos szoftverfejlesztés alapjaival a HWSW 2021. május 31-én kezdődő, 10 alkalmas, 30 órás gyakorlatorientált online képzésén közelebbről is megismerkedhetnek - Márk vezetésével. A tanfolyam órái utólag felvételről bármikor visszanézhetők.

Gémes Tamás (Aggreg8.io)

A Dockert és a Docker-compose-t sokan használják microservice rendszerek fejlesztésére, hisz gyorsan összehuzalozhatók vele a különféle előrecsomagolt, akár Docker Hubról összeollózott szolgáltatások. De mi a teendő, ha a compose-t élesben akarjuk használni? Ha több környezetünk is van, developer, QA, UAT, production környezetek is? Hogyan kezeljük a környezetek közötti különbségeket, beleértve a különféle konfigurációkat, titkos kulcsokat, volume-okat? Hogyan érjük el, hogy a rendszerünk a lehető legkisebb leállással frissíthető legyen, figyelembe véve a startup és shutdown dependenciákat is? Hogyan tudunk különféle logging drivereket használni, logokat rotálni? Hogyan monitorozzuk a konténereket? Mi a helyzet, ha egy konténerünk leáll az éjszaka közepén? Hogyan érjük el, hogy egy túlszaladt konténer ne rántsa magával az egész szervert? A fejlesztői közösségben az elmúlt években azt már sokan elfogadták, hogy a Docker és a konténerek nem csak fejlesztésre, hanem éles üzemeltetésre is alkalmas eszközök. Az előadásban azt szeretném bemutatni, hogy nem szükséges mindjárt orkesztrációs technológiában gondolkodni élesen sem (pl. Kubernetes, Swarm). A Docker-compose egy középutas megoldásként rengeteg olyan eszközt ad a kezünkbe, amellyel infrastructure-as-code filozófia mentén egy közepesen bonyolult rendszert a Kubernetes komplexitás magunkra vétele nélkül is üzemeltethetünk. Állítom mindezt úgy, hogy startupunkban mind Kubernetest, mind Docker-compose-t használunk éles környezetek üzemeltetésére több éve.