Biztonságos szoftverfejlesztés: hol kezdje

A biztonság beépítése a fejlesztésbe akkor működik, ha nem lassítja a csapatot. Ha minden commitnál tíz percet vár egy szkennerre, amiből kilenc téves riasztás, akkor a folyamat két hét múlva ki lesz kapcsolva.

Ez a cikk arról szól, mi az, ami valóban véd, és mi az, ami csak zaj.

1. Titkok kiszűrése a kódból

Ez a legfontosabb egyetlen lépés. Az API-kulcs, adatbázis-jelszó vagy tanúsítvány, ami bekerül a verziókezelőbe, örökre ott marad a történetben, és minden fejlesztő gépén megvan.

Amit tenni kell: commit előtti ellenőrzés (pre-commit hook) és a repository teljes történetének átvizsgálása. Ha találat van, a titkot nemcsak törölni kell, hanem cserélni is, mert a törlés a történetből nem tünteti el.

2. Függőség-vizsgálat automatizálva

A kód nagy része idegen. Az automatizált vizsgálat a build része legyen, és a KEV-listás vagy magas EPSS-értékű találat állítsa meg a buildet, a többi csak jelezzen. Erről a szoftverfüggőségekről szóló cikkünkben írtunk.

3. Statikus elemzés, de szűken

A SAST könnyen elárasztja a csapatot. Kezdje néhány magas bizonyosságú szabállyal (injektálás, hardcode-olt titok, ismert veszélyes függvény), és csak akkor bővítse, ha a téves riasztások aránya alacsony marad.

A kulcs: ami megállítja a buildet, annak igaznak kell lennie. Egy hamis blokkolás után a csapat bizalma elvész.

4. Kód-átnézés biztonsági szemmel

Nem külön folyamat, hanem a meglévő átnézés kiegészítése néhány kérdéssel:

• Van-e jogosultsági ellenőrzés minden erőforrás-hozzáférésnél?
• Kerül-e felhasználói bemenet lekérdezésbe, parancsba vagy sablonba?
• A hibaüzenet ad-e ki belső információt?
• Naplózza-e a művelet a szükséges adatot, és nem naplóz-e titkot?

Négy kérdés, és a valós hibák nagy részét lefedi.

5. Titkok kezelése futásidőben

A titkot nem a konfigurációs fájlba kell tenni, hanem titok-kezelőből kiolvasni futásidőben. Így nincs a repóban, nincs az image-ben, és rotálható a kód módosítása nélkül.

Amit ne vezessen be azonnal

Teljes körű SAST minden szabállyal. Több ezer találatot ad, aminek a nagy része nem releváns. A csapat megtanulja figyelmen kívül hagyni, és onnantól a valódi találat is elveszik.

Kötelező biztonsági jóváhagyás minden kiadáshoz. Szűk keresztmetszetet hoz létre, és a csapat megkerüli. A kockázatarányos megközelítés jobb: csak a nagyobb változásoknál.

DAST minden buildnél. Lassú, és a futó környezetet igényli. Heti vagy kiadás előtti futtatás elég.

Amit érdemes még

Fenyegetésmodellezés a tervezésnél. Egy óra beszélgetés arról, ki mit támadhatna meg egy új funkcióban, olcsóbb, mint bármilyen későbbi javítás.

Biztonsági alapkonfiguráció a környezetekhez. A fejlesztői, teszt és éles környezet ugyanazokkal a biztonsági beállításokkal. A leggyakoribb rés, hogy a teszt környezet éles adatot tartalmaz, gyengébb védelemmel.

Anonimizált tesztadat. Az éles adatbázis másolata a fejlesztői környezetben az egyik leggyakoribb adatvédelmi hiba.

Mit mérjen

• Hány titok van a repository történetében
• Hány nyitott, KEV-listás komponens-sérülékenység
• Átlagos idő a sérülékenység jelzésétől a javításig
• A build-blokkoló szabályok téves riasztási aránya

Az IT biztonsági szolgáltatásaink között a fejlesztési folyamat biztonsági felülvizsgálata is szerepel.