Share via

Vytváření spolehlivých a zabezpečených programů C++

  • Článek

USA vládní publikace NISTIR 8397: Pokyny k minimálním standardům pro ověřování softwaru pro vývojáře obsahují vynikající pokyny k vytváření spolehlivého a zabezpečeného softwaru v jakémkoli programovacím jazyce.

Tento dokument se řídí stejnou strukturou jako NISTIR 8397. Každá část:

  • shrnuje, jak používat vývojářské produkty Microsoftu pro C++ a další jazyky, aby splňovaly potřeby zabezpečení dané části, a
  • poskytuje pokyny k získání maximální hodnoty v každé oblasti.

2.1 Modelování hrozeb

Souhrn

Modelování hrozeb je cenný proces, zejména při použití způsobem, který se škáluje tak, aby vyhovoval vašim potřebám vývoje a který snižuje šum.

Doporučení

Modelování hrozeb by mělo být jednou součástí vašeho dynamického životního cyklu vývoje zabezpečení (SDL). Doporučujeme, aby pro váš produkt jako celek, pro konkrétní funkci nebo pro zásadní změnu návrhu nebo implementace:

  • Mít solidní, dynamický SDL, který umožňuje včasné zapojení vývojářských týmů a přístupových práv.
  • Použijte modelování hrozeb cíleným způsobem. Využijte modelování hrozeb u všech funkcí, ale takticky začněte vystavenými, složitými nebo kritickými funkcemi. Použijte ji pravidelně jako součást kontroly produktu shora dolů.
  • Modelování hrozeb můžete použít na začátku (stejně jako u všech požadavků na zabezpečení), pokud stále existuje příležitost změnit návrh. Modely hrozeb také slouží jako vstup do jiných procesů, jako je snížení prostoru pro útoky nebo návrh zabezpečení. Modely hrozeb, které se vytvoří později, jsou nejlepší "průzkumy" pro testování perem (penetrační testování) nebo oblasti, které potřebují testování zabezpečení, jako je přibližné testování. Jakmile vytvoříte základní model hrozeb, naplánujte, že budete pokračovat v iteraci, jakmile se prostor útoku změní.
  • Pomocí inventáře prostředků a dodržování předpisů můžete odpovídajícím způsobem sledovat, co tvoří produkt, a sledovat artefakty zabezpečení (včetně modelů hrozeb) spolu s prostředky, na které se vztahují. Tento přístup umožňuje lepší automatizované posuzování rizik a zaměření úsilí o zabezpečení na konkrétní komponenty nebo funkce, které se mění.
  • V Azure byl nástroj Microsoft Threat Modeling Tool aktualizován v roce 2022 pro vývoj pro Azure. Další informace najdete v tématu Microsoft Threat Modeling Tool – přehled – Azure

Podpůrné faktory a postupy

Abychom správně použili modelování hrozeb a vyhnuli se nedostatečnému využití nebo nadměrnému využití, zjistili jsme, že je potřeba nejprve vyřešit následující základní koncepty.

Přístup k vývoji

Nejprve porozumíte přístupu k vývoji týmu. Pro týmy s pracovními postupy agilního vývoje, které každý den tlačí desítky změn do produkčního prostředí, není praktické ani rozumné vyžadovat aktualizaci modelu hrozeb pro každou funkční změnu. Místo toho při psaní funkčních požadavků funkce zvažte zahrnutí dotazníku požadavků na zabezpečení. Dotazník by se měl zaměřit na konkrétní otázky týkající se funkce, aby bylo možné určit, jaké budoucí aspekty SDL se vztahují. Příklad:

  • Dělá tato funkce zásadní změnu návrhu způsobu, jakým poskytujeme izolaci zákazníků ve víceklientských prostředích? Pokud ano, zvažte provedení úplného modelu hrozeb.
  • Povoluje nová funkce nahrávání souborů? Pokud ano, možná je vhodnější posouzení zabezpečení webových aplikací.
  • Jedná se především o změnu funkčního uživatelského rozhraní? Pokud ano, možná není potřeba nic nad rámec tradičního automatizovaného nástroje.

Výsledky dotazníku zabezpečení informují, které techniky SDL se mají svázat s jakou jednotkou vývoje. Informuje také vývojové partnery o časových osách SDL této funkce, aby mohli spolupracovat ve správných časech.

Inventář produktů

Za druhé, udržujte si inventář silných aktiv produktů, na které máte za úkol vyhodnotit. Produkty se zvětšují složitostí. Běžně se píše software pro připojená zařízení, která mají:

  • senzory (jako jsou osobní kolej a vozidla),
  • sběrnicové sítě, které komunikují s dalšími součástmi ve vozidle (například CANBUS nebo PROFIBUS),
  • bezdrátová/mobilní/Bluetooth pro komunikaci se zákaznickými zařízeními a cloudovými back-endy,
  • strojové učení v cloudu, které se vrací zpět do zařízení nebo aplikace pro správu vozového parku,
  • a ještě víc.

V takových složitých produktech je modelování hrozeb velmi důležité. Když máte inventář silných prostředků, můžete zobrazit celý zásobník produktů, abyste viděli kompletní obrázek a viděli klíčová místa, která je potřeba vyhodnotit, jak nová nebo změněná funkce ovlivňuje zabezpečení produktů.

Členitost a integrace

Vytvořte systémy pro měření dodržování předpisů pomocí jasných metrik.

  • Pravidelně měří dodržování předpisů pro vývoj na úrovni funkcí. Dodržování předpisů funkcí by se obecně mělo měřit s vyšší frekvencí a menší členitostí, někdy i v systému vývojáře nebo v době potvrzení nebo sloučení kódu.
  • Pravidelně vyhodnocujte zabezpečení pro širší produkt, ve kterém se využívá funkce nebo součást. Širší vyhodnocení se obvykle provádí s nižší frekvencí a širší členitostí, například v době testování modulu nebo systému.

Měřítko

Udržujte správný systém inventáře prostředků, který zachycuje a zachovává artefakty zabezpečení a výstup kontrol modelů hrozeb. Díky jasnému inventáři můžete vyhodnotit výstupy vzorů a provádět inteligentní rozhodnutí o tom, jak program zabezpečení produktů pravidelně upřesňovat.

Zkuste kombinovat dotazníky zabezpečení fáze požadavků, výsledky modelování hrozeb, výsledky posouzení zabezpečení a výsledky z automatizovaných nástrojů. Když je zkombinujete, můžete automatizovat zobrazení relativního rizika daného produktu, ideálně jako "řídicí panel", aby týmy zabezpečení informovaly, na co se zaměřit, aby získaly nejlepší hodnotu z modelování hrozeb.

2.2 Automatizované testování

Souhrn

Automatizované testy představují důležitý způsob, jak zajistit kvalitu a bezpečnost kódu. Jedná se o nedílnou součást podpory dalších oblastí uvedených v tomto dokumentu, jako je modelování hrozeb. Když jsou spárované s jinými postupy zabezpečeného kódování, pomáhají chránit před chybami a ohroženími zabezpečení, které se zavádějí do základu kódu.

Klíčové atributy

Testy by měly být spolehlivé, konzistentní a izolované. Tyto testy by měly zahrnovat co nejvíce kódu. Všechny nové funkce a opravy chyb by měly mít odpovídající testy, aby se zajistilo dlouhodobé zabezpečení a spolehlivost kódu, pokud je to možné. Pravidelně spouštět automatizované testy a v co nejvíce prostředích, aby se zajistilo jejich spuštění a pokrytí všech oblastí:

  • První místo, kde by se měly spouštět, je na počítači, který provádí změny. Spouštění testů se nejsnážněji provádí v integrovaném vývojovém prostředí (IDE), které se používá k úpravám, nebo jako skript na příkazovém řádku při provádění změn vývojářem.
  • Dalším místem, kde by se měly spouštět, je součástí procesu potvrzení nebo sloučení žádosti o přijetí změn.
  • Posledním místem ke spuštění testů je kanál kontinuální integrace a průběžného nasazování (CI/CD) nebo sestavení kandidáta na vydání.

Rozsah testů by se měl v každém kroku zvýšit, přičemž poslední krok poskytuje úplné pokrytí všeho, co ostatní kroky nemusí chybět.

Průběžné používání a údržba

Spolehlivost testů je důležitou součástí zachování efektivity testovací sady. Chyby testů by se měly přiřazovat a prošetřit s potenciálními problémy se zabezpečením, které mají vysokou prioritu a aktualizují se v rámci výzvy a předem určeného časového rámce. Ignorování selhání testů by nemělo být běžným postupem, ale mělo by vyžadovat silné odůvodnění a schválení. Chyby testů způsobené problémy v samotné sadě testů by se měly považovat za stejné jako u jiných selhání, aby nedošlo k výpadku pokrytí, ve kterém by mohly chybět problémy s produktem.

Druhy testů, zejména testy jednotek

Existuje několik typů automatizovaných testů, ale ne všechny jsou použitelné pro všechny aplikace, dobrá testovací sada obsahuje výběr několika různých typů. Testovací případy založené na kódu, jako jsou testy jednotek, jsou nejběžnější a nejvíce integrální, které platí pro všechny aplikace a záměrně pokrývají co nejvíce cest kódu pro správnost. Tyto testy by měly být malé, rychlé a nemají vliv na stav počítače, aby bylo možné rychle a často spustit úplnou sadu testů. Pokud je to možné, spusťte testy na mnoha počítačích s různými nastaveními hardwaru, abyste zachytili problémy, které nejsou reprodukovatelné na jednom typu počítače.

Visual Studio

Visual Studio Test Explorer nativně podporuje řadu nejoblíbenějších testovacích architektur jazyka C++ a nabízí možnosti instalace rozšíření pro více architektur. Tato flexibilita je užitečná při spouštění podmnožiny testů, které pokrývají kód, na kterém pracujete, a usnadňuje ladění selhání testů při jejich vzniku. Visual Studio také usnadňuje nastavení nových testovacích sad pro existující projekty a poskytuje užitečné nástroje, jako je CodeLens, které usnadňují správu těchto testů. Další informace o psaní, spouštění a správě testů C/C++ pomocí sady Visual Studio naleznete v tématu Zápis testů jednotek pro C/C++ – Visual Studio (Windows).

V Azure a GitHubu CI/CD

Testy, které provádějí hlubší ověření a jejich spouštění trvá déle, jako je statická analýza, detekce komponent atd., jsou vhodnými kandidáty pro testování žádostí o přijetí změn nebo průběžné testování integrace. Azure DevOps a GitHub Actions usnadňují automatické spouštění ověření a blokování kontrol kódu v případě selhání ověření. Automatizované vynucování pomáhá zajistit, aby byl veškerý vrácený kód zabezpečený na základě těchto přísnějších kontrol. Ověřování sestavení Azure Pipelines a Azure DevOps jsou popsané tady:

2.3 Analýza založená na kódu nebo statická analýza

Ve výchozím nastavení by měla být povolena souhrnná statická analýza nebo binární analýza, aby byla ve výchozím nastavení zabezpečená. Statická analýza analyzuje program za účelem zajištění požadované bezpečnosti a zásad zabezpečení v době, kdy se sestavuje, a ne v době spuštění, kdy může na počítači zákazníka dojít k zneužití. Statická analýza může analyzovat program ve formuláři zdrojového kódu nebo v kompilovaném spustitelném formuláři.

Doporučení microsoftu doporučuje:

  • Povolte statickou analýzu pro všechny programy jazyka C++ pro vstupní zdrojový kód (před kompilací) i spustitelné binární soubory (po kompilaci). Povolení může znamenat spuštění analýzy během každého sestavení na počítači vývojáře nebo jako samostatné sestavení pro pozdější kontrolu kódu nebo jako požadavek na vrácení se změnami.
  • Začlenit statickou analýzu do kanálů CI jako formu testování.
  • Statická analýza podle definice má falešně pozitivní výsledky a připravte se na začlenění této skutečnosti do smyčky zpětné vazby kvality. Buďte rychlí, abyste předem povolili všechna upozornění s nízkými falešně pozitivními výsledky. Pak buďte proaktivní, abyste postupně zvýšili počet pravidel, pro které váš základ kódu zkompiluje upozornění a provádí čištění, protože pravidelně přidáváte další pravidla, která označují důležité chyby na úkor postupně vyšších falešně pozitivních výsledků (napřed před vyčištěním základu kódu pro tato pravidla).
  • Vždy používejte nejnovější podporované verze sady Visual Studio a nastavte své technické prostředí tak, aby rychle využívalo nejnovější vydané verze oprav, jakmile budou k dispozici, aniž by se zpozdila další fáze vývoje nebo cyklus.

Klíčové nástroje Mějte na paměti a používejte následující:

Poznámky:

  • /analyze umožňuje statickou analýzu kódu C++ v době kompilace k identifikaci kritických ohrožení zabezpečení a spolehlivosti kódu. Měla by být povolena v celé časové ose vývoje programu C++. Začněte tím, že ve výchozím nastavení povolíte alespoň nativní doporučení Microsoftu jako minimální směrný plán. Pak se podívejte do dokumentace, kde najdete další pravidla, zejména pravidla C++ Core Guidelines vyžadovaná vašimi technickými zásadami. Funkce statické analýzy zdrojového kódu je k dispozici v integrovaném vývojovém prostředí Visual C++ i v nástrojích sestavení příkazového řádku.
  • /W4 a /WX měly by být povoleny všude, kde je to možné, abyste měli jistotu, že kód zkompilujete čistě na vysokých úrovních upozornění (W4) a zacházíte s upozorněními jako s chybami, které je potřeba opravit (WX). Tyto možnosti umožňují najít neinicializované chyby dat, které ostatní nástroje statické analýzy nemůžou zkontrolovat, protože chyby se zobrazí pouze po provedení back-endu kompilátoru s interproceduralovou analýzou a vložením.
  • Binární analýza BinSkim zajišťuje, že projekty umožňují širokou škálu funkcí zabezpečení. BinSkim generuje soubory PDB a další výstupy, které usnadňují ověření řetězu opatrovnictví a efektivní reakci na problémy se zabezpečením. Společnost Microsoft doporučuje spustit nástroj BinSkim k analýze všech spustitelných binárních souborů (.sys.dllnebo.exe) vytvořených pro nebo spotřebované vašimi programy. Uživatelská příručka BinSkim obsahuje seznam podporovaných standardů zabezpečení. Microsoft doporučuje opravit všechny problémy hlášené jako chyby nástrojem BinSkim. Problémy hlášené jako "upozornění" by se měly vyhodnotit selektivně, protože jejich řešení může mít vliv na výkon nebo nemusí být nutné.

V Azure a GitHub CI/CD Microsoft doporučuje vždy povolit zdrojový kód a binární statickou analýzu ve scénářích CI/CD vydaných verzí. Okamžitě spusťte zdrojovou analýzu na počítači místního vývojáře nebo alespoň pro každé potvrzení nebo žádost o přijetí změn, abyste co nejdříve zachytili zdrojové chyby a minimalizovali celkové náklady. Chyby binární úrovně se obvykle zavádějí pomaleji, takže může být dostačující ke spuštění binární analýzy v méně častých scénářích CI/CD (například nočních nebo týdenních buildů).

2.4 Kontrola pevně zakódovaných tajných kódů

Souhrn

Nezakódujte tajné kódy v rámci softwaru. Tajné kódy ze zdrojového kódu můžete efektivně najít a odebrat pomocí spolehlivých nástrojů, které můžou prohledávat celý základ zdrojového kódu. Jakmile najdete tajné kódy, přesuňte je na bezpečné místo podle pokynů pro zabezpečené ukládání a používání tajných kódů.

Problém

"Tajné kódy" znamená entity, které zřídí identitu a poskytují přístup k prostředkům nebo které se používají k podepisování nebo šifrování citlivých dat. Mezi příklady patří hesla, klíče úložiště, připojovací řetězec a privátní klíče. Je lákavé uchovávat tajné kódy v softwarovém produktu, aby bylo možné je snadno získat v případě potřeby softwarem. Tyto pevně zakódované tajné kódy ale můžou vést k závažným nebo katastrofickým incidentům zabezpečení, protože jsou snadno zjištěny a dají se použít k ohrožení vaší služby a dat.

Prevence

Tajné kódy pevně zakódované ve zdrojovém kódu (jako prostý text nebo šifrovaný objekt blob) představují ohrožení zabezpečení. Tady jsou obecné pokyny, jak se vyhnout tajným kódům ve zdrojovém kódu:

  • Pomocí nástroje precheckin můžete před odesláním do správy zdrojového kódu zkontrolovat a zachytit potenciální pevně zakódované tajné kódy.
  • Nezadávejte do zdrojového kódu ani konfiguračních souborů nezařaďte přihlašovací údaje s prostým textem.
  • Neukládejte v SharePointu, OneNotu, sdílených složkách a podobně přihlašovací údaje pro vymazání textu. Nebo je můžete sdílet prostřednictvím e-mailu, rychlých zpráv atd.
  • Nezašifrujte tajný kód pomocí snadno zjistitelného dešifrovacího klíče. Například neukládejte soubor PFX spolu se souborem, který obsahuje heslo.
  • Nezašifrujte tajný kód pomocí slabého dešifrování. Například nešifrujte soubor PFX slabým nebo běžným heslem.
  • Vyhněte se vkládání šifrovaných přihlašovacích údajů do zdrojového kódu. Místo toho použijte zástupné symboly ve zdroji a nechte systém nasazení nahradit je tajnými kódy ze schválených úložišť.
  • Stejné principy použijte u tajných kódů v prostředích, jako jsou testování, příprava atd., stejně jako v produkčních nasazeních. Nežádoucí uživatelé často cílí na neprodukční systémy, protože jsou méně dobře spravované, a pak je používají k přecházení do produkčního prostředí.
  • Nesdílejte tajné kódy mezi nasazeními (například testování, příprava, produkční prostředí).

I když přímo nesouvisí s pevně zakódovanými tajnými kódy, nezapomeňte také zabezpečit tajné kódy pro váš test, vývoj a produkci:

  • Tajné kódy pravidelně obměňujte a kdykoliv byly vystaveny. Schopnost obměňovat/znovu nasadit tajné kódy je důkazem zabezpečeného systému. Zejména absence této schopnosti je ještě silnější důkazy o nevyhnutelném ohrožení zabezpečení.
  • Nepřidávejte běžným důvodům vývojáře, že "moje testovací přihlašovací údaje nevytváří riziko". V praxi téměř vždy dělají.
  • Zvažte přesun od tajných kódů (například hesel, nosných klíčů) zcela ve preferencích řešení řízených RBAC nebo identitou jako vhodného technického řešení, které může zcela stupňovit správu tajných kódů.

Detekce

Starší komponenty vašeho produktu můžou ve zdrojovém kódu obsahovat skryté pevně zakódované tajné kódy. Někdy se tajné kódy z desktopových počítačů vývojářů můžou vylít do vzdálené větve a sloučit je do větve vydané verze, takže tajné kódy nechtěně unikají. Pokud chcete zjistit tajné kódy, které mohou být skryty ve zdrojovém kódu, můžete použít nástroje, které můžou kód prohledávat pevně zakódované tajné kódy:

Nápravy

Když se ve zdrojovém kódu nacházejí přihlašovací údaje, okamžitá nutnost zneplatnit vystavený klíč a provést analýzu rizik na základě expozice. I když váš systém potřebuje zůstat spuštěný, můžete povolit správce tajných kódů pro nápravu pomocí těchto kroků:

  1. Pokud náprava umožňuje přepnutí na spravované identity nebo vyžaduje vyřazení správce tajných kódů, jako je Azure Key Vault (AKV), udělejte to jako první. Pak znovu nasaďte aktualizovanou identitu nebo klíč.
  2. Zneplatnění vystaveného tajného kódu.
  3. Proveďte auditování nebo posouzení rizik potenciálních škod z důvodu ohrožení zabezpečení.

Pokud chcete chránit kryptografické klíče a další tajné kódy používané cloudovými aplikacemi a službami, použijte azure Key Vault s příslušnými zásadami přístupu.

Pokud expozice ohrožuje určitá zákaznická data nebo PII, může vyžadovat jiné požadavky na dodržování předpisů nebo vytváření sestav.

Odeberte teď neplatné tajné kódy ze zdrojového kódu a nahraďte je alternativními metodami, které tajné kódy nezpřístupňují přímo ve zdrojovém kódu. Hledejte příležitosti k odstranění tajných kódů tam, kde je to možné, pomocí nástrojů, jako je Azure AD. Metody ověřování můžete aktualizovat tak, aby využívaly spravované identity prostřednictvím Azure Active Directory. K ukládání a správě tajných kódů, jako je Azure Key Vault (AKV), používejte jenom schválené úložiště. Další informace naleznete v tématu:

Azure DevOps (AzDO)

Uživatelé AzDO můžou kód prohledat prostřednictvím GitHub Advanced Security pro Azure DevOps (GHAzDO). GHAzDO také umožňuje uživatelům zabránit tajným expozicím tím, že povolí nabízenou ochranu ve svých úložištích a zachytí potenciální expozice před tím, než dojde k úniku. Další informace o zjišťování pevně zakódovaných tajných kódů v kódu v Azure DevOps najdete v tématu Kontrola tajných kódů pro Azure DevOps advanced Security pro Azure DevOps v každém z následujících odkazů:

Na GitHubu

Kontrola tajných kódů je k dispozici na GitHub.com ve dvou formách:

  • Výstrahy kontroly tajných kódů pro partnery Spustí se automaticky ve všech veřejných úložištích. Všechny řetězce, které odpovídají vzorům poskytnutým partnery pro kontrolu tajných kódů, se oznamují přímo příslušnému partnerovi.
  • Upozornění kontroly tajných kódů pro uživatele Můžete povolit a nakonfigurovat další vyhledávání úložišť vlastněných organizacemi, které používají GitHub Enterprise Cloud a mají licenci pro GitHub Advanced Security. Tyto nástroje také podporují privátní a interní úložiště.

GitHub poskytuje známé vzory tajných kódů pro partnery a uživatele, které je možné nakonfigurovat tak, aby vyhovovaly vašim potřebám. Další informace najdete tady:

Poznámka:

GitHub Advanced Security pro Azure DevOps přináší stejné řešení pro kontrolu tajných kódů, kontrolu závislostí a řešení kontroly kódu CodeQL, která jsou už dostupná pro uživatele GitHubu, a nativně je integruje do Azure DevOps, aby chránila vaše úložiště Azure Repos a Pipelines.

Další materiály

2.5 Spuštění s kontrolami a ochranou poskytovanými jazykem a operačním systémem

Souhrn

Binární posílení zabezpečení se provádí použitím kontrolních mechanismů zabezpečení v době kompilace. Patří mezi ně zmírnění rizik, která:

  • zabránit zneužitelným ohrožením zabezpečení v kódu,
  • povolte detekce za běhu, které aktivují ochranu zabezpečení při zneužití, a
  • povolením produkčního prostředí a archivace dat můžete omezit poškození způsobené incidenty zabezpečení.

Binární příjemci se musí přihlásit k funkcím zabezpečení Systému Windows, aby získali plnou výhodu posílení zabezpečení.

Microsoft poskytuje sadu zařízení specifických pro projekty C++, které vývojářům pomáhají psát a dodávat bezpečnější a bezpečnější kód. Vývojáři C++ by také měli dodržovat standardy zabezpečení společné pro jazyky, které generují spustitelný kód. Microsoft udržuje BinSkim, veřejný binární nástroj pro kontrolu operačního systému, který pomáhá vynucovat použití mnoha ochrany popsaných v této části. Další informace o BinSkim naleznete v uživatelské příručce binskim | Github

Ovládací prvky na binární úrovni se liší podle toho, kde se používají v technickém procesu. Měli byste rozlišovat mezi možnostmi kompilátoru a linkeru, které: jsou přísně zkompilované, měnit generování kódu s režií za běhu a měnit generování kódu, aby bylo dosaženo kompatibility s ochranou operačního systému.

Vývojářská nastavení by měla upřednostnit co nejvíce statické analýzy, umožnit produkci privátních dat, aby se urychlilo ladění atd. Buildy vydaných verzí by měly být vyladěné na odpovídající kombinaci zabezpečení, výkonu a dalších aspektů generování kódu. Procesy vydávání verzí musí být nakonfigurované tak, aby správně generovaly a spravovaly veřejné a soukromé data sestavení (například veřejné nebo soukromé symboly).

Zůstaňte aktuální: Vždy používejte aktuální kompilátory a nástroje.

Zkompilujte veškerý kód pomocí aktuálních sad nástrojů, abyste mohli využívat aktuální jazykovou podporu, statickou analýzu, generování kódu a bezpečnostní prvky. Vzhledem k tomu, že kompilátory ovlivňují každou vygenerovanou komponentu, je potenciál regrese aktualizace nástroje relativně vysoký. Použití zastaralých kompilátorů vytváří konkrétní riziko pro nápravnou akci při reakci na incident zabezpečení, protože týmy nemusí mít dostatek času na upgrade kompilátorů. Microsoft doporučuje, aby týmy vyvinuly zařízení, aby pravidelně aktualizovaly a testoval aktualizace kompilátoru.

Použití zabezpečených metod vývoje, jazykových verzí, architektur a rozhraní API

Kód by měl využívat vývojové metodologie, jazykové verze, architekturu, rozhraní API atd., které minimalizují riziko tím, že podporují bezpečnost a jednoduchost v jazyce C++, včetně:

Využívání zabezpečených závislostí

Binární soubory by neměly odkazovat na nezabezpečené knihovny a závislosti. Vývojové týmy by měly sledovat všechny externí závislosti a řešit ohrožení zabezpečení v těchto komponentách pomocí aktualizace na bezpečnější verze, pokud se na ně vztahují.

Maximalizace záruky provenience kódu a efektivita reakce na zabezpečení

Kompilace by měla umožňovat záruky silné provenience kódu, které pomáhají rozpoznat a zabránit zavedení zadních vrátek a dalších škodlivých kódů. Výsledná data, která jsou také důležitá pro ladění a šetření, by se měla archivovat pro všechny verze softwaru, aby se v případě ohrožení zabezpečení řídila efektivní reakce na zabezpečení. Následující přepínače kompilátoru generují informace, které jsou důležité pro odpověď zabezpečení:

  • /ZH:SHA_SHA256 v jazyce Visual C++ – zajišťuje, aby se kryptograficky zabezpečený algoritmus použil ke generování všech hodnot hash zdrojového souboru PDB.
  • /Zi, /ZI (Formát informací o ladění) v jazyce Visual C++ – Kromě publikování prokládaných symbolů pro shromažďování chybových dat a dalších scénářů veřejného použití se ujistěte, že sestavení vytvářejí a archivují privátní soubory PDB pro všechny vydané binární soubory. Binární nástroje pro analýzu vyžadují úplné symboly k ověření, jestli bylo v době kompilace povoleno mnoho omezení zabezpečení. Soukromé symboly jsou kritické v reakci na zabezpečení a nižší náklady na ladění a vyšetřování, když se technici snaží vyhodnotit a omezit poškození v případě, že dojde k zneužití.
  • /SOURCELINK In Visual C++ Linker - Include Sourcelink file in PDB: Source link is a language- and source-control agnostic system providing source debugging for binaries. Ladění zdroje výrazně zvyšuje efektivitu rozsahu předběžných ověření zabezpečení a reakce na incidenty po vydání.

Povolení chyb kompilátoru, aby se zabránilo problémům při vytváření kódu

Kompilace by měla povolit kontroly kompilátoru relevantní pro zabezpečení jako chyby způsobující chyby, například:

Označení binárních souborů jako kompatibilních se zmírněními rizik zabezpečení modulu runtime operačního systému

Nastavení kompilátoru a linkeru by se mělo přihlásit k funkcím generování kódu, které detekují a snižují spuštění škodlivého kódu, včetně:

Zabránění zpřístupnění citlivých informací

Nastavení kompilátoru by se mělo přihlásit k prevenci zjišťování citlivých informací. V posledních letech výzkumní pracovníci odhalili neúmyslný únik informací, který pochází z hardwarových funkcí, jako je spekulativní spuštění.

Na úrovni softwaru můžou být důvěrná data přenášena útočníkům, pokud dojde k neočekávanému úniku. Selhání inicializace vyrovnávacích pamětí bez inicializace a jiné zneužití vyrovnávací paměti může útočníkům, kteří volají důvěryhodné rozhraní API, uniknout privátním důvěrným datům. Tato třída problému nejlépe zvládá povolením dodatečné statické analýzy a používáním zabezpečených kontejnerů prostředků, jak je popsáno výše.

  • /Qspectre - Zmírnění spekulativních útoků na spuštění na straně kanálu – vloží pokyny k bariérám, které pomáhají zabránit zpřístupnění citlivých dat vytvořených spekulativním spuštěním. Tato omezení rizik by měla být povolena pro kód, který ukládá citlivá data do paměti a funguje v rámci hranice důvěryhodnosti. Microsoft vždy doporučuje měřit dopad na výkon s příslušnými srovnávacími testy při povolování omezení rizik Spectre kvůli možnosti zavedení kontrol za běhu v kritických blocích nebo smyčkách výkonu. Tyto cesty kódu můžou zakázat zmírnění rizik prostřednictvím modifikátoru spectre(nomitigation)declspec . Projekty, které umožňují funkci /Qspectre, by také měly propojit knihovny, které jsou také zkompilovány s těmito omezeními rizik, včetně knihoven modulu runtime Microsoftu.

2.6 Testovací případy černé skříňky

Souhrn

Testy černé skříňky nespoléhá na znalost vnitřních fungování testované komponenty. Testy černé skříňky jsou navržené tak, aby testily kompletní funkce funkcí v produktu na libovolné vrstvě nebo úrovni. Testy černé skříňky můžou být funkční testy, testy uživatelského rozhraní, testy výkonnosti a integrační testy. Testy černé skříňky jsou cenné pro měření obecné spolehlivosti a funkční správnosti a zajištění toho, aby se produkt chová podle očekávání.

Vztah k jiným oddílům

Tyto typy testů založených na požadavcích jsou užitečné pro ověření předpokladů provedených v modelu hrozeb a pokrytí potenciálních hrozeb, které jsou uvedeny v této části. Tyto testy jsou užitečné pro testování integrace mezi samostatnými součástmi produktu, zejména těch, které jsou přes hranice důvěryhodnosti, jak je popsáno v modelu hrozeb. Testovací případy černé skříňky jsou také užitečné pro testování všech druhů hraničních případů pro ověření vstupu uživatele. Testování známých hraničních případů a případů chyb jsou užitečné. Fuzzing je také užitečný k testování méně zřejmé případy.

Automatizace a regrese

Tyto testy spusťte pravidelně a porovnejte výsledky s předchozími spuštěními, abyste zachytili zásadní změny nebo regrese výkonu. Spuštění těchto testů na mnoha různých počítačích a instalačních nastaveních vám může pomoct pokrýt všechny problémy, které můžou vzniknout z různých architektur nebo změn instalace.

Výpisy stavu systému

Tyto testy pomáhají najít problémy se spolehlivostí a schopnost testovat mnoho různých scénářů, které můžou narazit na chybové ukončení, zablokování, zablokování atd. Shromažďováním výpisů stavu systému v rámci selhání testů můžete výpisy paměti importovat přímo do sady Visual Studio, abyste mohli dále prozkoumat, na jaké části kódu dochází k těmto problémům. Pokud spouštíte funkční testy v sadě Visual Studio, můžete snadno replikovat a ladit selhání tím, že přesně zjistíte, kde v černém rámečku test selže, a můžete rychle otestovat opravy.

Pokud chcete začít s laděním testů, přečtěte si téma Ladění testů jednotek pomocí Průzkumníka testů – Visual Studio (Windows)

V Azure

Azure DevOps může také pomoct spravovat a ověřovat tyto testy pomocí testovacích plánů. Tyto testy lze použít k zajištění schválení ručním ověřením a ke spouštění automatizovaných testů přidružených k požadavkům na produkt. Další informace o plánech Azure Test a jejich použití ke spuštění automatizovaného testování najdete tady:

2.7 Testovací případy založené na kódu

Souhrn

Testovací případy založené na kódu jsou nedílnou součástí údržby zabezpečení a spolehlivosti vašeho produktu. Tyto testy by měly být malé a rychlé a neměly by mít na sebe vliv, aby mohly běžet paralelně. Testy založené na kódu jsou pro vývojáře snadné spouštět místně na svém vývojovém počítači, kdykoli v kódu provádějí změny, aniž by se museli starat o zpomalení vývojového cyklu.

Typy a vztah k jiným oddílům

Mezi běžné typy testovacích případů založených na kódu patří:

  • testy jednotek,
  • parametrizované testy pro pokrytí funkcí s více vstupními typy,
  • testy komponent pro zachování samostatných součástí jednotlivých testovacích komponent a
  • Napodobení testování pro ověření částí kódu, které komunikují s jinými službami, aniž by se rozšířil rozsah testu tak, aby zahrnoval samotné služby.

Tyto testy jsou založeny na interním kódu, který je napsán, zatímco testy černé skříňky jsou založeny na externích funkčních požadavcích produktu.

Cílem

Prostřednictvím těchto testů je cílem dosáhnout vysoké úrovně pokrytí testů nad vaším kódem. Toto pokrytí byste měli aktivně sledovat a kde existují mezery. Když přidáte další testy, které budou vykonávat více cest kódu, zvýší se celková spolehlivost zabezpečení a spolehlivosti kódu.

Visual Studio

Nástroje Průzkumníka testů v sadě Visual Studio usnadňují spouštění těchto testů často a rychle získají zpětnou vazbu o úspěšnosti a neúspěšných umístěních a umístěních selhání. Mnoho testovacích architektur podporuje také funkce CodeLens, které vidí stav testu v umístění samotného testu, což usnadňuje přidávání a údržbu sady testů. Průzkumník testů také usnadňuje správu těchto testů, což umožňuje skupiny testů, vlastní seznamy stop testů, filtrování, řazení, vyhledávání a další možnosti.

Další informace naleznete v tématu:

Součástí sady Visual Studio jsou také nástroje pro sledování pokrytí kódu. Tyto nástroje umožňují zajistit, aby změny kódu, které provedete, byly pokryty existujícími testy, nebo přidat nové testy pro pokrytí nových a neotestovaných cest kódu. Nástroje také zobrazují procento pokrytí kódu, aby se zajistilo, že se udržuje nad cílovou úrovní, abyste měli jistotu v celkové kvalitě kódu.

Informace o těchto nástrojích naleznete v tématu Testování pokrytí kódu – Visual Studio (Windows)

V Azure

Azure DevOps může také pomoct se sledováním výsledků pokrytí kódu pro celý produkt v rámci procesu kanálu buildu. Další informace najdete v tématu Kontrola pokrytí kódu – Azure Pipelines.

2.8 Historické testovací případy

Souhrn

Historické testovací případy, označované také jako regresní testovací případy, brání starým problémům v opětovném povrchu a zvyšují celkové pokrytí testu produktu. Měli byste zajistit, aby při opravení chyby projekt přidal také odpovídající testovací případ. Vzhledem k tomu, že se v průběhu času provádí opravy, celková robustnost testovací sady se bude dál zlepšovat a poskytuje lepší záruky spolehlivosti a zabezpečení.

Klíčové vlastnosti a vztah k jiným oddílům

Vzhledem k tomu, že testují regrese chyb, měly by být tyto testy rychlé a snadno spustitelné, aby mohly běžet společně s [testovacími případy založenými na kódu] a přispívat k celkovému pokrytí kódu produktu. Spolu s tím je použití skutečných příkladů od zákazníků k inspiraci nových testovacích případů skvělým způsobem, jak zlepšit pokrytí a kvalitu testů.

Visual Studio

Visual Studio umožňuje snadno přidávat testy do sady a provádět změny pro opravu chyby a rychle spouštět testy a pokrytí kódu, aby se zajistilo, že se budou všechny nové případy brát v úvahu. Odkazování na ID chyby ze systému sledování problémů v kódu, ve kterém test napíšete, je dobrým způsobem, jak připojit regresní testy k odpovídajícím problémům. Preferujte použití plánů Azure Boards a testování společně se sadou Visual Studio:

  • přidružit testy, testovací případy a problémy; A
  • sledovat všechny aspekty problému a odpovídající testy.

Další informace naleznete v tématu:

Nakonec integrace těchto testů do oblasti testování jednotek, která by měla pokrýt oddíl kódu, pomáhá udržovat sadu testů uspořádanou a snadněji spravovat. Pomocí seskupení testů Průzkumníka testů můžete efektivně sledovat testy, které patří dohromady. Další informace najdete v tématu Spouštění testů jednotek pomocí Průzkumníka testů – Visual Studio (Windows)

2.9 Fuzzing

Souhrnná fuzzing (označovaná také jako přibližné testování) je automatizovaná technika testování softwaru, která zahrnuje poskytnutí neplatných, neočekávaných nebo náhodných dat jako vstupu do programu. Program se pak monitoruje pro výjimky, jako jsou chyby, selhání předdefinované nebo kompilátor vložené kontrolní výrazy kódu a potenciální nevracení paměti.

Pokyny

Používejte přibližné přibližné informace ve všech softwarech, které by mohly zpracovávat nedůvěryhodné vstupy, které by útočník mohl ovládat. Pokud vytváříte novou aplikaci a její přidruženou testovací sadu, co nejdříve zahrňte klíčové moduly. Spouštění přibližných shod poprvé na kusu softwaru téměř vždy odhalí skutečná ohrožení zabezpečení, která byla dříve neznámá. Jakmile začnete fuzzing, nikdy nezastavte.

Vztah k jiným oddílům

Při hlášení selhání vždy přirozeně poskytuje reprodukovatelný testovací případ, který ukazuje chybu. Tento testovací případ lze reprodukovat, vyřešit a pak přidat do historických testovacích případů.

Při použití obou sanitizátorů, jako je Adresa Sanitizer (ASan) a přibližné:

  • Nejprve spusťte běžné testy s povolenými sanitizátory, abyste zjistili, jestli nedošlo k problémům, a pak jakmile je kód sanitizer-clean start fuzzing.
  • Pro jazyk C nebo C++ existují kompilátory, které automatizují injektáž kontrolních výrazů modulu runtime a meta-data, které umožňují ASan. Při kompilaci pro ASan jsou výsledné binární soubory propojeny s knihovnou modulu runtime, která dokáže přesně diagnostikovat 15+ kategorie chyb bezpečnosti paměti s nulovými falešně pozitivními výsledky. Pro C nebo C++ pokud máte zdroj, použijte Knihovnu LibFuzzer, která vyžaduje povolení ASan jako první.
  • Pro knihovny napsané v Javě, C#, Pythonu, Rustu a tak dále použijte architekturu AFL++.

Klíčové vlastnosti

  • Funkce Fuzzing najde chyby zabezpečení, které analýza statického programu často zmeškala, vyčerpávající testování funkcí a ruční kontrola kódu.
  • Fuzzing je efektivní způsob, jak najít chyby zabezpečení a spolehlivosti v softwaru, takže životní cyklus vývoje zabezpečení společnosti Microsoft vyžaduje přibližné přibližné přibližné hodnoty v každém nedůvěryhodném rozhraní každého produktu (viz také Modelování hrozeb).
  • Vždy používejte fuzzing pro software, který může zpracovávat nedůvěryhodné vstupy.
  • Fuzzing je efektivní pro samostatné aplikace s velkými analyzátory dat.

Ci/CD v Azure a GitHubu

Upravte sestavení tak, aby podporovala průběžné vytváření spustitelných souborů, které používají Knihovnu LibFuzzer nebo AFL++. Můžete přidat další výpočetní prostředky potřebné pro fuzzing u služeb, jako je OSS-Fuzz nebo OneFuzz.

2.10 Vyhledávání webových aplikací

Souhrn

V rámci programu Microsoft Visual C++ ve Windows společnost Microsoft doporučuje:

  • Upřednostněte TypeScript, JavaScript a ASP.NET pro webové aplikace.
  • Nezapisujte webová rozšíření v jazyce C++. Microsoft přestal používat technologie ActiveX.
  • Když je kód zkompilován do Emscripten/WASM, už se nepoužívá jazyk C++ a další nástroje.
  • Microsoft poskytuje RESTler, stavový fuzzer rozhraní REST API.

Přehled a klíčové vlastnosti

Skener webových aplikací zkoumá webovou aplikaci procházením jeho webových stránek a zkoumá ohrožení zabezpečení. Tato aktualizace zahrnuje automatické generování škodlivých vstupů a vyhodnocení odpovědí aplikace. Kontrola webových aplikací musí v kritickém případě zahrnovat/ podporovat:

  • Kataloguje všechny webové aplikace ve vaší síti, včetně nových a neznámých a škáluje se z několika aplikací na tisíce.
  • Hloubkové prohledávání verzí softwaru, služeb SOAP a REST API a rozhraní API používaných mobilními zařízeními
  • Vložení primitiv zabezpečení do vývoje a nasazení aplikací v prostředích DevOps Tyto primitivy pracují s prohledávacím modulem.
  • Detekce malwaru.

2.11 Kontrola zahrnutých softwarových komponent

Souhrn

Zpracujte kód C++ stejně jako kód napsaný v jiných programovacích jazycích a použijte všechny nástroje pro analýzu softwaru (SCA) a origin Analysis (OA), které vaše společnost přijala, na váš kód C++. Pracovní postupy a kontroly zabezpečení by měly být navrženy jako součást systémů CI/CD (kontinuální integrace a průběžné doručování).

Upstreamová obrana

Aby se zmírnit riziko útoků na upstreamové závislosti, měly by být zdroje a komponenty třetích stran uložené na aktivu řízeném podnikem, na kterém běží nástroje SCA a OA.

  • Nástroje by měly kontrolovat a upozorňovat na identifikaci ohrožení zabezpečení (včetně veřejných databází), například: Domů | CVE
  • Spusťte statickou analýzu všech softwarových komponent, které jsou součástí vaší aplikace nebo úložiště, a identifikujte ohrožené vzory kódu.

Obrana závislostí

Proveďte a udržujte audit závislostí, abyste ověřili, že všechny tyto výskyty jsou zohledněny a pokryty vašimi nástroji SCA a OA.

  • Komponenty by se měly pravidelně auditovat a aktualizovat na nejnovější ověřené verze.
  • Závislosti informačního kanálu balíčků.
  • Nástroje SCA/OA pokrývají a audituje všechny závislosti balíčků, které pocházejí z jednoho informačního kanálu.

SBOM

Vytvořte SBOM (softwarové vyúčtování materiálů) se seznamem všech závislostí, jako jsou:

  • origin (například ADRESA URL (Uniform Resource Locator))
  • version
  • konzistence (například hash zdroje SHA-256) a další prostředky pro ověřování konzistence, jako jsou deterministické buildy.
  • Vyžadovat a auditovat soubory SBOM v softwarových závislostech nebo generovaných jako součást sestavení, včetně OSS (opensourcového softwaru).
  • Společnost Microsoft standardizuje aktualizaci SPDX (Software Package Data Exchange) verze 2.2 nebo novější | Linux Foundation jako formát dokumentu SBOM.
  • Determinismus sestavení lze použít k nezávislému vytváření bitových identických binárních souborů a k zajištění nezávislých ověření integrity:
    • Ověření reprodukovatelnosti první strany nebo třetí strany
    • Jiné techniky, jako je binární podepisování prostřednictvím důvěryhodného zdroje certifikátů, mohou také poskytnout určité záruky binární integrity.

Další materiály

Řešení Microsoftu zahrnují následující doprovodné materiály a produkty: