2022: a biztonságos szoftverfejlesztés kit érdekel?

HUP

Legyünk őszinték magunkkal és a felhasználóinkkal: a szoftveripar jelenlegi struktúrája mellett a biztonságos szoftverfejlesztés reménytelen ügy. Sajnos ez ma még nagyobb gondot jelent, mint tíz évvel ezelőtt, de ahhoz, hogy mindez megváltozzon, számtalan drasztikus változásnak kellene bekövetkeznie a szoftveriparban. Előadásomban ezekre fogom felhívni a figyelmet.

(Pfeiffer Szilárd (Balasys) előadása az IC Enterprise Technologies meetup-sorozat 2022. június 28-i, DevSecOps tematikájú állomásán hangzott el.)

( ricsip v | 2022. 07. 20., sze – 15:01 )

Szerkesztve: 2022. 07. 20., sze – 16:14

Senkit nem érdekel a biztonságos szoftverfejlesztés, ha az pénzbe kerül. Majd ha meghekkelik a cuccunkat, gyorsan kiadunk rá 1 javítást, meg egy sablonszöveg nyilatkozatot. Aztán a következő nyilvános megszégyenülésig szarunk megint az egészre. Az internet népe gyorsan felejt amúgyis.

Autógyártókkal az élen: minden héten látok 1 újabb ilyen kaliberű balfaszságot:
https://youtu.be/tqln99BHUzU

Azért nem érdekel senkit, mert nem adható el drágábban a biztonságosabb szolgáltatás, mint a lyukas, mert a userek is leszarják az egészet. Papírra írt jelszavak, stb. Senkit nem érdekel a biztonság. Emiatt aztán senki nem fizeti meg, emiatt aztán minek csinálni? Nem térül meg.

( YleGreg | 2022. 07. 20., sze – 16:06 )

Az elet egyre tobb teruleten latok peldakat az elore menekulesre. A bizonytalansag csak tovabbi bizonytalansagokat szul. Uszunk az arral. Bakker, atmentem Coelhoba, elnezest, gyorsan abbafejezem magam es iszom egy kavet. Es leellenorzom az utolso fuggvenyt amit irtam, ki tudja miota vagyok ebben a tudatallapotban, mi kovettem el ez ido alatt. :-)

( sz332 v | 2022. 07. 20., sze – 22:08 )

Szerkesztve: 2022. 07. 20., sze – 22:13

Amit it elmond a srác, az a kommerciális, nem biztonságkritikus szoftverfejlesztésre igaz, valójában biztonságos szoftvert nem így építünk. Security by design, nem pedig azt nézegetjük, hogy hány sor egy függvény, aztán onnan próbálunk reszelgetni. 

( Chain-Q v | 2022. 07. 21., cs – 08:56 )

Szerkesztve: 2022. 07. 21., cs – 09:00

Nálunk most kitalálták, hogy úgy fogják növelni a kódbiztonságot, hogy mielőtt bármilyen változtatás production deployba mehet, JIRA ticketnek kell róla lenni (ha egy commit v. PR több issue-t fixel, akkor mindegyikről egyesével külön ticket), ahova azt is le kell írni hogy ez a változtatás milyen business requirement és előny része - hiszen minden új változtatás új security issue lehetősége is egyben, ami csak akkor éri meg ha van business értéke - ÉS ezt a security review-elni fogja egyesével. A ticketeket és a hozzá tartozó kódokat is, full vétó joggal. És ezt így elfogadták és kész kuss, odafentről és anyacégtől is jóváhagyva, mostantól ez van, punktum.

Száz nyolcvan fejlesztőnk van. Kb. négyszáz különböző git repo. KETTŐ security-s van (amiből az egyik a security góré, aki nyilván nem fog ilyesmit csinálni). Fasza lesz. :)

A security szakmai szintjéről meg mellesleg annyit, hogy minap kiverték a hisztit, hogy nginx 1.14-et futtatunk, ami már EoL, szóval MOST AZONNAL UPGRADE!!!!. Na itt jött a fél órás szájbarágás a "hogy működik egy Linux distró (Ubuntu 18.04), és mi az a security patching ami a disztró vendor végez, stb. " témában. Utána volt hümmögés, fejvakarás, extra meeting, végül az volt a megoldás, hogy "ja, hát akkor kapcsoljátok ki a verzió megjelenítést (server_tokens off - szerk.) a response fejlécben amit a sechole-scannerünk használ, és akkor nem sípol rá, hogy régi a szerver, mert nem tud róla"...

Szóval kikapcsoltam. Amúgy sem kellett volna bekapcsolva lennie, szvsz, szóval fair enough. És azóta SEKURITI STONKS.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A security policynek való megfelelés nem feltétlenül jelent biztonságos szoftvert. Ugyanúgy, ahogy az ISO 9001-es plecsni sem jelent magas minőségű terméket, csak szabályozott módon előálló terméket.

Ez az egész általában a felelősségek megfelelő elhárításáról szól, hogy aki megfelel a policynek, az mondhassa, hogy onnantól kezdve nem az ő felelőssége, ha baj van, és meg lehessen találni a szabályzat alapján azt, hogy kinek a felelőssége.

Ettől még nem lesz biztonságosabb a szofver/jobb minőségű a  termék, de egy minőségbiztosítás elmaradása miatti perben könnyebb megtalálni a felelőst. Erről szól ez az egész.

Olcsóbb a néha felmerülő perben kifizetni a büntetést, mint a valódi biztonságot. Főleg úgy, hogy a szoftverek fejlesztői semmilyen garanciát nem vállalnak, csak akkor, ha jogszabályban van róla előírás. Nagyon szűk köre a szoftvereknek az, amire van ilyen jogszabályi előírás.

Nem tud a szakma jó része szoftvert írni, tesztelni meg pláne.

Tesztelni ráadásul nem is szeret.

Ahol hajlandóak beletenni a pénzt és az időt a tesztelésbe ott azért lehet valamiféle közel állandó minőséget biztosítani. Nincsen garancia a hibamentességre csak arra hogy ugyanazt a hibát kétszer nem követjük el.

zászló, zászló, szív

Én imádok bugfixelni, és jobb is vagyok benne, mintha bármit nulláról kell megírni. De miközben én azt gondolom, hogy azokon a napokon vagyok legproduktívabb, amikor többszáz sort kihányok a forráskódnak csúfolt trutymóból, és ettől féltucat bug megjavul és húszszorosára gyorsul az egész, a management sokszor ezt nem érzékeli, mert más fejlesztőktől meg az a feedback hogy nem akarják az ilyesmit, és ne nyúljak a SZENT kódhoz, amit ők írtak. Többnyire mert az általam írt résszel ugyanaz lenne a bajuk mint a sajátjukkal lenne, csak 6 hónappal később: kód olvasás és értelmezés nem megy, emiatt úgyis csak mindent újraírnak végül. Óvoda. Ezzel összefüggésben szintén rendszeres a "hozzányúltál innentől a te bajod", meg a "nem értjük mit csinálnak a változtatásaid, szóval inkább újraírtuk" (értsd: visszarakták a többszáz kőfelesleges sort, csak más sorrendben) problémakör.

Szóval nem elég, hogy a szakma nem szeret bugokat fixelni még azokat is kinézi és kiveti magából, akik szeretnek. Aztán meg csodálkozunk, hogy minden szar.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Aztán a szekuritis melója abban fog kimerülni, hogy tiketeket nyitogat meg zárogat le. Emiatt az az ember aki valóban értett a szekuritihez, fel is áll majd 6 hónao múlva és átmegy oda ahol hagyják a valódi munkaját végezni. Ezután már olyan ember lesz felvéve, aki eleve csak tiketeléshez ért, szekuritihez meg nem.