Szoftverellátási lánc biztonsági irányelvei fejlesztőknek

Legyen szó csomageltérítésről, függőségi zavarról, gépelési hibákról, folyamatos integrációról és folyamatos kézbesítésről (CI/CD) vagy az örökölt függőségek alapvető webes kihasználásáról, a szoftverellátási láncot számos támadás érheti a rosszindulatú felek, hogy leszámolják áldozataikat. és tartsa őket váltságdíj követeléséért. és a kritikus adatok kiszűrése.

Gyakran hatékonyabb a lánc gyenge láncszemének megtámadása egy nagyobb cél elérése érdekében, mint amilyen az elmúlt években a Kaseya vagy a SolarWinds esetében történt. A támadók beültethetnek egy RCE-t (Remote Code Execution), vagy fejlesztői hitelesítési adatokat gyűjthetnek a jogosultságok kiterjesztéséhez és rejtett rosszindulatú műveletek végrehajtásához.

Ezenkívül előfordulhat, hogy csak egy csomagot kell feltörniük ahhoz, hogy a rosszindulatú programokat nagyszámú felhasználóhoz és szervezethez terjeszthessék, mivel a mai ellátási lánc őrülten összetett és összekapcsolt.

Természetesen a fejlesztők nem tehetők felelőssé minden sebezhetőségért, de általában privilegizált fiókokkal rendelkeznek, sőt közvetlen hozzáférésük is van az érzékeny dokumentumokhoz és csövekhez, így egyre vonzóbb célpontok.

Az Egyesült Államok Nemzetbiztonsági Ügynöksége (NSA), a Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökség (CISA) és a Nemzeti Hírszerzési Igazgatói Hivatal (ODNI) a közelmúltban átfogó útmutatót adott ki a fejlesztőknek az ellátási lánc feltörései elleni védelem érdekében kódjukat és folyamataikat.

Lásd a A legjobb hibakereső és kódvédelmi eszközök

A rosszindulatú kódok befecskendezésének leállítása

Az útmutató szerint a fenyegetések szereplői továbbra is használják a sebezhetőségek nyilvános közzétételét, de ahelyett, hogy megvárnák, „proaktívan rosszindulatú kódokat juttatnak be a termékekbe, amelyeket azután legitim módon terjesztenek a globális ellátási láncon keresztül”.

A fejlesztőcsapatok gyakran küszködnek a frissítésekkel és az időigényes DevOp-okkal (fejlesztés és műveletek), ezért automatizálják a CI/CD folyamatokat az automatizált telepítésekhez és teszteléshez, de a folyamatot néha rosszul konfigurálják, és gyakran hiányoznak a biztonsági ellenőrzések.

Egy másik népszerű technika magában foglalhatja egy olyan csomag veszélyeztetését, amelyet csak a fejlesztők használnak (például a devDependencies a Node-ban) a hitelesítő adataik, például az AWS-kulcsok összegyűjtésére.

Az új amerikai útmutatás azonosítja a gyakori fenyegetési forgatókönyveket a szoftver életciklusa során:

  1. Egy rosszindulatú személy szándékosan rosszindulatú kódot fecskendez be, vagy a fejlesztő véletlenül sebezhető kódot épít be a termékbe.
  2. A harmadik féltől származó sebezhető forráskód vagy bináris fájlok tudatosan vagy tudatlanul beépülnek a termékbe.
  3. Az összeállítási folyamat gyengeségeit kihasználva rosszindulatú szoftvereket juttatnak be a termék egy részébe.
  4. A szállítási mechanizmuson belüli termék módosul, ami rosszindulatú szoftverek bejuttatását eredményezi az eredeti csomagba, frissítésbe vagy frissítési csomagba, amelyet az ügyfél implementált.

A dokumentum konkrét intézkedéseket sorol fel a kockázat csökkentésére:

  • Építészeti és tervezési dokumentumokat generál.
  • Állítson össze egy képzett, képzett és megbízható fejlesztőcsapatot.
  • Hozzon létre fenyegetési modelleket a szoftvertermékhez.
  • Biztonsági teszttervek kidolgozása és végrehajtása.
  • Határozza meg a kibocsátási kritériumokat, és ennek megfelelően értékelje a terméket.
  • Szabályzatok és eljárások létrehozása a terméktámogatás és a sebezhetőségek kezelésére.
  • Mérje fel a fejlesztők képességeit és a biztonságos fejlesztési folyamat megértését, és rendeljen hozzá képzést.
  • Minden szoftverkiadáshoz dokumentálja és tegye közzé a biztonsági eljárásokat és folyamatokat.

A kód biztonságossá tétele

A biztonságos kód írása olyan eljárásokat tartalmaz, mint a kódellenőrzés és a biztonsági tesztelés, függetlenül a programozási nyelvtől, még akkor is, ha ezek közül néhány, például a Rust és a C, alapértelmezés szerint a biztonságot részesíti előnyben.

Az útmutató kiemeli a rosszindulatú kód szándékos és nem szándékos befecskendezésének gyakoriságát a támadások során.

A mérnökök és a fejlesztők veszélybe kerülhetnek olyan ártalmatlannak tűnő helyzetekben, mint például az elégedetlenség vagy külső befolyás. A képzettség hiánya megmagyarázhatja a bosszantó tervezési hibákat is, amelyeket meglehetősen nehéz észlelni, és nulladik napi támadásokhoz vezethetnek, amelyek hónapokig nem javíthatók.

Ezenkívül a programozók szeretnek speciális paramétereket és egyéb hibakereső funkciókat megvalósítani a hibaelhárítás vagy a telepítés megkönnyítése érdekében. Sajnos nem ritka, hogy ezeket a “hackeket” kényelmi okokból gyártásba állítják, vagy valaki egyszerűen elfelejti eltávolítani őket használat után.

Az útmutató felkéri a technikai csapatokat, hogy alkalmazzák a következő kockázatcsökkentéseket:

  • Valósítson meg egy kiegyensúlyozott bejelentkezési folyamatot az ellenőrzött forráskódhoz, például a GIT-tárolókkal és a többtényezős hitelesítéssel (MFA) kapcsolatos bevált gyakorlatokat.
  • Futtasson automatikus statikus és dinamikus vizsgálatokat a biztonsági/sebezhetőségek keresésére.
  • Futtasson éjszakai buildeket biztonsági és regressziós teszteléssel.
  • Rendeljen funkciókat olyan követelményekhez, mint például a fejlesztői csomagok korlátozása és a nem használt függőségek eltávolítása.
  • Részesítse előnyben a kódellenőrzéseket és tekintse át a kritikus kódot.
  • Biztonságos szoftverfejlesztési/programozási képzés végrehajtása.
  • Erősítse meg a fejlesztői környezetet olyan módszerekkel, mint a VPN, az MFA, a „jump-host” és a fenyegetésmodellezés az egyes környezetekhez.

Hogyan javítható az építési folyamat

Akár az egyéni fejlesztő, akár az éles környezet esetében, ajánlatos ellenőrizni a szoftver biztonságát, mielőtt azt leszállítaná és eljuttatná a végfelhasználókhoz. A csapatok különböző eszközöket és technikákat használhatnak. Például:

  • Végezzen közvetett ellenőrzéseket, például sebezhetőségi vizsgálatot, tolltesztet, vízjelet, adatvesztés-megelőzést (DLP) és integritás-ellenőrzést.
  • SBOM-ok (Software Bill of Materials) és digitális aláírások a szállítások érvényesítéséhez
  • Gyors iteratív ciklusok (agilis fejlesztés)
  • Hozzáférés az összes csővezetékhez
  • Titkosítás
  • A legkisebb kiváltság elve
  • Hálózati szétválasztás
  • Helyszíni megvalósítás
  • Verzióvezérlés
  • A/B tesztelés CI/CD csővezetékekben

Verziókezelés bevált gyakorlatai

A dokumentum útmutatást ad a forráskód védelméhez.

Először is, a hozzáférés és az érvényesítés a jó forráskód-kezelési (SCM) elvekkel kezdődik a forráskód-tárhely változásainak nyomon követésére.

A fejlesztőcsapatoknak azt is lehetővé kell tenniük, hogy értesítéseket kapjanak, ha új fenyegetést, verziót vagy frissítést találnak. A főbb kiadási platformok, például a GitLab vagy a GitHub kínálnak ilyen funkciókat, de az útmutató azt javasolja, hogy haladjon tovább, és „vezessen naplót minden fejlesztőről és az általuk letöltött összetevőkről”.

Az MFA-t „minden hozzáféréshez” engedélyezni kell a tárhelyhez, és a csapatok az alapvető Git-ágakat használhatják a dolgok rendszerezésére:

  • A fejlesztők a fejlesztőiparban dolgoznak.
  • A kód áttekintése és jóváhagyása után a szoftvert minőségbiztosítási (QA) osztályra vezeti.
  • A minőségbiztosítási csapatok tesztelik a minőségbiztosítási ág szoftverét.
  • Jóváhagyás esetén az ágazat beolvadható a termelésbe.

Az útmutató azt javasolja, hogy korlátozza az éles ághoz való hozzáférést “kis számú build- és csapattagra”, és minden egyes kiadás után hajtson végre zárolási eljárásokat a buildek biztonsága érdekében.

A fejlesztőknek kötelezettségvállalásokat is alá kell írniuk. A kézikönyvben nincs kifejezetten említve, de egyes támadások lopott kulcsokra támaszkodnak a commitok leküldéséhez. Ebben az esetben a jogosulatlan módosítások jogos felhasználóhoz tartoznak.

Nem ritka, hogy a fejlesztők ideiglenes kulcsokat használnak a környezetek beállításához. Ha használat után nem törlik a kulcsokat, a támadó a szerver elérése után megtalálhatja azokat.

Egy másik támadás lehet egy törvényes rendszergazda személyazonosságának meghamisítása egy hamis csomag létrehozásával és a Git konfigurálásával a rendszergazda információival (pl. typosquatting).

A fejlesztők aláírhatják a kötelezettségvállalásokat GPG (Gnu Privacy Guard) kulcsokkal vagy olyan könyvtárakkal, mint a Gitsign. Nem golyóálló, de ez az extra biztonsági réteg viszonylag könnyen beállítható.

Olvassa el a következőt: A legfontosabb sebezhetőség-kezelő eszközök

Leave a Comment

%d bloggers like this: