Ajánlott eljárások a biztonságos szoftverellátási lánchoz

A nyílt forráskód mindenhol megtalálható. Számos védett kódbázisban és közösségi projektben található. A szervezetek és magánszemélyek számára ma nem az a kérdés, hogy nyílt forráskódú kódot használ-e vagy sem, hanem azt, hogy milyen nyílt forráskódú kódot használ, és mennyit.

Ha nem tudja, hogy mi található a szoftverellátási láncban, az egyik függőség felsőbb rétegbeli biztonsági rése végzetes lehet, így Ön és ügyfelei ki vannak téve egy esetleges kompromisszumnak. Ebben a dokumentumban részletesebben is bemutatjuk, mit jelent a "szoftverellátási lánc" kifejezés, miért fontos, és hogyan segíthet a projekt ellátási láncának biztonságossá tételében az ajánlott eljárásokkal.

Függőségek

A szoftverellátási lánc kifejezés arra szolgál, hogy mindenre hivatkozzon, amely a szoftverbe kerül, és ahonnan származik. A szoftverellátási lánc függőségeitől és tulajdonságaitól függ. A függőség az, amire a szoftver működéséhez szükség van. Lehet kód, bináris fájl vagy más összetevő, és honnan származnak, például adattár vagy csomagkezelő.

Ide tartozik, hogy ki írta a kódot, mikor járultak hozzá, hogyan ellenőrizték a biztonsági problémákat, ismert sebezhetőségek, támogatott verziók, licencinformációk, és szinte minden, ami bármely szakaszban érinti.

Az ellátási lánc a verem más részeit is magában foglalja egy alkalmazáson túlmutatva, például az építési és csomagolási szkripteket, vagy a szoftvert, amely az alkalmazás által igénybe vett infrastruktúrát működteti.

Sebezhetőség

Napjainkban a szoftverfüggőségek áthatóak. Gyakran előfordul, hogy a projektek több száz nyílt forráskódú függőséget használnak olyan funkciókhoz, amelyeket nem kellett saját magának írnia. Ez azt jelentheti, hogy az alkalmazás nagy része olyan kódból áll, amelyet nem ön készített.

A külső vagy nyílt forráskódú függőségek lehetséges biztonsági rései feltehetően olyan függőségek, amelyeket nem lehet olyan szigorúan szabályozni, mint az ön által írt kód, ami potenciális biztonsági kockázatokat okozhat az ellátási láncban.

Ha ezek közül a függőségek közül az egyik rendelkezik biztonsági réssel, akkor valószínű, hogy ön is rendelkezik biztonsági réssel. Ez ijesztő lehet, mivel az egyik függősége megváltozhat anélkül, hogy tudná. Még akkor is, ha egy sebezhetőség már létezik egy függőségben, de nem hasznosítható, a jövőben is kihasználható.

Annak lehetősége, hogy kihasználjuk a nyílt forráskódú fejlesztők és könyvtárírók ezreinek munkáját, azt jelenti, hogy idegenek ezrei hatékonyan hozzájárulhatnak közvetlenül a produkciós kódodhoz. A termékre a szoftverellátási láncon keresztül nem javított biztonsági rések, ártatlan hibák vagy akár függőségek elleni rosszindulatú támadások is hatással lesznek.

Az ellátási lánc sérülései

Az ellátási lánc hagyományos meghatározása a gyártásból származik; ez a folyamatlánc, amely szükséges ahhoz, hogy valamit készítsünk és szállítsunk. Ez magában foglalja a tervezést, az anyagellátást, a gyártást és a kiskereskedelemet. A szoftverellátási lánc hasonló, kivéve az anyagokat, ez kód. A gyártás helyett ez a fejlesztés. Ahelyett, hogy a földből ásták az érget, a kód szállítóktól, kereskedelmi vagy nyílt forrásból származik, és általában a nyílt forráskódú kód adattárakból származik. Ha kódokat ad hozzá egy adattárból, az azt jelenti, hogy a termék függőséget vesz fel a kódtól.

A szoftverellátási lánc támadására példa akkor fordul elő, ha a rosszindulatú kódot szándékosan hozzáadják egy függőséghez, és a függőség ellátási láncával terjesztik a kódot az áldozatok között. Az ellátási lánc támadásai valósak. Számos módszer létezik egy ellátási lánc megtámadására, a rosszindulatú kódok új közreműködőként való közvetlen beszúrásától a közreműködői fiók átvételéig, anélkül, hogy mások észrevenné, vagy akár veszélyeztetné az aláíró kulcsot a függőség hivatalosan nem részét képező szoftverek terjesztéséhez.

A szoftverellátási lánc támadása önmagában ritkán a végső cél, hanem egy lehetőség a támadók számára, hogy kártevőket szúrjanak be vagy hátsó ajtót biztosítsanak a jövőbeli hozzáféréshez.

Nem csomagolt szoftver

A nyílt forráskódú alkalmazások használata ma jelentős, és várhatóan nem fog hamarosan lelassulni. Mivel nem fogjuk abbahagyni a nyílt forráskódú szoftverek használatát, az ellátási lánc biztonságát fenyegető veszély a javítatlan szoftver. Ennek ismeretében hogyan oldható meg annak a kockázata, hogy a projekt függősége sebezhetőséggel rendelkezik?

• Tudva, hogy mi van a környezetében. Ehhez fel kell derítenie a függőségeket és az átvitt függőségeket, hogy megértse ezeknek a függőségeknek a kockázatát, például a biztonsági réseket vagy a licencelési korlátozásokat.
• A függőségek kezelése. Ha új biztonsági rést észlel, meg kell határoznia, hogy érintett-e, és ha igen, frissítsen a legújabb verzióra és a rendelkezésre álló biztonsági javításra. Ez különösen fontos az új függőségeket bevezetésével vagy a régebbi függőségek rendszeres naplózásával kapcsolatos változások áttekintéséhez.
• Az ellátási lánc figyelése. Ez a függőségek kezeléséhez használt kontrollok auditálásával történik. Ezzel szigorúbb feltételeket kényszeríthet ki a függőségeivel kapcsolatban.

A NuGet és a GitHub által biztosított különféle eszközöket és technikákat fogjuk lefedni, amelyeket ma használhat a projekten belüli lehetséges kockázatok kezelésére.

Annak ismerete, hogy mi van a környezetben

Ismert biztonsági résekkel rendelkező csomagok

📦 Csomagfelhasználó | 📦🖊 Csomag szerzője

A .NET 8 és a Visual Studio 17.8 hozzáadta a NuGetAuditot, amely a visszaállítás során ismert biztonsági résekkel rendelkező közvetlen csomagokra figyelmeztet. A .NET 9 és a Visual Studio 17.12 alapértelmezés szerint az átvitt csomagokra is figyelmeztet.

A NuGetAuditnak szüksége van egy forrásra egy ismert biztonsági rések adatbázisának biztosításához, ezért ha nem nuget.org csomagforrásként használja, vegye fel naplózási forrásként.

Mire a NuGet figyelmezteti Önt, a biztonsági rés nyilvánosan ismert lesz. A támadók ezzel a nyilvános közzététellel támadásokat fejleszthetnek olyan célokra, akik nem javították az alkalmazásaikat. Ezért ha figyelmeztetést kap arról, hogy a projekt által használt csomag ismert biztonsági rést jelent, gyorsan meg kell tennie a szükséges lépéseket.

NuGet-függőségi grafikon

📦 Csomagfelhasználó

A NuGet-függőségeket közvetlenül a megfelelő projektfájlban tekintheti meg.

Ez általában két helyen található:

• packages.config – A projekt gyökérkönyvtárában található.
• <PackageReference> – A projektfájlban található.

Attól függően, hogy milyen módszerrel kezeli a NuGet-függőségeket, a Visual Studióval közvetlenül a Megoldáskezelőben vagy a NuGet Package Managerben is megtekintheti a függőségeket.

CLI-környezetek esetén a dotnet list package paranccsal listázhatja a projekt vagy a megoldás függőségeit. A parancs segítségéveldotnet nuget why azt is megtudhatja, hogy miért szerepelnek a projekt csomaggráfjában az átvitt csomagok (a projekt által közvetlenül nem hivatkozott csomagok).

A NuGet-függőségek kezelésével kapcsolatos további információkért tekintse meg az alábbi dokumentációt.

GitHub-függőségi gráf

📦 Csomagfelhasználó | 📦🖊 Csomag szerzője

A GitHub függőségi gráfjával megtekintheti a projekttől függő csomagokat és az attól függő adattárakat. Ez segíthet a függőségeiben észlelt biztonsági rések észlelésében.

A GitHub-adattár függőségekkel kapcsolatos további információkért tekintse meg az alábbi dokumentációt.

Függőségi verziók

📦 Csomagfelhasználó | 📦🖊 Csomag szerzője

A függőségek biztonságos ellátási láncának biztosítása érdekében gondoskodnia kell arról, hogy az összes függőség és eszköz rendszeresen frissüljön a legújabb stabil verzióra, mivel ezek gyakran tartalmazzák az ismert biztonsági rések legújabb funkcióit és biztonsági javításait. A függőségek tartalmazhatnak öntől függő kódot, a felhasznált bináris fájlokat, a használt eszközöket és egyéb összetevőket. Ez a következők lehetnek:

• Visual Studio
• .NET SDK és Futtatókörnyezet
• NuGet
• NuGet-csomagok

Függőségek kezelése

NuGet elavultnak minősített és biztonsági hibát tartalmazó függőségek

📦 Csomagfelhasználó | 📦🖊 Csomag szerzője

A dotnet parancssori felületével listázhatja a projektben vagy megoldásban esetleg meglévő ismert elavult vagy sebezhető függőségeket. Használhatja a dotnet list package --deprecated vagy a dotnet list package --vulnerable parancsot, hogy megadjon egy listát az ismert elavult funkciókról vagy biztonsági résekről. A NuGetAudit figyelmeztetheti önt az ismert sebezhető függőségekre, és alapértelmezés szerint engedélyezve van, ha egy forrás biztonsági réseket tartalmazó adatbázist biztosít.

A GitHub sebezhető függőségei

📦 Csomagfelhasználó | 📦🖊 Csomag szerzője

Ha a projektet a GitHub üzemelteti, a GitHub Security segítségével biztonsági réseket és hibákat kereshet a projektben, és a Dependabot egy lekéréses kérelmet nyit meg a kódbázison.

A " Shift Left" mozgalom egyik célja, hogy a sebezhető függőségeket a bevezetésük előtt elkapja. A függőségekkel kapcsolatos információk, például a licencek, a tranzitív függőségek és a függőségek korának megismerése segít pontosan ezt megtenni.

A Dependabot-riasztásokkal és biztonsági frissítésekkel kapcsolatos további információkért tekintse meg az alábbi dokumentációt.

NuGet-konfiguráció

📦 Csomagfelhasználó

Adjon hozzá egy nuget.config fájlt a projektadattár gyökeréhez. Ez ajánlott eljárásnak számít, mivel elősegíti az ismételhetőséget, és biztosítja, hogy a különböző felhasználók ugyanazt a NuGet-konfigurációt használják. Javasoljuk, hogy adjon hozzá clear elemeket, hogy ne alkalmazzanak felhasználó- vagy gépspecifikus konfigurációt. További információ a beállítások alkalmazásáról.

Például:

<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <clear />
  </packageSourceMapping>
</configuration>

NuGet-hírcsatornák

📦 Csomagfelhasználó

Megbízható csomagforrásokat használjon. Ha több nyilvános és privát NuGet-forráscsatornát használ, a csomag bármelyik hírcsatornából letölthető. A legjobb gyakorlat annak biztosítása érdekében, hogy a build kiszámítható és biztonságos legyen az olyan ismert támadásokkal szemben, mint a Függőségi zavar, tudni, hogy a csomagok milyen konkrét forrásból származnak. Egyetlen hírcsatornát vagy privát hírcsatornát használhat felfelé irányuló védelmi képességekkel.

A csomagcsatornák védelmével kapcsolatos további információkért lásd: 3 módszer a kockázat csökkentésére privát csomagcsatornák használatakor.

Privát hírcsatorna használata esetén tekintse meg a hitelesítő adatok kezelésére vonatkozó ajánlott biztonsági eljárásokat.

Ügyfélmegbízhatósági szabályzatok

📦 Csomagfelhasználó

Vannak olyan szabályzatok, amelyekbe beleegyezhet, és amelyek megkövetelik, hogy az Ön által használt csomagok aláírva legyenek. Ez lehetővé teszi a csomag szerzőjének megbízhatóságát mindaddig, amíg a szerző aláírta, vagy megbízhat egy csomagban, ha az egy adott felhasználó vagy fiók tulajdonában van, amely NuGet.org által aláírt adattár.

Az ügyfélmegbízhatósági szabályzatok konfigurálásához tekintse meg az alábbi dokumentációt.

Fájlok zárolása

📦 Csomagfelhasználó

A zárolási fájlok a csomag tartalmának kivonatát tárolják. Ha a telepíteni kívánt csomag tartalomkivonata megegyezik a zárolási fájllal, az biztosítja a csomag megismételhetőségét.

A zárolási fájlok engedélyezéséhez tekintse meg az alábbi dokumentációt.

Csomagforrás leképezése

📦 Csomagfelhasználó

A csomagforrás-megfeleltetés lehetővé teszi, hogy központilag deklarálja, hogy a megoldás minden egyes csomagja melyik forrásból legyen visszaállítva a nuget.config fájlban.

A csomagforrás-leképezés engedélyezéséhez tekintse meg az alábbi dokumentációt.

Számítógépek biztonságossá tétele

Címtárengedélyek

📦 Csomagfelhasználó

Windows és Mac rendszeren, valamint néhány Linux-disztribúción a felhasználói fiók otthoni címtárai alapértelmezés szerint privátak. Egyes Linux-disztribúciók azonban alapértelmezés szerint olvashatóvá teszik a felhasználói könyvtárakat ugyanazon a számítógépen lévő más fiókok számára. Emellett több konfigurációs lehetőség is rendelkezésre áll a NuGet globális csomagmappájának és HTTP-gyorsítótárának nem alapértelmezett helyekre való átirányításához. A megoldásokat, projekteket és adattárakat a felhasználó kezdőlapján kívül is létrehozhatja.

Ha olyan csomagokat használ, amelyek nincsenek a nuget.org-on, akkor ha a számítógép bármely más fiókja hozzáfér a NuGet globális csomagjainak vagy a HTTP gyorsítótár könyvtárainak, vagy a projekt build kimeneti könyvtárának olvasási lehetőségéhez, ezek a csomagok hozzáférhetővé válhatnak azoknak a felhasználóknak, akiknek nem lenne szabad hozzáférniük ezekhez a csomagokhoz.

Linux rendszeren a fájlengedélyeket dotnet nuget update source úgy változtatja meg, hogy a nuget.config fájl csak a fájltulajdonos számára legyen olvasható. Ha azonban a nuget.config fájlt bármilyen más módon szerkessze, és a fájl olyan helyen található, ahol más fiókok is elolvashatják a fájlt, előfordulhat, hogy a csomag forrásának URL-címével vagy a csomag forrásának hitelesítő adataival kapcsolatos információk közzététele történik. Győződjön meg arról, hogy a nuget.config fájlokat nem tudja olvasni az ugyanazon számítógép többi felhasználója.

Megoldások a letöltési címtárban

📦 Csomagfelhasználó

A letöltési címtárban lévő megoldások vagy projektek használata esetén fokozottan ügyelni kell rá. A NuGet több konfigurációs fájlból gyűjti össze a beállításokat, és az MSBuild általában importálja a Címtár.Build.props, a Directory.NuGet.props, a Directory.Build.targets és a potenciálisan más fájlokat bármely szülőkönyvtárból, egészen a fájlrendszer gyökeréhez.

A letöltési mappa további kockázattal jár, mivel általában ez az alapértelmezett hely, ahol a webböngészők letöltik a fájlokat az internetről

Ügynökök létrehozása

📦 Csomagfelhasználó

Azok a buildügynökök (CI-ügynökök), amelyek nem állnak vissza kezdeti állapotba minden build után, több kockázattal járnak, amelyeket figyelembe kell venni.

A hitelesítő adatok kezelésének biztonságos módjairól a hitelesített hírcsatornákból származó csomagok felhasználásáról szóló dokumentációban olvashat.

A NuGet által tárolt könyvtárak módosításáról a globális csomagok, gyorsítótárak és ideiglenes mappák kezeléséről szóló dokumentációban olvashat. Ezeket a könyvtárakat olyan könyvtárra kell konfigurálni, amelyet a CI-ügynök minden build után megtisztít.

Vegye figyelembe, hogy a projekt által használt csomagok a projekt build kimeneti könyvtárában maradhatnak. Ha a projekt hitelesített forrásokból származó csomagokat használ, akkor ugyanazon CI-ügynök más felhasználói jogosulatlan hozzáférést kaphatnak a csomagszerelvényekhez. Ezért az adattárat a build végén is törölnie kell, még akkor is, ha a build meghiúsul vagy megszakad.

Az ellátási lánc monitorozása

GitHub-titkos kódok vizsgálata

📦🖊 Csomag szerzője

A GitHub átvizsgálja a NuGet API-kulcsok adattárait, hogy megakadályozza a véletlenül lekötött titkos kódok csalárd használatát.

A titkos kódok vizsgálatáról további információt a Titkos kódok vizsgálata című témakörben talál.

Szerzői csomag aláírása

📦🖊 Csomag szerzője

A szerző aláírásával a csomag szerzője lebélyegzheti a személyazonosságát egy csomagon, és a fogyasztó ellenőrizheti, hogy Öntől származik-e. Ez védelmet nyújt a tartalom illetéktelen módosítása ellen, és egyetlen igazságforrásként szolgál a csomag eredetével és a csomag hitelességével kapcsolatban. Az ügyfélmegbízhatósági szabályzatokkal kombinálva ellenőrizheti, hogy egy csomag egy adott szerzőtől származik-e.

A csomag aláírását a Csomag aláírása című témakörben találhatja meg.

Reprodukálható építések

📦🖊 Csomag szerzője

A reprodukálható buildek minden létrehozáskor bájtonként azonos bináris fájlokat hoznak létre, és olyan forráskódhivatkozásokat és fordítói metaadatokat tartalmaznak, amelyek lehetővé teszik, hogy a csomagfelhasználók közvetlenül újra létrehozhassák a bináris fájlt, és ellenőrizhessék, hogy a buildkörnyezet nem sérült-e.

A reprodukálható buildekről további információt a Forráshivatkozással rendelkező csomagok létrehozása és a reprodukálható buildérvényesítési specifikáció című témakörben talál.

Two-Factor hitelesítés (kétfaktoros hitelesítés)

📦🖊 Csomag szerzője

A nuget.org minden fiókjában engedélyezve van a 2FA. Ez további biztonsági réteget ad hozzá a GitHub-fiókba vagy a NuGet.org-fiókjába való bejelentkezéskor.

Csomagazonosító előtag foglalása

📦🖊 Csomag szerzője

A csomagok identitásának védelme érdekében lefoglalhat egy csomagazonosító-előtagot a megfelelő névtérhez egyező tulajdonos társításához, ha a csomagazonosító előtagja megfelelően tartozik a megadott feltételekhez.

Az azonosító-előtagok lefoglalásáról a Csomagazonosító előtag foglalása című témakörben olvashat.

Sebezhető csomag elavulttá nyilvánítása és listából való eltávolítása

📦🖊 Csomag szerzője

A .NET-csomag ökoszisztémájának védelme érdekében, ha tisztában van az Ön által készített csomag esetleges biztonsági résével, tegyen meg mindent annak érdekében, hogy a csomagot elavultnak jelölje és eltávolítsa a listából, így az nem jelenik meg a csomagot kereső felhasználók számára. Ha elavult és nem listás csomagot használ, kerülje a csomag használatát.

A csomagok elavulásáról és listáról levételéről a következő dokumentációban olvashat.

Érdemes lehet jelenteni az ismertet a GitHub Advisories Database-nek.

Összefoglalás

A szoftverbeszerzési láncod mindaz, ami a kódodba kerül vagy befolyásolja azt. Annak ellenére, hogy az ellátási lánc kompromisszumoi valósak és egyre népszerűbbek, még mindig ritkák; Ezért a legfontosabb teendő az ellátási lánc védelme azáltal , hogy tisztában van a függőségekkel, kezeli a függőségeket, és figyeli az ellátási láncot.

Megismerhette a NuGet és a GitHub által ma elérhető különböző módszereket, amelyekkel hatékonyabban tekintheti meg, kezelheti és figyelheti az ellátási láncot.

A világ szoftvereinek védelméről további információt az Octoverse 2020 Biztonsági jelentés állapota című témakörben talál.