Megbízható és biztonságos C++ programok létrehozása

Az Egyesült Államok kormányzati kiadványa, a NISTIR 8397: Guidelines on Minimum Standards for Developer Verification of Software kiváló útmutatást nyújt a megbízható és biztonságos szoftverek bármilyen programozási nyelven történő létrehozásához.

Ez a dokumentum ugyanazt a struktúrát követi, mint a NISTIR 8397. Minden szakasz:

  • összefoglalja, hogyan használhatók a Microsoft fejlesztői termékei A C++ és más nyelvek esetében az adott szakasz biztonsági igényeinek kielégítésére, és
  • útmutatást nyújt az egyes területek legnagyobb értékének eléréséhez.

2.1 Fenyegetésmodellezés

Összefoglalás

A fenyegetésmodellezés értékes folyamat, különösen akkor, ha olyan skálázást alkalmaznak, amely megfelel a fejlesztési igényeknek, és csökkenti a zajt.

Ajánlások

A fenyegetésmodellezésnek a dinamikus biztonsági fejlesztési életciklus (SDL) egyik részének kell lennie. Javasoljuk, hogy a termék egésze, egy adott funkció, vagy egy jelentős tervezési vagy megvalósítási változás esetén:

  • Szilárd, dinamikus SDL-vel rendelkezik, amely lehetővé teszi a fejlesztői csapatokkal való korai részvételt és a megközelítési jogosultságok érvényesítését.
  • A fenyegetésmodellezést célzott módon alkalmazhatja. Alkalmazza a fenyegetésmodellezést az összes funkcióra, de taktikailag kezdje a közzétett, összetett vagy kritikus funkciókkal. Inkább alkalmazza rendszeresen egy felülről lefelé történő termékértékelés részeként.
  • Alkalmazza a fenyegetésmodellezést korán (mint minden biztonsági követelmény esetében), amikor még lehetőség van a terv módosítására. Emellett a fenyegetésmodellek más folyamatok bemeneteként is szolgálnak, például a támadási felület csökkentéséhez vagy a biztonság kialakításához. A később létrehozott fenyegetésmodellek legfeljebb "felmérések" a penetrációs tesztekhez (behatolásteszteléshez) vagy olyan területekhez, amelyek biztonsági tesztelést igényelnek, például a *fuzzing*. Az alapkonfigurációs fenyegetésmodell létrehozása után tervezze meg, hogy a támadási felület változásakor folytassa az iterálást.
  • Az eszközleltár és a megfelelőség használatával megfelelően nyomon követheti a termék összetevőit, és nyomon követheti a biztonsági összetevőket (beleértve a fenyegetésmodelleket is), valamint az általuk alkalmazott eszközöket. Ez a megközelítés jobb automatizált kockázatértékelést tesz lehetővé, és a biztonsági erőfeszítéseket a változó összetevőkre vagy funkciókra összpontosítja.
  • Az Azure-ban a Microsoft Threat Modeling Tool 2022-ben frissült az Azure-fejlesztéshez. További információ: Microsoft Threat Modeling Tool – Áttekintés – Azure

Támogató tényezők és gyakorlatok

A fenyegetésmodellezés megfelelő alkalmazása és a túlzott használat elkerülése érdekében úgy találtuk, hogy először a következő alapvető fogalmakat kell figyelembe venni.

Fejlesztési megközelítés

Először is ismerje meg a csapat fejlesztési megközelítését. Az olyan agilis fejlesztési munkafolyamatokkal rendelkező csapatok számára, amelyek naponta több tucat változtatást hajtanak végre az éles környezetben, nem praktikus vagy ésszerű, ha minden funkcionális változáshoz szükség van egy fenyegetésmodell frissítésére. Ahelyett már a funkcionális követelmények megírásakor fontolja meg egy biztonsági követelményeket tartalmazó kérdőív beillesztését. A kérdőívnek a funkcióval kapcsolatos konkrét kérdésekre kell összpontosítania annak meghatározásához, hogy az SDL milyen jövőbeli aspektusait alkalmazza. Például:

  • A funkció jelentős változást hoz a több-bérlős környezetek ügyfélelkülönítésének kialakításában? Ha igen, fontolja meg egy teljes fenyegetésmodell végrehajtását.
  • Engedélyezi egy új funkció a fájlfeltöltést? Ha igen, akkor talán a webalkalmazások biztonsági felmérése a legmegfelelőbb.
  • Ez a változás elsősorban csak egy funkcionális felhasználói felületi változás? Ha igen, akkor talán semmire sincs szükség a hagyományos automatizált eszközhasználaton túl.

A biztonsági kérdőív eredményei azt jelzik, hogy mely SDL-technikákat kell a fejlesztési egységhez kötni. Emellett tájékoztatja a fejlesztői partnereket a szolgáltatás SDL-ütemtervéről, hogy a megfelelő időben együttműködhessenek.

Termékleltár

Másodszor, őrizze meg a kiértékeléssel megbízott termékek erős eszközleltárát. A termékek egyre összetettebbek. Gyakran előfordul, hogy olyan csatlakoztatott eszközökhöz ír szoftvereket, amelyek rendelkeznek:

  • érzékelők (például személyvasút és járművek),
  • buszalapú hálózatok, amelyek a jármű más összetevőivel kommunikálnak (például a CANBUS vagy a PROFIBUS),
  • vezeték nélküli/mobil/Bluetooth az ügyféleszközökkel és a felhőbeli háttérrendszerekkel való kommunikációhoz,
  • gépi tanulás a felhőben, amely visszatáplálást nyújt az eszközre vagy egy flottakezelő alkalmazásra,
  • és így tovább.

Ilyen összetett termékekben a fenyegetésmodellezés kritikus fontosságú. Az erős eszközleltár lehetővé teszi a teljes termékverem megtekintését a teljes kép megtekintéséhez, valamint azokat a kulcsfontosságú helyeket, amelyeket ki kell értékelni, hogy egy új vagy módosított funkció hogyan befolyásolja a termékbiztonságot.

Részletesség és integráció

A megfelelőség mérésére használható rendszerek létrehozása világos metrikák használatával.

  • A funkciószintű fejlesztés megfelelőségének rendszeres mérése. A funkciómegfelelést általában nagyobb gyakorisággal és kisebb részletességgel kell mérni, néha még a fejlesztő rendszerében vagy a kód véglegesítési/egyesítési ideje alatt is.
  • Rendszeresen értékelje ki annak a szélesebb terméknek a biztonságát, amelyben egy szolgáltatást vagy összetevőt használnak fel. A szélesebb körű értékeléseket általában alacsonyabb gyakorisággal és szélesebb részletességgel végzik el, például a modul vagy a rendszer tesztelési ideje alatt.

Skála

Őrizze meg a megfelelő eszközleltár-rendszert, amely rögzíti és megőrzi a biztonsági összetevőket és a fenyegetésmodell-felülvizsgálatok kimenetét. A tiszta készlettel kiértékelheti a minták kimeneteit, és intelligens döntéseket hozhat a termékbiztonsági program rendszeres finomításáról.

Próbálja kombinálni a követelményfázisú biztonsági kérdőíveket, a fenyegetésmodellezési eredményeket, a biztonsági felmérés eredményeit és az automatizált eszközök eredményeit. Ezek kombinálásával automatizálhatja egy adott termék relatív kockázatának nézőpontját, ideális esetben "irányítópultként", hogy tájékoztassa a biztonsági csapatokat arról, hogy mire kell összpontosítania, hogy a lehető legjobb értéket hozhassa ki a fenyegetésmodellezésből.

2.2 Automatizált tesztelés

Összefoglalás

Az automatizált tesztek fontos módja a kód minőségének és biztonságának biztosításának. Ezek szerves részei a dokumentumban említett egyéb területek támogatásának, például a fenyegetésmodellezésnek. Más biztonságos kódolási eljárásokkal párosítva segítenek megvédeni a kódbázisba beszúrt hibákat és biztonsági réseket.

Kulcsattribútumok

A teszteknek megbízhatónak, konzisztensnek és izoláltnak kell lenniük. Ezeknek a teszteknek a kód lehető legnagyobb részét kell lefedniük. Minden új funkciónak és hibajavításnak megfelelő tesztekkel kell rendelkeznie a kód hosszú távú biztonsága és megbízhatósága érdekében, ha lehetséges. Automatizált teszteket rendszeresen és a lehető legtöbb környezetben futtathat, hogy biztosítsa azok futtatását, és hogy az összes területre kiterjedjen:

  • Elsőként azon a gépen kell futniuk, amelyen a módosításokat hajtják végre. A teszteket a legegyszerűbben a szerkesztéshez használt IDE-n belül, vagy szkriptként lehet elvégezni a parancssorban, miközben a fejlesztő végrehajtja a módosításokat.
  • A következő hely, ahol futniuk kell, a pull request véglegesítési/egyesítési folyamat részeként van.
  • A tesztek utolsó futtatása egy folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) folyamat vagy a kiadásra jelölt buildek részeként történik.

A tesztek hatókörének minden lépésnél növekednie kell, az utolsó lépés pedig teljes lefedettséget biztosít minden olyan dologra, amit a többi lépés kihagyhat.

Folyamatos használat és karbantartás

A tesztelési csomag hatékonyságának fenntartásának fontos része a tesztelési megbízhatóság. A tesztelési hibákat ki kell osztani és ki kell vizsgálni, mert a lehetséges biztonsági problémák magas prioritást kapnak, és egy gyors és előre meghatározott időkereten belül frissülnek. A tesztelési hibák figyelmen kívül hagyása nem általános gyakorlat, de erős indoklást és jóváhagyást igényel. A tesztcsomagon belüli problémák miatti teszthibákat ugyanúgy kell kezelni, mint a többi hibát, hogy ne merüljön fel olyan lefedettség, amelyben a termékproblémák kihagyhatók.

Tesztek típusai, különösen egységtesztek

Többféle automatizált teszt létezik, és bár nem mindegyik alkalmazható minden alkalmazásra, egy jó tesztcsomag számos különböző típust tartalmaz. A kódalapú tesztelési esetek, például az egységtesztek a leggyakoribbak és legintegrálhatóbbak, amelyek minden alkalmazásra alkalmazhatók, és szándékosan lefedik a lehető legtöbb kódútvonalat a helyesség érdekében. Ezeknek a teszteknek kicsinek, gyorsnak kell lenniük, és nem lehetnek hatással a gép állapotára, így a teljes tesztcsomag gyorsan és gyakran futtatható. Ha lehetséges, futtasson teszteket számos különböző hardverbeállítással rendelkező gépen, hogy olyan problémákat észleljen, amelyek egyetlen géptípuson nem reprodukálhatók.

Visual Studio

A Visual Studio Test Explorer natív módon támogatja a legnépszerűbb C++ tesztelési keretrendszereket, és további keretrendszerekhez is telepíthető bővítmények. Ez a rugalmasság hasznos lehet a tesztek egy részhalmazának futtatásához, amely lefedi a használt kódot, és megkönnyíti a teszthibák hibakeresését a felmerülő hibák esetén. A Visual Studio emellett megkönnyíti az új tesztcsomagok beállítását a meglévő projektekhez, és olyan hasznos eszközöket biztosít, mint a CodeLens, amely megkönnyíti ezeknek a teszteknek a kezelését. A C/C++ tesztek Visual Studióval való írásáról, futtatásáról és kezeléséről további információt a C/C++ – Visual Studio (Windows) egységtesztjeinek írása című témakörben talál.

Az Azure-ban és a GitHub CI/CD-ben

A mélyebb ellenőrzést végző és hosszabb ideig tartó tesztek, például a statikus elemzés, az összetevők észlelése stb., jó jelöltek a lekéréses kérelmek tesztelésére vagy a folyamatos integrációs tesztelésre. Az Azure DevOps és a GitHub Actions megkönnyíti az ellenőrzések automatikus futtatását, és letiltja a kódellenőrzéseket, ha az érvényesítés sikertelen. Az automatizált kényszerítés segít biztosítani, hogy az összes beadott kód biztonságos legyen ezen szigorúbb ellenőrzések alapján. Az Azure Pipelines és az Azure DevOps build-érvényesítés itt van leírva:

2.3 Kódalapú vagy statikus elemzés

Összefoglalás A statikus kód-/bináris elemzést alapértelmezés szerint engedélyezni kell, hogy alapértelmezés szerint biztonságos legyen. A statikus elemzés elemzi a szükséges biztonsági és biztonsági szabályzatok programját a létrehozásakor, nem pedig a végrehajtáskor, amikor biztonsági rések léphetnek fel az ügyfél gépén. A statikus elemzés forráskód formájában vagy lefordított végrehajtható formában elemezheti a programot.

Ajánlások A Microsoft a következőket javasolja:

  • Engedélyezze a statikus elemzést az összes C++ programhoz, mind a bemeneti forráskódhoz (fordítás előtt) és a végrehajtható bináris fájlokhoz (fordítás után). Az "Engedélyezés" azt jelentheti, hogy a fejlesztő gépén az egyes buildek során elemzést futtat, vagy külön buildként a kód későbbi vagy beadási követelményként való vizsgálatához.
  • A statikus elemzés beépítése a CI-folyamatokba mint tesztelési módszer.
  • A statikus elemzés definíció szerint hamis pozitívumokat is tartalmaz, ezért fel kell készülni arra, hogy ezt a tényt beépítsük a minőségbiztosítási folyamatba. Engedélyezze gyorsan előzetesen az összes hamis pozitív figyelmeztetést alacsony fokozattal. Ezután proaktívan növelje azoknak a szabályoknak a számát, amelyekre a kódbázis figyelmeztetést állít össze, mivel rendszeresen hozzáad további szabályokat, amelyek fontos hibákat jelölnek meg a fokozatosan magasabb hamis pozitív értékek rovására (kezdetben, mielőtt a kódbázist is megtisztították volna ezekhez a szabályokhoz).
  • Mindig használja a Visual Studio legújabb támogatott verzióit, és állítsa be a mérnöki környezetet, hogy gyorsan felhasználja a legújabb patch-kiadásokat, amint elérhetővé válnak, anélkül, hogy a következő fejlesztési fázisra/ciklusra késleltetné.

Kulcseszközök Vegye figyelembe és használja a következőket:

Megjegyzések:

  • /analyze lehetővé teszi a C++ kód fordítási időben történő statikus elemzését a kritikus biztonsági és megbízhatósági kód biztonsági réseinek azonosításához. A C++ program teljes fejlesztési ütemtervében engedélyezni kell. Először is állítsa be alapértelmezettként a „Microsoft Native Recommended” engedélyezését a minimális alapkonfiguráció érdekében. Ezután tekintse meg a dokumentációt, amelyből megtudhatja, hogyan adhat meg további szabályokat, különösen a C++ alapvető irányelvek szabályait, a mérnöki szabályzatok által megkövetelt módon. A forráskód statikus elemzési képessége a Visual Studio IDE-ben és a parancssori buildeszközökben is elérhető.
  • /W4 és /WX ahol csak lehetséges, engedélyezni kell, hogy a kódot nagy figyelmeztetési szinteken (W4) megfelelően fordíthassa le, és a figyelmeztetéseket kijavítandó hibaként kezelje (WX). Ezek a beállítások lehetővé teszik az olyan nem inicializált adathibák megtalálását, amelyeket más statikus elemzési eszközök nem tudnak ellenőrizni, mivel a hibák csak akkor válnak láthatóvá, ha a fordító háttérrendszere interprokedurális elemzést és fordítást végez.
  • A BinSkim bináris elemzése biztosítja, hogy a projektek széles körű biztonsági funkciókat tegyenek lehetővé. A BinSkim olyan PDF-eket és egyéb kimeneteket hoz létre, amelyek megkönnyítik a felügyeleti lánc ellenőrzését, és hatékonyan reagálnak a biztonsági problémákra. A Microsoft azt javasolja, hogy futtassa a BinSkim eszközt a programok számára létrehozott vagy felhasznált összes végrehajtható bináris fájl (.sys.dllvagy .exe) elemzéséhez. A BinSkim felhasználói útmutatója tartalmazza a támogatott biztonsági szabványok listáját. A Microsoft azt javasolja, hogy javítsa ki a BinSkim eszköz által "hibaként" jelentett összes problémát. A "figyelmeztetésként" jelentett problémákat szelektíven kell kiértékelni, mert azok megoldása hatással lehet a teljesítményre, vagy nem feltétlenül szükséges.

Az Azure-ban és a GitHub CI/CD-ben A Microsoft azt javasolja, hogy mindig engedélyezze a forráskódot és a bináris statikus elemzést a kiadási CI/CD-forgatókönyvekben. Futtassa a forráselemzést azonnal a helyi fejlesztő gépén, vagy legalábbis minden véglegesítési vagy lekéréses kérelem esetében, hogy a lehető leghamarabb elkapja a forráshibát, és minimalizálja az általános költségeket. A bináris szintű hibákat általában lassabban vezetik be, ezért elegendő lehet bináris elemzést futtatni a ritkábban használt CI/CD-forgatókönyvekben (például éjszakai vagy heti buildekben).

2.4 A kódolt titkos kódok áttekintése

Összefoglalás

Ne kódolja a titkos kódokat a szoftveren belül. A forráskód titkos kulcsait hatékonyan keresheti meg és távolíthatja el megbízható eszközökkel, amelyek a teljes forráskódbázist beolvashatják. Miután megtalálta a titkos kulcsokat, helyezze őket biztonságos helyre a titkos kulcsok biztonságos tárolására és használatára vonatkozó útmutatót követve.

Probléma

A "titkos kódok" olyan entitások, amelyek identitást hoznak létre, és hozzáférést biztosítanak az erőforrásokhoz, vagy amelyek bizalmas adatok aláírására vagy titkosítására szolgálnak. Ilyenek például a jelszavak, a tárkulcsok, a kapcsolati sztringek és a titkos kulcsok. Csábító, hogy titkos kulcsokat tartsanak a szoftvertermékben, hogy a szoftver szükség esetén könnyen beszerezhesse őket. Ezek a szigorúan kódolt titkos kódok azonban súlyos vagy katasztrofális biztonsági incidensekhez vezethetnek, mivel könnyen felderíthetők, és felhasználhatók a szolgáltatás és az adatok veszélyeztetésére.

megelőzési

A forráskódban (egyszerű szöveges vagy titkosított blobként) rögzített titkos kódok biztonsági rést jelentenek. Az alábbiakban általános útmutatást talál a titkos kódok forráskódban való elkerüléséről:

  • Használjon egy előellenőrző eszközt a kódban lévő lehetséges előre kódolt titkok átvizsgálásához és észleléséhez, mielőtt forrásvezérlés alá küldené a kódot.
  • Ne helyezzen el egyértelmű szöveges hitelesítő adatokat a forráskódban vagy a konfigurációs fájlokban.
  • Ne tárolja a tiszta szöveges hitelesítő adatokat a SharePointban, a OneNote-ban, a fájlmegosztásokban stb. Vagy ossza meg őket e-mailben, üzenetküldő alkalmazásokkal stb.
  • Ne titkosítsa a titkos kulcsokat könnyen felderíthető visszafejtési kulccsal. Például ne tároljon PFX-fájlt a jelszavát tartalmazó fájllal együtt.
  • Ne titkosítsa a titkos kulcsokat gyenge visszafejtéssel. Például ne titkosítsa a PFX-fájlokat gyenge vagy gyakori jelszóval.
  • Kerülje a titkosított hitelesítő adatok forráskódban való elhelyezését. Ehelyett a forrásban használjon helyőrzőket, és hagyja, hogy az üzembe helyezési rendszer ezeket váltsa fel az engedélyezett tárolók titkos adataival.
  • Ugyanazokat az alapelveket alkalmazza a titkokra olyan környezetekben, mint a tesztelés, az előkészítés stb., mint ahogyan az éles környezetekben teszi. A támadók gyakran a kevésbé jól kezelt tesztrendszereket célozzák meg, majd ezeket használják fel az éles környezetbe való átjutásra.
  • Ne ossza meg a titkos adatokat a különböző környezetek között (például tesztelés, előkészítés, éles környezet).

Bár közvetlenül nem kapcsolódik a szigorúan kódolt titkos kódokhoz, ne feledje, hogy titkos kulcsokat biztosít a teszteléshez, fejlesztéshez és éles környezethez:

  • A titkos kulcsokat rendszeresen forgassa el, és bármikor, amikor esetleg felfedték őket. A titkos kulcsok elforgatásának/ismételt üzembe helyezésének bizonyított képessége egy biztonságos rendszer bizonyítéka. Pontosabban, ennek a képességnek a hiánya még erősebb bizonyítéka az elkerülhetetlen sebezhetőségnek.
  • Ne adja meg magát a fejlesztők általános érvelésének, amely szerint "a teszt hitelesítő adataim nem járnak kockázattal". A gyakorlatban szinte mindig van kockázat.
  • Fontolja meg, hogy a titkoktól, például jelszavaktól és kulcsoktól, teljesen elhagyja az RBAC- és identitásvezérelt megoldások javára, mint egy jó mérnöki megoldást, amely lehetővé teszi a titkok helytelen kezelésének teljes elkerülését.

észlelési

A termék régi összetevői rejtett, keménykódolt titkokat tartalmazhatnak a forráskódjukban. Néha a fejlesztők asztali gépeiről származó titkok távoli ágba csúszhatnak, és összeolvadnak a kiadási ággal, véletlenül kiszivárogtatva a titkokat. A forráskódban esetleg elrejtett titkos kódok felderítéséhez használhat olyan eszközöket, amelyekkel a kódban rögzített titkos kódokat kereshet:

Kijavítás

Ha hitelesítő adatokat talál a forráskódban, azonnal sürgősen érvényteleníteni kell a közzétett kulcsot, és kockázatelemzést kell végezni az expozíció alapján. Még ha a rendszernek továbbra is futnia kell, az alábbi lépések végrehajtásával engedélyezheti a titkos kulcskezelők szervizelését:

  1. Ha a szervizelés lehetővé teszi a felügyelt identitások közötti váltást, vagy egy titkos kulcskezelőbe, például az Azure Key Vaultba (AKV) való bedobást igényel, először végezze el ezt. Ezután telepítse újra a frissített identitással vagy kulccsal.
  2. Érvénytelenítse a felfedett titkos kódot.
  3. Végezzen naplózást/kockázatfelmérést a potenciális kárról, amely a sérülés miatt keletkezik.

A felhőalkalmazások és -szolgáltatások által használt titkosítási kulcsok és egyéb titkos kódok védelme érdekében használja az Azure Key Vaultot egy megfelelő hozzáférési szabályzattal.

Ha egy kitettség veszélyeztet bizonyos ügyféladatokat/PII-t, az egyéb megfelelőségi/jelentési követelményeket is megkövetelhet.

Távolítsa el az érvénytelenített titkos kulcsokat a forráskódból, és cserélje le azokat olyan alternatív módszerekre, amelyek nem teszik elérhetővé közvetlenül a titkos kulcsokat a forráskódban. Olyan lehetőségeket keres, ahol csak lehetséges, a titkos kulcsok eltávolítására az Azure AD-hez hasonló eszközökkel. A hitelesítési módszereket frissítheti, hogy kihasználhassa a felügyelt identitások előnyeit az Azure Active Directoryn keresztül. Csak jóváhagyott tárolókat használjon olyan titkos kódok tárolására és kezelésére, mint az Azure Key Vault (AKV). További információkért lásd:

Azure DevOps (AzDO)

Az AzDO-felhasználók a GitHub Advanced Security for Azure DevOps (GHAzDO) segítségével ellenőrizhetik a kódjukat. A GHAzDO lehetővé teszi a felhasználók számára, hogy megakadályozzák a titkos kitettségeket azáltal, hogy engedélyezik a Push Protection használatát az adattáraikon, és észlelik a potenciális expozíciókat, mielőtt kiszivárognának. Az Azure DevOpsban a kódban rögzített titkos kódok észleléséről a GitHub Advanced Security for Azure DevOps titkos kulcskeresése című témakörben talál további információt az alábbi hivatkozások mindegyikében:

A GitHubon

A titkos kódok vizsgálata két formában érhető el GitHub.com:

  • Titkos kódvizsgálati riasztások partnerek számára. Automatikusan fut az összes nyilvános adattáron. A titkos kulcskereső partnerek által biztosított mintáknak megfelelő sztringeket a rendszer közvetlenül az érintett partnernek jelenti.
  • Titkos kódvizsgálati riasztások felhasználók számára. Engedélyezheti és konfigurálhatja a GitHub Enterprise Cloudot használó és a GitHub Advanced Securityhez licenccel rendelkező szervezetek tulajdonában lévő adattárak további vizsgálatát. Ezek az eszközök a magán- és belső adattárakat is támogatják.

A GitHub ismert titkos kódmintákat biztosít a partnerek és a felhasználók számára, amelyek az igényeinek megfelelően konfigurálhatók. További információkért lásd:

Megjegyzés:

Az Azure DevOps GitHub Advanced Security szolgáltatása ugyanazokat a titkos kulcskeresési, függőségvizsgálati és CodeQL-kódkeresési megoldásokat biztosítja, mint a GitHub-felhasználók számára, és natív módon integrálja őket az Azure DevOpsba az Azure-adattárak és -folyamatok védelme érdekében.

További erőforrások

2.5 Futtatás nyelvi és operációs rendszer által biztosított ellenőrzésekkel és védelemmel

Összefoglalás

A bináris megkeményedés fordítási idejű biztonsági vezérlők alkalmazásával történik. Ilyenek például a következők:

  • a kód kihasználható biztonsági réseinek megakadályozása,
  • olyan futtatókörnyezet-észlelések engedélyezése, amelyek biztonsági védelmet váltanak ki a kizsákmányoláskor, és
  • lehetővé teszi az adatok előállítását és archiválását a biztonsági incidensek okozta károk csökkentése érdekében.

A bináris fogyasztóknak a Windows biztonsági funkcióit kell választaniuk, hogy teljes mértékben kihasználják a megkeményedés előnyeit.

A Microsoft a C++ projektekhez kapcsolódó létesítményeket biztosít, amelyek segítenek a fejlesztőknek biztonságosabb és biztonságosabb kódokat írni és szállítani. A C++ fejlesztőknek is be kell tartaniuk a végrehajtható kódot létrehozó nyelvekre jellemző biztonsági szabványokat. A Microsoft fenntartja a BinSkim nyilvános OSS bináris ellenőrzőt, amely segít kikényszeríteni az ebben a szakaszban ismertetett számos védelem használatát. További információ a BinSkimről: Binskim felhasználói útmutató | GitHub

A bináris szintű vezérlők attól függően különböznek, hogy hol alkalmazzák őket a mérnöki folyamatban. Meg kell különböztetnie a fordító és a linker beállításait, amelyek a következők: szigorúan fordítási idő, a kódgenerálás módosítása futásidejű többletterheléssel, valamint a kódgenerálás módosítása az operációsrendszer-védelemmel való kompatibilitás érdekében.

A fejlesztői beállításoknak a lehető legtöbb statikus elemzést kell engedélyeznie, lehetővé kell tenni a privát adatok előállítását a hibakeresés felgyorsítása érdekében, és így tovább. A kiadási buildeket a biztonsági, teljesítménybeli és egyéb kódgenerálási szempontok megfelelő kombinációjára kell hangolni. A kiadási folyamatokat úgy kell konfigurálni, hogy megfelelően generálják és kezeljék a nyilvános és a privátan felhasznált buildadatokat (például a nyilvános és a privát szimbólumokat).

Maradjon naprakész: Mindig up-to-date fordítókat és eszközöket használjon

Állítsa össze az összes kódot az aktuális eszközkészletekkel, hogy kihasználhassa up-to-date nyelvi támogatás, statikus elemzés, kódgenerálás és biztonsági vezérlők előnyeit. Mivel a fordítók minden létrehozott összetevőre hatással vannak, az eszközfrissítés regressziójának lehetősége viszonylag magas. Az elavult fordítók használata különös kockázatot jelent a biztonsági incidensekre való reagálás során fellépő korrekciós műveletekre, mivel előfordulhat, hogy a csapatoknak nincs elég idejük a fordítók frissítésére. A Microsoft azt javasolja, hogy a csapatok fejlesszék ki a létesítményt a fordítófrissítések rendszeres frissítéséhez és teszteléséhez.

Biztonságos fejlesztési módszerek, nyelvi verziók, keretrendszerek/API-k használata

A kódnak olyan fejlesztési módszereket, nyelvi verziókat, keretrendszereket, API-kat és egyebeket kell használnia, amelyek minimalizálják a kockázatot azáltal, hogy elősegítik a C++-ban a biztonságot és az egyszerűséget, beleértve a következőket:

  • Az ajánlott eljárásokat követő és a gyakori buktatókat elkerülő, modern, biztonságos és konzisztens C++ kód írására vonatkozó útmutatásért tekintse meg a C++ alapvető irányelvek útmutatójának támogatási kódtárát (GSL ).
  • Tekintse meg a Microsoft GSL-implementációját azokról a függvényekről és típusokról, amelyeket a C++ alapvető irányelvei javasolnak.
  • Erőforrás-biztonságos C++ tárolók, C futtatókörnyezeti kódtár (CRT) memória túlcsordulás elleni védelme: Előnyben részesítés std::vector és std::string, amelyek erőforrás-biztonságosak. Ha C-adatokat kell használnia, használja a CRT-függvények biztonságos verzióit, amelyek célja, hogy megakadályozza a memória sérülését a puffer helytelen használata és a nem definiált nyelvi viselkedések miatt.
  • A SafeInt kódtár védelmet nyújt a matematikai és összehasonlító műveletek egész számának túlcsordulása ellen.

Biztonságos függőségek használata

A bináris fájlok nem hivatkozhatók nem biztonságos kódtárakra és függőségekre. A fejlesztői csapatoknak nyomon kell követniük az összes külső függőséget, és meg kell oldaniuk a cves/azonosított biztonsági réseket ezekben az összetevőkben azáltal, hogy a biztonsági rések esetén biztonságosabb verziókra frissítenek.

A kód származási szavatosságának és a biztonsági válasz hatékonyságának maximalizálása

A fordításnak lehetővé kell tennie az erős kód-eredet-garanciákat, amelyek segítenek észlelni és megakadályozni a backdoorok és más rosszindulatú kódok bevezetését. A hibakereséshez és a vizsgálathoz szintén kritikus fontosságú adatokat az összes szoftverkiadás esetében archiválni kell, hogy a biztonsági válasz hatékony legyen, ha azok sérülnek. A következő fordítókapcsolók olyan információkat hoznak létre, amelyek kritikus fontosságúak a biztonsági válasz szempontjából:

  • /ZH:SHA_SHA256 a Microsoft C++ alkalmazásban – Biztosítja, hogy egy kriptográfiailag biztonságos algoritmussal hozza létre az összes PDB-forrásfájl kivonatát.
  • /Zi, /ZI (Hibakeresési információformátum) a Microsoft C++ alkalmazásban – Az összeomlási adatok és más nyilvános használati forgatókönyvek gyűjtésére szolgáló lecsupaszított szimbólumok közzététele mellett győződjön meg arról, hogy a buildek minden kiadott bináris fájlhoz létrehoznak és archiválnak privát PDF-eket. A bináris elemzési eszközök teljes szimbólumokat igényelnek annak ellenőrzéséhez, hogy számos biztonsági kockázatcsökkentés engedélyezve volt-e fordításkor. A privát szimbólumok kritikus fontosságúak a biztonsági válasz szempontjából, és csökkentik a hibakeresési és vizsgálati költségeket, amikor a mérnökök a károk felmérése és korlátozása érdekében versenyeznek egy biztonsági rés bekövetkezésekor.
  • /SOURCELINK a Microsoft C++ Linkerben – Sourcelink-fájl belefoglalása a PDB-fájlba: A Source Link egy nyelv- és verziókezelés-agnosztikus rendszer, amely forráskód hibakeresést biztosít a bináris fájlokhoz. A forráskeresés jelentősen növeli az előzetes biztonsági ellenőrzések és a kiadás utáni incidensek válaszainak hatékonyságát.

Fordítási hibák engedélyezése a kódkészítési időpontban felmerülő problémák megelőzéséhez

A fordítási folyamatnak lehetővé kell tennie a biztonsági szempontból releváns fordítóellenőrzések megtörő hibaként történő kezelését, például:

Bináris fájlok megjelölése az operációs rendszer futtatókörnyezetének biztonsági kockázatcsökkentéseivel kompatibilisként

A fordító és a linker beállításainak olyan kódgenerálási funkciókat kell választaniuk, amelyek észlelik és csökkentik a rosszindulatú kódvégrehajtást, beleértve a következőket:

Bizalmas információk felfedésének megakadályozása

A fordító beállításainak a bizalmas információfelderítés megelőzését kell választaniuk. Az elmúlt években a kutatók nem szándékos információszivárgást fedeztek fel, amely olyan hardverfunkciókból ered, mint a spekulatív végrehajtás.

Szoftverszinten bizalmas adatok továbbíthatók a támadóknak, ha váratlanul kiszivárognak. A pufferek nulla inicializálásának és más pufferekkel való visszaélésnek a sikertelensége bizalmas adatokat szivárogtathat ki a megbízható API-t hívó támadók számára. Ez a problémaosztály a legjobban úgy kezelhető, hogy lehetővé teszi az extra statikus elemzést, és biztonságos erőforrástárolókat használ a korábban leírtak szerint.

  • /Qspectre - A spekulatív végrehajtás oldalcsatornás támadásainak mérséklése – Sorompó-utasításokat szúr be, amelyek megakadályozzák a spekulatív végrehajtás során keletkező bizalmas adatok felfedését. Ezeket a kockázatcsökkentéseket engedélyezni kell olyan kód esetében, amely bizalmas adatokat tárol a memóriában, és egy megbízhatósági határon keresztül működik. A Microsoft mindig azt javasolja, hogy mérje a teljesítményre gyakorolt hatást a megfelelő teljesítménytesztekkel szemben, amikor engedélyezi a Spectre-csökkentéseket, mivel lehetősége van futásidejű ellenőrzések bevezetésére a teljesítmény szempontjából kritikus fontosságú blokkokban vagy hurkokban. Ezek a kódútvonalak a spectre(nomitigation)declspec módosítóval letilthatják a kockázatcsökkentéseket. Az engedélyező /Qspectre projekteknek olyan kódtárakra is hivatkoznia kell, amelyeket szintén ezekkel a kockázatcsökkentésekkel fordítanak le, beleértve a Microsoft futtatókörnyezeti kódtárait is.

2.6 Fekete dobozos tesztesetek

Összefoglalás

A fekete dobozos tesztek nem támaszkodnak a tesztelt összetevő belső működésének ismeretére. A fekete dobozos tesztek úgy vannak kialakítva, hogy teszteljék a termék funkcióinak végpontok közötti működését bármilyen rétegben vagy szinten. A feketedobozos tesztek lehetnek funkcionális tesztek, felhasználói felületi tesztek, teljesítménytesztek és integrációs tesztek. A fekete dobozos tesztek értékesek az általános megbízhatóság és a funkcionális helyesség méréséhez, valamint annak biztosításához, hogy a termék a várt módon viselkedjen.

Kapcsolat más szakaszokhoz

Az ilyen típusú követelményalapú tesztek hasznosak a fenyegetésmodellben szereplő feltételezések ellenőrzéséhez és az adott szakaszban ismertetett lehetséges fenyegetések lefedéséhez. Ezek a tesztek hasznosak a termék különböző összetevői közötti integráció teszteléséhez, különösen azok esetében, amelyek a fenyegetésmodellben leírt megbízhatósági határokon átnyúlóak. A fekete dobozos tesztesetek a felhasználói bemenetek ellenőrzéséhez használható szélsőséges esetek teszteléséhez is hasznosak. Az ismert peremhálózati esetek és hibaesetek tesztelése egyaránt hasznos. A homályosítás a kevésbé nyilvánvaló esetek teszteléséhez is hasznos.

Automatizálás és regresszió

Rendszeresen futtassa ezeket a teszteket, és hasonlítsa össze az eredményeket az előző futtatásokkal, hogy észlelje a kompatibilitástörő változásokat vagy a teljesítményregressziókat. Emellett ezeknek a teszteknek a futtatása számos különböző gépen és telepítési beállításon segíthet a különböző architektúrákból vagy beállítási módosításokból eredő problémák megoldásában.

Összeomlási memóriaképek

Ezek a tesztek segítenek megtalálni a megbízhatósággal kapcsolatos problémákat, és számos különböző forgatókönyvet tesztelhetnek, amelyek összeomlásokba, lefagyásokba, holtpontokba ütközhetnek stb. A programösszeomlás utáni memóriaképek gyűjtésével a teszthibák részeként közvetlenül importálhatja azokat a Visual Studio-ba, hogy tovább vizsgálja, a kód mely részei okozzák ezeket a problémákat. Ha funkcionális teszteket futtat a Visual Studióban, egyszerűen replikálhatja és hibakeresésre használhatja a hibákat, ha pontosan látja, hogy a fekete dobozon belül hol sikertelen a teszt, és gyorsan tesztelheti a javításokat.

A hibakeresési tesztek első lépéseit a Test Explorer – Visual Studio (Windows) hibakeresési egységtesztjeiben találhatja meg.

Az Azure-ban

Az Azure DevOps a tesztcsomagok használatával is segíthet ezeknek a teszteknek a kezelésében és ellenőrzésében. Ezek a tesztek felhasználhatók a manuális ellenőrzéssel történő jóváhagyás biztosítására, valamint a termékkövetelményekkel kapcsolatos automatizált tesztek futtatására. Az Azure Test Plans szolgáltatással és az automatizált tesztelés futtatásával kapcsolatos további információk itt találhatók:

2.7 Kódalapú tesztelési esetek

Összefoglalás

A kódalapú tesztesetek a termék biztonságának és megbízhatóságának fenntartásának szerves részét képezik. Ezeknek a teszteknek kicsinek és gyorsnak kell lenniük, és nem szabad hatással lenniük egymásra, így párhuzamosan futtathatók. A kódalapú tesztek könnyen futtathatók helyileg a fejlesztőgépükön, amikor módosításokat végeznek a kódon anélkül, hogy a fejlesztési ciklus lassításával kellene foglalkozniuk.

Típusok és más szakaszokhoz való viszony

A kódalapú tesztelési esetek gyakori típusai a következők:

  • egységtesztek
  • paraméteres tesztek, amelyek több bemeneti típussal rendelkező függvényeket fednek le,
  • komponenstesztek, hogy az egyes tesztösszetevők külön maradjanak, és
  • mock tesztelés a kód más szolgáltatásokkal kommunikáló részeinek ellenőrzésére anélkül, hogy a teszt hatókörét kibővítenénk, és ezzel magukat a szolgáltatásokat is bevonnánk.

Ezek a tesztek a megírt belső kódon alapulnak, míg a fekete dobozos tesztek a termék külső funkcionális követelményein alapulnak.

cél

A cél ezekkel a tesztekkel az, hogy magas szintű tesztelési lefedettséget érjen el a kódon. Aktívan nyomon kell követnie ezt a lefedettséget, és hogy hol vannak hiányosságok. Ahogy további teszteket ad hozzá, amelyek több kódútvonalat gyakorolnak, nő a kód biztonsága és megbízhatósága iránti általános bizalom.

Visual Studio

A Visual Studio tesztkezelő eszközei megkönnyítik a tesztek gyakori futtatását, és gyorsan visszajelzést kaphatnak az átadási/sikertelenségi arányokról és a meghibásodási helyekről. A tesztelési keretrendszerek nagy része támogatja a CodeLens funkcióit is, így a teszt állapota a teszt helyén jelenik meg, ami megkönnyíti a tesztcsomag hozzáadását és karbantartását. A Tesztböngésző megkönnyíti a tesztek kezelését is, így tesztcsoportokat, egyéni tesztlistákat, szűrést, rendezést, keresést és egyebeket tesz lehetővé.

További információkért lásd:

A Visual Studio a kódlefedettség nyomon követésére szolgáló eszközöket is tartalmaz. Ezek az eszközök lehetővé teszik annak biztosítását, hogy a kód módosításait a meglévő tesztek lefedik, vagy új teszteket adjon hozzá az új és a nem tesztelt kódútvonalak lefedéséhez. Az eszközök a kódlefedettség százalékos arányát is megjelenítik, így biztosítható, hogy a kód a célszint felett maradjon a teljes kódminőség megbízhatósága érdekében.

További információ ezekről az eszközökről: Kódlefedettségi tesztelés – Visual Studio (Windows)

Az Azure-ban

Az Azure DevOps segíthet a teljes termék kódlefedettségi eredményeinek nyomon követésében a buildelési folyamat részeként. További információ: Kódlefedettség áttekintése – Azure Pipelines.

2.8 Korábbi tesztelési esetek

Összefoglalás

Az előzménytesztes esetek, más néven regressziós tesztesetek megakadályozzák, hogy a régi problémák újra felszabadulnak, és növeljék a termék teljes tesztelési lefedettségét. Győződjön meg arról, hogy hiba kijavításakor a projekt egy megfelelő tesztesetet is hozzáad. Idővel a javítások során a tesztelési csomag általános robusztussága folyamatosan javulni fog, ami jobb megbízhatósági és biztonsági garanciákat nyújt.

Főbb tulajdonságok és más szakaszokhoz való viszony

Mivel hibaregressziókat tesztelnek, ezeknek a teszteknek gyorsnak és könnyen futtathatónak kell lenniük, hogy a kódalapú tesztesetekkel együtt fussanak, és hozzájáruljanak a termék teljes kódlefedettségéhez. Ezzel együtt az ügyfelek valós példáinak felhasználásával új teszteseteket inspirálhat, nagyszerű módszer a tesztek lefedettségének és minőségének javítására.

Visual Studio

A Visual Studio segítségével egyszerűen adhat hozzá teszteket a csomaghoz, miközben elvégzi a hiba kijavításához szükséges módosításokat, és gyorsan futtathatja a teszteket és a kódlefedettségeket, hogy minden új esetet figyelembe lehessen venni. A hibakövetési rendszer hibaazonosítójának hivatkozása a kódban, ahol a tesztet írja, jó módszer a regressziós tesztek és a kapcsolódó problémák összekapcsolására. Inkább használja az Azure Board-okat és a tesztcsomagokat a Visual Studióval együtt:

  • tesztek, tesztelési esetek és problémák társítása; és
  • a probléma összes aspektusának és a hozzá tartozó teszteknek a nyomon követése.

További információkért lásd:

Végül ezeket a teszteket integrálva az egységtesztelési területre, amely elvileg lefedi a kódszakaszt, segít a tesztcsomag rendszerezett és könnyebben kezelhető állapotában. A Test Explorer tesztcsoportosítását használva hatékonyan követheti nyomon az összetartozó teszteket. További információ: Egységtesztek futtatása a Test Explorerrel – Visual Studio (Windows)

2.9 Elfedés

Összefoglalás A fuzzing (más néven fuzz-tesztelés) egy automatizált szoftvertesztelési technika, amely érvénytelen, váratlan vagy véletlenszerű adatokat ad meg egy program bemeneteként. A programot ezután figyelik az olyan kivételek szempontjából, mint az összeomlások, a hibás beépített vagy a fordító által injektált kódigények és a lehetséges memóriaszivárgások.

Útmutató

Használjon elfuzzingot minden olyan szoftveren, amely feldolgozhatja a támadó által szabályozható nem megbízható bemeneteket. Ha új alkalmazást és a hozzá tartozó tesztcsomagot készít, a lehető leghamarabb adja meg a fő modulokra vonatkozó fuzzingot. A szoftveren első alkalommal futó fuzzing szinte mindig feltárja a korábban ismeretlen biztonsági réseket. Ha elkezdi a buzzingot, soha ne hagyja abba.

Kapcsolat más szakaszokhoz

Amikor a fuzzing hibát jelez, mindig biztosít egy reprodukálható tesztesetet, amely bemutatja a hibát. Ez a teszteset reprodukálható, feloldható, majd hozzáadható az előzménytesztes esetekhez.

Ha mindkét szanitizáló eszközt, például az Address Sanitizert (ASan) és a fuzzingot használja:

  • Először futtassa a normál teszteket engedélyezett szaniterekkel, hogy lássa, vannak-e problémák, majd ha a kód szanitertiszta, kezdje el a fuzzingot.
  • C vagy C++ esetén vannak olyan fordítók, amelyek automatizálják a futtatókörnyezeti állítások és a metaadatok injektálását, amelyek lehetővé teszik az ASan használatát. Az ASan számára lefordítva az eredményül kapott bináris fájlok egy futtatókörnyezeti kódtárra mutatnak, amely pontosan képes a memóriabiztonsági hibák 15+ kategóriájának pontos diagnosztizálására nulla hamis pozitív értékkel. C vagy C++ esetén, ha rendelkezik forrással, használja a LibFuzzert, amely megköveteli az ASan engedélyezését.
  • A Java, C#, Python, Rust stb. nyelven írt kódtárakhoz használja az AFL++ keretrendszert.

Főbb tulajdonságok

  • A Fuzzing gyakran elmulasztott biztonsági réseket talál a statikus programelemzés, a teljes körű funkciótesztelés és a manuális kódvizsgálat során.
  • A szoftveres biztonsági és megbízhatósági hibák keresésének hatékony módja a Fuzzing, olyannyira, hogy a Microsoft biztonsági fejlesztési életciklusához minden termék nem megbízható felületén meg kell fuzzingot használni (lásd még a fenyegetésmodellezést).
  • Mindig használjon fuzzingot olyan szoftverekhez, amelyek esetleg nem megbízható bemeneteket dolgoznak fel.
  • A Fuzzing hatékony a nagyméretű adatelemzőkkel rendelkező önálló alkalmazások esetében.

Azure és GitHub CI/CD

Módosítsa a build(ek)et a LibFuzzert vagy az AFL++-t használó végrehajtható fájlok folyamatos létrehozásához. Az olyan szolgáltatásokban, mint az OSS-Fuzz, további számítási erőforrásokat adhat hozzá a fuzzinghoz.

2.10 Webalkalmazások vizsgálata

Összefoglalás

A Windowson futó Microsoft C++ hatókörén belül a Microsoft a következőket javasolja:

  • Részesítsd előnyben a TypeScriptet, a JavaScriptet és az ASP.NET-et a webalkalmazásokhoz.
  • Ne írjon webkiterjesztéseket a C++-ban. A Microsoft elavultnak nyilvánította az ActiveX-et.
  • Amikor a kódot Emscripten/WASM-be fordítják, már nem tekinthető C++-nak, és más eszközöket alkalmaznak.
  • A Microsoft a RESTlert, egy állapotalapú REST API-t biztosít.

Áttekintés és főbb tulajdonságok

A webalkalmazás-képolvasó a webalkalmazásokat a weblapjain való bejárással vizsgálja meg, és megvizsgálja a biztonsági réseket. Ez a bejárás magában foglalja a rosszindulatú bemenetek automatikus létrehozását és az alkalmazás válaszainak kiértékelését. Kritikus fontosságú, hogy a webalkalmazások vizsgálata kiterjedjen/támogatott legyen:

  • Katalógusba foglalja a hálózat összes webalkalmazását, beleértve az újakat és az ismeretleneket is, és néhány alkalmazástól több ezerig skálázható.
  • A mobileszközök által használt szoftververziók, SOAP- és REST API-szolgáltatások és API-k részletes vizsgálata.
  • Biztonsági primitívek beszúrása alkalmazásfejlesztésbe és üzembe helyezésbe DevOps-környezetekben. Ezek a primitívek a kúszórendszerrel működnek.
  • Kártevők észlelése.

2.11 A mellékelt szoftverösszetevők ellenőrzése

Összefoglalás

A C++ kódot ugyanúgy kezelje, mint a más programozási nyelveken írt kódot, és alkalmazza a vállalat által a C++ kódra alkalmazott szoftverösszetétel-elemzési (SCA) és origin analysis (OA) eszközöket. A munkafolyamatokat és a biztonsági vizsgálatokat a CI/CD (folyamatos integráció és folyamatos teljesítés) rendszerek részeként kell megtervezni.

Felsőbb rétegbeli védelem

A felsőbb rétegbeli függőségek elleni támadások kockázatának csökkentése érdekében a külső forrásokat/összetevőket egy nagyvállalati irányítású eszközön kell tárolni, amelyen SCA- és OA-eszközök futnak.

  • Az eszközöknek be kell vizsgálniuk és figyelmeztetni kell a biztonsági réseket (beleértve a nyilvános adatbázisokat is), például: Kezdőlap | CVE
  • Végezzen el statikus kódelemzést az alkalmazás/adattár összes szoftverkomponensén a sebezhető kódminták azonosítása érdekében.

Függőségvédelem

Végezze el és tartsa karban a függőségek naplózását annak ellenőrzéséhez, hogy az SCA- és OA-eszközök minden ilyen előfordulást elszámolnak és lefednek.

  • Az összetevőket rendszeresen naplózni kell, és frissíteni kell a legújabb ellenőrzött verziókra.
  • Csomagadatfolyam-függőségek.
  • Az SCA/OA-eszközök lefedik és ellenőrzik az egyetlen forrásból származó összes csomagfüggőséget.

SBOM

SBOM -t (szoftveres anyagjegyzéket) készíthet, amelyben a termék felsorolja az összes függőséget, például:

  • forrás (például URL -cím (egységes erőforráskereső))
  • verzió
  • konzisztencia (például SHA-256-forráskivonat), valamint a konzisztencia érvényesítésének egyéb eszközei, például a determinisztikus buildek.
  • SBOM-fájlok megkövetelése és naplózása szoftverfüggőségekben, vagy egy build részeként, beleértve az OSS-t (nyílt forráskódú szoftverek).
  • A Microsoft szabványosítja az SPDX (Software Package Data Exchange) 2.2-es vagy újabb verzióját, és javasolja | Linux Foundation mint SBOM dokumentumformátum.
  • A build determinizmus használható a bitszintű azonos bináris fájlok önálló előállítására és az integritás független ellenőrzésére:
    • A reprodukálhatóság első vagy harmadik féltől származó igazolása
    • Más technikák, például a megbízható tanúsítványforráson keresztüli bináris aláírás is biztosíthatja a bináris integritást.

További erőforrások

A Microsoft-megoldások a következő útmutatást és termékeket tartalmazzák:

  • Last updated on