Share via

Tworzenie niezawodnych i bezpiecznych programów w języku C++

  • Artykuł

Publikacja Stany Zjednoczone dla instytucji rządowych NISTIR 8397: Wytyczne dotyczące minimalnych standardów weryfikacji oprogramowania dla deweloperów zawierają doskonałe wskazówki dotyczące tworzenia niezawodnego i bezpiecznego oprogramowania w dowolnym języku programowania.

Ten dokument jest zgodny z tą samą strukturą co NISTIR 8397. Każda sekcja:

  • Podsumowuje sposób używania produktów deweloperskich firmy Microsoft dla języka C++ i innych języków w celu spełnienia wymagań dotyczących zabezpieczeń tej sekcji oraz
  • zawiera wskazówki, aby uzyskać największą wartość w każdym obszarze.

2.1 Modelowanie zagrożeń

Podsumowanie

Modelowanie zagrożeń jest cennym procesem, szczególnie w przypadku zastosowania w sposób, który skaluje się w celu zaspokojenia potrzeb programistycznych i zmniejsza hałas.

Zalecenia

Modelowanie zagrożeń powinno być jedną z części dynamicznego cyklu projektowania zabezpieczeń (SDL). Zalecamy, aby produkt jako całość, dla konkretnej funkcji lub dla głównej zmiany projektu lub implementacji:

  • Mieć solidny, dynamiczny język SDL, który umożliwia wczesne zaangażowanie zespołów deweloperów i prawa do podejścia.
  • Stosowanie modelowania zagrożeń w sposób ukierunkowany. Zastosuj modelowanie zagrożeń do wszystkich funkcji, ale taktycznie zacznij od uwidocznionych, złożonych lub krytycznych funkcji. Zamiast tego należy regularnie stosować go w ramach przeglądu produktu najwyższego poziomu.
  • Zastosuj modelowanie zagrożeń na wczesnym etapie (podobnie jak w przypadku wszystkich wymagań dotyczących zabezpieczeń), gdy nadal istnieje możliwość zmiany projektu. Ponadto modele zagrożeń służą jako dane wejściowe do innych procesów, takich jak zmniejszenie obszaru ataków lub projektowanie pod kątem bezpieczeństwa. Utworzone później modele zagrożeń są w najlepszym przypadku "ankietami" na potrzeby testów penetracyjnych (testów penetracyjnych) lub obszarów wymagających testowania zabezpieczeń, takich jak rozmycie. Po utworzeniu modelu zagrożenia według planu bazowego zaplanuj kontynuowanie iteracji w miarę zmian obszaru podatnego na ataki.
  • Użyj spisu zasobów i zgodności, aby odpowiednio śledzić, co składa się na produkt, oraz śledzić artefakty zabezpieczeń (w tym modele zagrożeń) wraz z zasobami, do których mają zastosowanie. Takie podejście umożliwia lepszą zautomatyzowaną ocenę ryzyka i skupienie się na wysiłkach związanych z zabezpieczeniami określonych składników lub funkcji, które się zmieniają.
  • Na platformie Azure narzędzie do modelowania zagrożeń firmy Microsoft zostało zaktualizowane w 2022 r. na potrzeby programowania na platformie Azure. Aby uzyskać więcej informacji, zobacz Omówienie narzędzia Microsoft Threat Modeling Tool — Azure

Czynniki pomocnicze i praktyki

Aby prawidłowo zastosować modelowanie zagrożeń i uniknąć nadmiernego korzystania z nich, odkryliśmy, że należy najpierw rozwiązać następujące podstawowe pojęcia.

Podejście programistyczne

Najpierw należy zrozumieć podejście programistyczne zespołu. W przypadku zespołów z elastycznymi przepływami pracy programowania, które codziennie wypychają dziesiątki zmian w środowisku produkcyjnym, nie jest praktyczne ani uzasadnione wymaganie aktualizacji modelu zagrożeń dla każdej zmiany funkcjonalnej. Zamiast tego od początku podczas pisania wymagań funkcjonalnych funkcji należy rozważyć dołączenie kwestionariusza wymagań dotyczących zabezpieczeń. Kwestionariusz powinien skupić się na konkretnych pytaniach dotyczących funkcji, aby określić, jakie przyszłe aspekty języka SDL mają zastosowanie. Na przykład:

  • Czy ta funkcja wprowadza istotną zmianę w projektowaniu sposobu zapewniania izolacji klienta w środowisku wielodostępnym? Jeśli tak, rozważ wykonanie pełnego modelu zagrożeń.
  • Czy nowa funkcja zezwala na przekazywanie plików? Jeśli tak, być może bardziej odpowiednia jest ocena zabezpieczeń aplikacji internetowej.
  • Czy ta zmiana polega przede wszystkim na zmianie funkcjonalnego interfejsu użytkownika? Jeśli tak, być może nic nie jest potrzebne poza tradycyjnym zautomatyzowanym narzędziem.

Wyniki kwestionariusza zabezpieczeń informują, które techniki SDL mają wiązać się z którą jednostką rozwoju. Informuje również partnerów programistycznych o osiach czasu SDL funkcji, aby mogli współpracować w odpowiednim czasie.

Spis produktów

Po drugie, należy zachować silny spis zasobów produktów, których zadaniem jest ocena. Produkty rosną w złożoności. Często można pisać oprogramowanie dla połączonych urządzeń, które mają:

  • czujniki (takie jak szyna pasażerska i pojazdy),
  • sieci oparte na autobusach, które komunikują się z innymi składnikami pojazdu (takimi jak CANBUS lub PROFIBUS),
  • bezprzewodowe/komórkowe/Bluetooth do komunikacji z urządzeniami klienckimi i zapleczami w chmurze,
  • uczenie maszynowe w chmurze przekazujące z powrotem do urządzenia lub aplikacji do zarządzania flotą,
  • Wiele innych funkcji

W takich złożonych produktach modelowanie zagrożeń ma kluczowe znaczenie. Posiadanie silnego spisu zasobów umożliwia wyświetlenie całego stosu produktów, aby wyświetlić pełny obraz, oraz zobaczyć kluczowe miejsca, które należy ocenić pod kątem wpływu nowej lub zmienionej funkcji na bezpieczeństwo produktu.

Stopień szczegółowości i integracji

Ustanów systemy do mierzenia zgodności przy użyciu przejrzystych metryk.

  • Regularnie mierz zgodność na potrzeby tworzenia aplikacji na poziomie funkcji. Zgodność funkcji zwykle powinna być mierzona z większą częstotliwością i mniejszym stopniem szczegółowości, czasami nawet w systemie dewelopera lub w czasie zatwierdzania/scalania kodu.
  • Okresowo oceniaj zabezpieczenia szerszego produktu, w którym jest zużywana funkcja lub składnik. Szersze oceny są zwykle wykonywane z niższą częstotliwością i szerszym stopniem szczegółowości, na przykład w czasie testowania modułowego lub systemowego.

Skaluj

Zachowaj odpowiedni system spisu zasobów, który przechwytuje i zachowuje artefakty zabezpieczeń oraz dane wyjściowe przeglądów modelu zagrożeń. Posiadanie jasnego spisu umożliwia ocenę wyników przeglądu wzorców i podejmowanie inteligentnych decyzji dotyczących regularnego uściślenia programu zabezpieczeń produktu.

Spróbuj połączyć kwestionariusze zabezpieczeń fazy wymagań, wyniki modelowania zagrożeń, wyniki oceny zabezpieczeń i wyniki z narzędzi automatycznych. Połączenie ich umożliwia zautomatyzowanie punktu widzenia względnego ryzyka danego produktu, najlepiej jako "pulpitu nawigacyjnego", aby poinformować zespoły ds. zabezpieczeń, na czym należy skupić się, aby uzyskać najlepszą wartość z modelowania zagrożeń.

2.2 Automatyczne testowanie

Podsumowanie

Testy automatyczne są ważnym sposobem zapewnienia jakości i bezpieczeństwa kodu. Są one integralną częścią obsługi innych obszarów wymienionych w tym dokumencie, takich jak modelowanie zagrożeń. W połączeniu z innymi bezpiecznymi praktykami kodowania pomagają chronić przed usterkami i lukami w zabezpieczeniach wprowadzanymi do bazy kodu.

Atrybuty klucza

Testy powinny być niezawodne, spójne i izolowane. Te testy powinny obejmować jak najwięcej kodu. Wszystkie nowe funkcje i poprawki błędów powinny mieć odpowiednie testy, aby zapewnić długoterminowe bezpieczeństwo i niezawodność kodu, gdy jest to możliwe. Regularnie uruchamiaj testy automatyczne i w jak największej liczbą środowisk, aby upewnić się, że są uruchamiane i że obejmują wszystkie obszary:

  • Pierwsze miejsce, na których należy uruchomić, znajduje się na maszynie, która wprowadza zmiany. Uruchamianie testów jest najłatwiej wykonywane w środowisku IDE używanym do edycji lub jako skrypt w wierszu polecenia, gdy deweloper wprowadza zmiany.
  • Następnym miejscem, w jakim powinny zostać uruchomione, jest proces zatwierdzania/scalania żądania ściągnięcia.
  • Ostatnim miejscem do uruchamiania testów jest potok ciągłej integracji i ciągłego wdrażania (CI/CD) lub kompilacji kandydata wydania.

Zakres testów powinien wzrosnąć w każdym kroku, a ostatni krok zapewnia pełne pokrycie wszystkich innych kroków.

Ciągłe używanie i konserwacja

Niezawodność testów jest ważną częścią utrzymania skuteczności zestawu testów. Błędy testów powinny być przypisywane i badane, a potencjalne problemy z zabezpieczeniami mają wysoki priorytet i są aktualizowane w określonym przedziale czasu. Ignorowanie niepowodzeń testów nie powinno być powszechną praktyką, ale powinno wymagać silnego uzasadnienia i zatwierdzenia. Niepowodzenia testów z powodu problemów w samym zestawie testów powinny być traktowane tak samo jak inne błędy, aby zapobiec wygaśnięciu zasięgu, w którym problemy z produktem mogą zostać pominięte.

Rodzaje testów, zwłaszcza testów jednostkowych

Istnieje kilka typów testów automatycznych, a mimo że nie wszystkie mają zastosowanie do wszystkich aplikacji, dobry zestaw testów zawiera wybór kilku różnych typów. Przypadki testowe oparte na kodzie, takie jak testy jednostkowe, są najbardziej typowe i najbardziej integralne, mają zastosowanie do wszystkich aplikacji i celowo obejmują jak najwięcej ścieżek kodu, jak to możliwe dla poprawności. Te testy powinny być małe, szybkie i nie mają wpływu na stan maszyny, dzięki czemu pełny zestaw testów może być uruchamiany szybko i często. Jeśli to możliwe, uruchom testy na wielu maszynach, które mają różne konfiguracje sprzętowe, aby przechwytywać problemy, które nie są odtwarzalne na jednym typie maszyny.

Program Visual Studio

Eksplorator testów programu Visual Studio natywnie obsługuje wiele najpopularniejszych platform testowania języka C++ i oferuje opcje instalowania rozszerzeń dla większej liczby struktur. Ta elastyczność jest przydatna w przypadku uruchamiania podzestawu testów obejmujących kod, nad którym pracujesz, i ułatwia debugowanie niepowodzeń testów w miarę ich wystąpienia. Program Visual Studio ułatwia również konfigurowanie nowych zestawów testów dla istniejących projektów i udostępnia przydatne narzędzia, takie jak CodeLens, aby ułatwić zarządzanie tymi testami. Aby uzyskać więcej informacji na temat pisania, uruchamiania i zarządzania testami C/C++ w programie Visual Studio, zobacz Pisanie testów jednostkowych dla języka C/C++ — Visual Studio (Windows).

Na platformie Azure i ciągłej integracji/ciągłego wdrażania w usłudze GitHub

Testy, które wykonują dokładnszą weryfikację i trwają dłużej, takie jak analiza statyczna, wykrywanie składników itd., są dobrymi kandydatami do testowania żądań ściągnięcia lub ciągłego testowania integracji. Usługi Azure DevOps i GitHub Actions ułatwiają automatyczne uruchamianie walidacji i blokowanie kontroli kodu w przypadku niepowodzenia walidacji. Automatyczne wymuszanie pomaga zagwarantować, że cały kod zaewidencjonowany jest bezpieczny na podstawie tych bardziej rygorystycznych testów, które są uruchamiane. Usługi Azure Pipelines i Weryfikacja kompilacji usługi Azure DevOps zostały opisane tutaj:

2.3 Analiza oparta na kodzie lub statyczna

Podsumowanie Statyczna analiza kodu/danych binarnych powinna być domyślnie włączona, aby być domyślnie zabezpieczona. Analiza statyczna analizuje program pod kątem wymaganych zasad bezpieczeństwa i zabezpieczeń w momencie jego skompilowania, a nie w czasie wykonywania, gdy na maszynie klienta może wystąpić luki w zabezpieczeniach. Analiza statyczna może analizować program w postaci kodu źródłowego lub w skompilowanym formularzu wykonywalnego.

Rekomendacje firma Microsoft zaleca:

  • Włącz analizę statyczną dla wszystkich programów języka C++, zarówno dla wejściowego kodu źródłowego (przed kompilacją) jak i plików binarnych wykonywalnych (po kompilacji). Opcja "Włącz" może oznaczać uruchamianie analizy podczas każdej kompilacji na maszynie dewelopera lub jako oddzielnej kompilacji w celu sprawdzenia kodu później lub jako wymagania kontrolnego.
  • Dołączanie analizy statycznej do potoków ciągłej integracji jako formy testowania.
  • Analiza statyczna według definicji zawiera wyniki fałszywie dodatnie i przygotuj się do uwzględnienia tego faktu w pętli opinii o jakości. Szybkie włączanie wszystkich ostrzeżeń o niskiej wartości fałszywie dodatniej z góry. Następnie należy aktywnie zwiększać liczbę reguł, dla których baza kodu kompiluje ostrzeżenie czyszczone, regularnie dodawaj więcej reguł, które flagują ważne usterki kosztem stopniowego wyższego wyniku fałszywie wyższego (początkowo przed wyczyszczeniem bazy kodu dla tych reguł).
  • Zawsze używaj najnowszych obsługiwanych wersji programu Visual Studio i skonfiguruj środowisko inżynieryjne, aby szybko korzystać z najnowszych wersji poprawek, gdy tylko staną się dostępne, bez opóźnień w następnym etapie programowania/cyklu.

Kluczowe narzędzia Należy pamiętać o następujących elementach i ich użyć:

Uwagi:

  • /analyze umożliwia statyczną analizę kodu C++ w czasie kompilacji w celu zidentyfikowania krytycznych luk w zabezpieczeniach i niezawodności kodu. Powinno ono być włączone na całej osi czasu programowania w języku C++. Zacznij od włączenia co najmniej opcji "Microsoft Native Recommended" domyślnie jako minimalnej linii bazowej. Następnie zapoznaj się z dokumentacją dotyczącą sposobu określania większej liczby reguł, zwłaszcza reguł podstawowych wytycznych języka C++, zgodnie z wymaganiami zasad inżynieryjnych. Funkcja analizy statycznej kodu źródłowego jest dostępna zarówno w środowisku IDE Visual C++, jak i w narzędziach kompilacji wiersza polecenia.
  • /W4 i /WX powinny być włączone wszędzie tam, gdzie to możliwe, aby zapewnić skompilowanie kodu w sposób czysty na wysokich poziomach ostrzeżeń (W4) i traktować ostrzeżenia jako błędy, które muszą zostać naprawione (WX). Te opcje umożliwiają znajdowanie niezainicjowanych błędów danych, których nie można sprawdzić za pomocą innych narzędzi do analizy statycznej, ponieważ błędy stają się widoczne tylko po wykonaniu międzyprocedowej analizy i tworzenia wbudowanych elementów zaplecza kompilatora.
  • Analiza binarna BinSkim zapewnia, że projekty umożliwiają szeroką gamę funkcji zabezpieczeń. BinSkim generuje pliki PDB i inne dane wyjściowe, które ułatwiają weryfikowanie łańcucha nadzoru i efektywne reagowanie na problemy z zabezpieczeniami. Firma Microsoft zaleca uruchomienie narzędzia BinSkim w celu przeanalizowania wszystkich plików binarnych wykonywalnych (.sys.dlllub .exe) utworzonych lub używanych przez programy. Podręcznik użytkownika BinSkim zawiera listę obsługiwanych standardów zabezpieczeń. Firma Microsoft zaleca rozwiązanie wszystkich problemów zgłaszanych jako "błędy" przez narzędzie BinSkim. Problemy zgłaszane jako "ostrzeżenia" powinny być oceniane selektywnie, ponieważ ich rozwiązanie może mieć wpływ na wydajność lub może nie być konieczne.

W przypadku platformy Azure i ciągłej integracji/ciągłego wdrażania w usłudze GitHub firma Microsoft zaleca zawsze włączanie kodu źródłowego i binarnej analizy statycznej w scenariuszach ciągłej integracji/ciągłego wdrażania. Uruchom analizę źródłową natychmiast na komputerze dewelopera lokalnego lub co najmniej dla każdego zatwierdzenia lub żądania ściągnięcia, aby jak najszybciej przechwycić usterki źródłowe i zminimalizować ogólne koszty. Błędy na poziomie binarnym zwykle są wprowadzane wolniej, więc może wystarczyć do uruchomienia analizy binarnej w mniej częstych scenariuszach ciągłej integracji/ciągłego wdrażania (takich jak kompilacje nocne lub tygodniowe).

2.4 Przegląd dla zakodowanych na stałe wpisów tajnych

Podsumowanie

Nie koduj wpisów tajnych w oprogramowaniu. Wpisy tajne można znaleźć i usunąć z kodu źródłowego wydajnie, korzystając z niezawodnych narzędzi, które umożliwiają skanowanie całej bazy kodu źródłowego. Po znalezieniu wpisów tajnych przenieś je do bezpiecznego miejsca zgodnie z wytycznymi dotyczącymi bezpiecznego przechowywania i używania wpisów tajnych.

Problem

"Wpisy tajne" oznaczają jednostki, które ustanawiają tożsamość i zapewniają dostęp do zasobów lub które są używane do podpisywania lub szyfrowania poufnych danych. Przykłady obejmują hasła, klucze magazynu, parametry połączenia i klucze prywatne. Kuszące jest przechowywanie wpisów tajnych w produkcie oprogramowania, dzięki czemu można je łatwo uzyskać w razie potrzeby przez oprogramowanie. Jednak te zakodowane na stałe wpisy tajne mogą prowadzić do poważnych lub katastroficznych zdarzeń zabezpieczeń, ponieważ są one łatwo wykrywane i mogą służyć do naruszenia bezpieczeństwa usługi i danych.

Zapobieganie

Wpisy tajne zakodowane w kodzie źródłowym (jako zwykły tekst lub zaszyfrowany obiekt blob) są luką w zabezpieczeniach. Poniżej przedstawiono ogólne wskazówki dotyczące unikania wpisów tajnych w kodzie źródłowym:

  • Użyj narzędzia precheckin, aby skanować i przechwytywać potencjalne zakodowane na stałe wpisy tajne w kodzie przed przesłaniem do kontroli źródła.
  • Nie umieszczaj poświadczeń zwykłego tekstu w kodzie źródłowym lub plikach konfiguracji.
  • Nie przechowuj poświadczeń zwykłego tekstu w programach SharePoint, OneNote, udziałach plików itd. Lub udostępnij je za pośrednictwem poczty e-mail, wiadomości błyskawicznych itd.
  • Nie szyfruj wpisu tajnego za pomocą łatwego odnajdywania klucza odszyfrowywania. Na przykład nie należy przechowywać pliku PFX wraz z plikiem zawierającym jego hasło.
  • Nie szyfruj wpisu tajnego przy użyciu słabego odszyfrowywania. Na przykład nie szyfruj pliku PFX przy użyciu słabego lub wspólnego hasła.
  • Unikaj umieszczania zaszyfrowanych poświadczeń w kodzie źródłowym. Zamiast tego użyj symboli zastępczych w źródle i pozwól systemowi wdrażania zastąpić je wpisami tajnymi z zatwierdzonych magazynów.
  • Zastosuj te same zasady do wpisów tajnych w środowiskach, takich jak testowanie, przemieszczanie itd., tak jak w przypadku wdrożeń produkcyjnych. Przeciwnicy często atakują systemy nieprodukcyjne, ponieważ są mniej dobrze zarządzane, a następnie używają ich do przejścia do środowiska produkcyjnego.
  • Nie udostępniaj wpisów tajnych między wdrożeniami (na przykład testowanie, przemieszczanie, produkcja).

Chociaż nie są bezpośrednio związane z zakodowanymi wpisami tajnymi, pamiętaj również o zabezpieczaniu wpisów tajnych na potrzeby testowania, programowania i produkcji:

  • Okresowo obracaj swoje wpisy tajne i zawsze, gdy mogły zostać ujawnione. Posiadanie zademonstrowanej możliwości rotacji/ponownego wdrażania wpisów tajnych jest dowodem bezpiecznego systemu. W szczególności brak tej możliwości jest jeszcze silniejszym dowodem nieuniknionej luki w zabezpieczeniach.
  • Nie daj się typowym uzasadnieniem dla deweloperów, że "moje poświadczenia testowe nie tworzą ryzyka". W praktyce prawie zawsze to robią.
  • Rozważ odejście od wpisów tajnych (na przykład haseł, kluczy nośnych) całkowicie w preferencjach rozwiązań opartych na kontroli dostępu opartej na rolach/tożsamości jako dobrego rozwiązania inżynieryjnego, które może całkowicie uniemożliwić zarządzanie wpisami tajnymi.

Wykrycie

Starsze składniki produktu mogą zawierać ukryte zakodowane na stałe wpisy tajne w kodzie źródłowym. Czasami wpisy tajne z komputerów stacjonarnych deweloperów mogą wkraść się do gałęzi zdalnej i scalić je z gałęzią wydania, nieumyślnie wyciekając wpisy tajne. Aby odnaleźć wpisy tajne, które mogą ukrywać się w kodzie źródłowym, możesz użyć narzędzi, które umożliwiają skanowanie kodu pod kątem zakodowanych na stałe wpisów tajnych:

Korygowanie

Po znalezieniu poświadczeń w kodzie źródłowym natychmiastową potrzebą jest unieważnienie ujawnionego klucza i przeprowadzenie analizy ryzyka na podstawie ekspozycji. Nawet jeśli system musi pozostać uruchomiony, możesz włączyć menedżera wpisów tajnych na potrzeby korygowania, wykonując następujące kroki:

  1. Jeśli korygowanie zezwala na przełączanie do tożsamości zarządzanych lub wymaga usunięcia w menedżerze wpisów tajnych, takich jak usługa Azure Key Vault (AKV), wykonaj to najpierw. Następnie ponownie wdróż przy użyciu zaktualizowanej tożsamości lub klucza.
  2. Unieważnij ujawniony wpis tajny.
  3. Przeprowadzanie inspekcji/oceny ryzyka potencjalnych szkód spowodowanych naruszeniem zabezpieczeń.

Aby zabezpieczyć klucze kryptograficzne i inne wpisy tajne używane przez aplikacje i usługi w chmurze, użyj usługi Azure Key Vault z odpowiednimi zasadami dostępu.

Jeśli narażenie narusza niektóre dane klienta/dane osobowe, może to wymagać innych wymagań dotyczących zgodności/raportowania.

Usuń teraz unieważnione wpisy tajne z kodu źródłowego i zastąp je metodami alternatywnymi, które nie ujawniają wpisów tajnych bezpośrednio w kodzie źródłowym. Poszukaj możliwości wyeliminowania wpisów tajnych, jeśli to możliwe, przy użyciu narzędzi takich jak Usługa Azure AD. Możesz zaktualizować metody uwierzytelniania, aby korzystać z tożsamości zarządzanych za pośrednictwem usługi Azure Active Directory). Używaj tylko zatwierdzonych magazynów do przechowywania wpisów tajnych i zarządzania nimi, takich jak usługa Azure Key Vault (AKV). Aby uzyskać więcej informacji, zobacz:

Azure DevOps (AzDO)

Użytkownicy azDO mogą skanować swój kod za pomocą usługi GitHub Advanced Security for Azure DevOps (GHAzDO). GhAzDO umożliwia również użytkownikom zapobieganie ujawnieniom wpisów tajnych przez włączenie ochrony wypychanej w swoich repozytoriach, przechwytywanie potencjalnych ekspozycji przed ich wyciekiem. Aby uzyskać więcej informacji na temat wykrywania zakodowanych na stałe wpisów tajnych w kodzie w usłudze Azure DevOps, zobacz Secret Scanning for Github Advanced Security for Azure DevOps (Skanowanie wpisów tajnych dla usługi GitHub Advanced Security dla usługi Azure DevOps ) w każdym z następujących linków:

W usłudze GitHub

Skanowanie wpisów tajnych jest dostępne w GitHub.com w dwóch formach:

  • Alerty skanowania wpisów tajnych dla partnerów. Uruchamia się automatycznie we wszystkich repozytoriach publicznych. Wszystkie ciągi pasujące do wzorców dostarczonych przez partnerów skanowania wpisów tajnych są zgłaszane bezpośrednio do odpowiedniego partnera.
  • Alerty skanowania wpisów tajnych dla użytkowników. Możesz włączyć i skonfigurować dodatkowe skanowanie repozytoriów należących do organizacji korzystających z usługi GitHub Enterprise Cloud i mieć licencję usługi GitHub Advanced Security. Te narzędzia obsługują również repozytoria prywatne i wewnętrzne.

Usługa GitHub udostępnia znane wzorce wpisów tajnych dla partnerów i użytkowników, które można skonfigurować pod kątem Twoich potrzeb. Aby uzyskać więcej informacji, zobacz:

Uwaga

Usługa GitHub Advanced Security dla usługi Azure DevOps zapewnia takie samo skanowanie wpisów tajnych, skanowanie zależności i rozwiązania do skanowania kodu CodeQL, które są już dostępne dla użytkowników usługi GitHub i natywnie integruje je z usługą Azure DevOps w celu ochrony usług Azure Repos i Pipelines.

Dodatkowe zasoby

2.5 Uruchamianie przy użyciu kontroli i ochrony systemu operacyjnego

Podsumowanie

Wzmacnianie zabezpieczeń binarnych odbywa się przez zastosowanie mechanizmów kontroli zabezpieczeń w czasie kompilacji. Obejmują one środki zaradcze, które:

  • zapobieganie lukom w zabezpieczeniach z możliwością wykorzystania w kodzie,
  • włączanie wykrywania środowiska uruchomieniowego, które wyzwalają zabezpieczenia ochrony przed wykorzystaniem i
  • umożliwienie produkcji i archiwizowania danych, aby ograniczyć szkody spowodowane zdarzeniami bezpieczeństwa.

Użytkownicy binarni muszą zdecydować się na funkcje zabezpieczeń systemu Windows, aby uzyskać pełną korzyść ze wzmacniania zabezpieczeń.

Firma Microsoft udostępnia zestaw obiektów specyficznych dla projektów języka C++, które ułatwiają deweloperom pisanie i dostarczanie bezpieczniejszego i bezpieczniejszego kodu. Deweloperzy języka C++ powinni również przestrzegać standardów zabezpieczeń wspólnych dla języków, które generują kod wykonywalny. Firma Microsoft utrzymuje BinSkim, publiczny kontroler binarny systemu operacyjnego, który pomaga wymusić korzystanie z wielu zabezpieczeń opisanych w tej sekcji. Aby uzyskać więcej informacji na temat BinSkim, zobacz Podręcznik użytkownika Binskim | Github

Kontrolki na poziomie binarnym różnią się w zależności od tego, gdzie są stosowane w procesie inżynieryjnym. Należy rozróżnić opcje kompilatora i konsolidatora, które: są ściśle kompilowane, zmieniają generowanie kodu z obciążeniem czasu wykonywania i zmieniają generowanie kodu w celu zapewnienia zgodności z zabezpieczeniami systemu operacyjnego.

Ustawienia deweloperów powinny wolisz włączyć jak najwięcej analizy statycznej, umożliwić produkcję danych prywatnych w celu przyspieszenia debugowania itd. Kompilacje wydań powinny być dostosowane do odpowiedniej kombinacji zabezpieczeń, wydajności i innych problemów związanych z generowaniem kodu. Procesy wydawania muszą być skonfigurowane tak, aby prawidłowo generować dane kompilacji używane publicznie i zarządzać nimi (na przykład symbolami publicznymi i prywatnymi).

Bądź na bieżąco: zawsze używaj aktualnych kompilatorów i narzędzi

Skompiluj cały kod z bieżącymi zestawami narzędzi, aby korzystać z aktualnej obsługi języka, analizy statycznej, generowania kodu i mechanizmów kontroli zabezpieczeń. Ze względu na to, że kompilatory wpływają na każdy wygenerowany składnik, potencjał regresji aktualizacji narzędzi jest stosunkowo wysoki. Użycie przestarzałych kompilatorów stwarza szczególne zagrożenie dla akcji naprawczej podczas reagowania na zdarzenie zabezpieczeń, ponieważ zespoły mogą nie mieć wystarczająco dużo czasu na uaktualnienie kompilatorów. Firma Microsoft zaleca zespołom opracowywanie obiektu w celu regularnego odświeżania i testowania aktualizacji kompilatora.

Używanie bezpiecznych metod programowania, wersji językowych, struktur/interfejsów API

Kod powinien korzystać z metodologii programowania, wersji językowych, struktury, interfejsów API itd., które minimalizują ryzyko poprzez wspieranie bezpieczeństwa i prostoty w języku C++, w tym:

  • Aby uzyskać wskazówki dotyczące pisania nowoczesnego, bezpiecznego i spójnego kodu C++, który jest zgodny z najlepszymi rozwiązaniami i unika typowych pułapek, zobacz Podstawowe wytyczne dotyczące języka C++.
  • Zobacz Implementacja biblioteki Microsoft GSL dla funkcji i typów sugerowanych przez podstawowe wytyczne dotyczące języka C++.
  • Kontenery C++ bezpieczne dla zasobów, zabezpieczenia przepełnienia pamięci biblioteki środowiska uruchomieniowego języka C (CRT): Preferuj std::vector i std::string, które są bezpieczne dla zasobów. Jeśli musisz używać danych języka C, użyj bezpiecznych wersji funkcji CRT, które zostały zaprojektowane, aby zapobiec uszkodzeniu pamięci z powodu nieprawidłowego użycia buforu i niezdefiniowanych zachowań języka.
  • Biblioteka Sejf Int chroni przed przepełnieniem liczb całkowitych w operacjach matematycznych i porównawczych.

Korzystanie z bezpiecznych zależności

Pliki binarne nie powinny łączyć się z niezabezpieczonymi bibliotekami i zależnościami. Zespoły programistyczne powinny śledzić wszystkie zależności zewnętrzne i rozwiązywać problemy z lukami w zabezpieczeniach/zidentyfikowanych lukami w zabezpieczeniach w tych składnikach, aktualizując je do bezpieczniejszych wersji w przypadku wystąpienia tych luk w zabezpieczeniach.

Maksymalizowanie gwarancji pochodzenia kodu i wydajności reagowania na zabezpieczenia

Kompilacja powinna zapewnić silne gwarancje pochodzenia kodu, aby pomóc wykrywać i zapobiegać wprowadzeniu backdoorów i innego złośliwego kodu. Wynikowe dane, również krytyczne dla debugowania i badania, powinny być archiwizowane dla wszystkich wydań oprogramowania w celu zapewnienia wydajnej reakcji na zabezpieczenia, jeśli zostaną naruszone. Następujące przełączniki kompilatora generują informacje krytyczne dla odpowiedzi na zabezpieczenia:

  • /ZH:SHA_SHA256 w języku Visual C++ — zapewnia, że algorytm kryptograficznie bezpieczny jest używany do generowania wszystkich skrótów plików źródłowych PDB.
  • /Zi, /ZI (Format informacji debugowania) w visual C++ — oprócz publikowania usuniętych symboli na potrzeby zbierania danych awarii i innych scenariuszy użycia publicznego upewnij się, że kompilacje tworzą i archiwizowają prywatne pliki PDB dla wszystkich zwolnionych plików binarnych. Narzędzia analizy binarnej wymagają pełnych symboli, aby sprawdzić, czy wiele środków zaradczych zabezpieczeń zostało włączonych w czasie kompilacji. Symbole prywatne mają kluczowe znaczenie w reagowaniu na zabezpieczenia oraz obniżają koszty debugowania i badania, gdy inżynierowie ścigają się w celu oceny i ograniczenia szkód w przypadku wystąpienia luki w zabezpieczeniach.
  • /SOURCELINK w konsolidatorze Visual C++ — dołącz plik Sourcelink do pliku PDB: Link źródłowy jest niezależnym systemem kontroli języka i źródła, który zapewnia debugowanie źródła dla plików binarnych. Debugowanie źródła znacznie zwiększa wydajność zakresu weryfikacji zabezpieczeń wersji wstępnej i reagowania na zdarzenia po wydaniu.

Włączanie błędów kompilatora w celu zapobiegania problemom w czasie tworzenia kodu

Kompilacja powinna włączyć kontrole kompilatora istotne dla zabezpieczeń jako błędy powodujące niezgodność, na przykład:

Oznaczanie plików binarnych jako zgodnych z ograniczaniem zabezpieczeń środowiska uruchomieniowego systemu operacyjnego

Ustawienia kompilatora i konsolidatora powinny zdecydować się na funkcje generowania kodu, które wykrywają i zmniejszają ryzyko złośliwego wykonywania kodu, w tym:

Zapobieganie ujawnianiu poufnych informacji

Ustawienia kompilatora powinny zdecydować się na zapobieganie odnajdywaniem informacji poufnych. W ostatnich latach naukowcy odkryli niezamierzone wycieki informacji, które pochodzą z funkcji sprzętowych, takich jak wykonywanie spekulacyjne.

Na poziomie oprogramowania poufne dane mogą być przesyłane do osób atakujących w przypadku nieoczekiwanego wycieku. Niepowodzenie inicjowania buforów i inne nieprawidłowe użycie buforu może spowodować wyciek prywatnych poufnych danych do osób atakujących, które nazywają zaufany interfejs API. Ta klasa problemu najlepiej obsłużona przez włączenie dodatkowej analizy statycznej i używanie bezpiecznych kontenerów zasobów zgodnie z wcześniejszym opisem.

  • /Qspectre - Eliminowanie ataków typu side-channel wykonywania spekulatywnego — wstawia instrukcje barier, które pomagają zapobiec ujawnieniu poufnych danych generowanych przez wykonywanie spekulacyjne. Te środki zaradcze należy włączyć dla kodu, który przechowuje poufne dane w pamięci i działa na granicy zaufania. Firma Microsoft zawsze zaleca pomiar wpływu wydajności na odpowiednie testy porównawcze podczas włączania środków zaradczych spectre ze względu na możliwość wprowadzenia kontroli środowiska uruchomieniowego w blokach lub pętlach o znaczeniu krytycznym dla wydajności. Te ścieżki kodu mogą wyłączać środki zaradcze za pośrednictwem spectre(nomitigation)declspec modyfikatora. Projekty, które włączają funkcję "/Qspectre", powinny również łączyć się z bibliotekami, które są również kompilowane przy użyciu tych środków zaradczych, w tym bibliotek środowiska uruchomieniowego firmy Microsoft.

2.6 Przypadki testowe black box

Podsumowanie

Testy black box nie polegają na znajomości wewnętrznej pracy przetestowanego składnika. Testy black box są przeznaczone do testowania kompleksowej funkcjonalności funkcji w produkcie na dowolnym poziomie lub warstwie. Testy black box mogą być testami funkcjonalnymi, testami interfejsu użytkownika, testami wydajności i testami integracji. Testy black box są cenne do mierzenia ogólnej niezawodności i poprawności funkcjonalnej i zapewnienia, że produkt działa zgodnie z oczekiwaniami.

Relacja z innymi sekcjami

Te typy testów opartych na wymaganiach są przydatne do sprawdzania poprawności założeń wprowadzonych w modelu zagrożeń i pokrycia potencjalnych zagrożeń w tej sekcji. Te testy są przydatne do testowania integracji między oddzielnymi składnikami produktu, zwłaszcza tych, które znajdują się w granicach zaufania zgodnie z opisem w modelu zagrożeń. Przypadki testowe black box są również przydatne do testowania wszystkich rodzajów przypadków brzegowych na potrzeby weryfikacji danych wejściowych użytkownika. Testowanie znanych przypadków brzegowych i przypadków błędów jest przydatne. Rozmycie jest również przydatne do testowania mniej oczywistych przypadków.

Automatyzacja i regresja

Regularnie uruchamiaj te testy i porównuj wyniki z poprzednimi przebiegami, aby przechwytywać zmiany powodujące niezgodność lub regresje wydajności. Ponadto uruchomienie tych testów na wielu różnych komputerach i konfiguracjach instalacji może pomóc w omówieniu wszelkich problemów, które mogą wynikać z różnych architektur lub zmian konfiguracji.

Zrzuty awaryjne

Te testy pomagają znaleźć problemy z niezawodnością, możliwość testowania wielu różnych scenariuszy, które mogą napotkać awarie, zawieszenia, zakleszczenia itd. Zbierając zrzuty awaryjne w ramach niepowodzeń testów, można zaimportować zrzuty bezpośrednio do programu Visual Studio, aby dokładniej zbadać, jakie części kodu napotykają te problemy. Jeśli uruchamiasz testy funkcjonalne z poziomu programu Visual Studio, możesz łatwo replikować i debugować błędy, sprawdzając dokładnie, gdzie wewnątrz czarnego pola test zakończy się niepowodzeniem, i możesz szybko przetestować poprawki.

Aby rozpocząć debugowanie testów, zobacz Debugowanie testów jednostkowych za pomocą Eksploratora testów — Visual Studio (Windows)

Na platformie Azure

Usługa Azure DevOps może również pomóc w zarządzaniu tymi testami i weryfikowaniu ich przy użyciu planów testów. Te testy mogą służyć do zapewnienia zatwierdzenia przy użyciu walidacji ręcznej oraz uruchamiania testów automatycznych skojarzonych z wymaganiami produktu. Więcej informacji na temat planów testów platformy Azure i korzystania z nich do uruchamiania testów automatycznych można znaleźć tutaj:

2.7 Przypadki testowe oparte na kodzie

Podsumowanie

Przypadki testowe oparte na kodzie są integralną częścią utrzymania bezpieczeństwa i niezawodności produktu. Te testy powinny być małe i szybkie i nie powinny mieć wpływu na siebie, aby mogły być uruchamiane równolegle. Testy oparte na kodzie są łatwe dla deweloperów do uruchamiania lokalnego na maszynie deweloperów w dowolnym momencie wprowadzania zmian w kodzie bez martwienia się o spowolnienie cyklu programowania.

Typy i relacje z innymi sekcjami

Typowe typy przypadków testowych opartych na kodzie obejmują:

  • testy jednostkowe,
  • sparametryzowane testy obejmujące funkcje z wieloma typami wejściowymi,
  • testy składników w celu oddzielenia każdego składnika testowego i
  • pozorowanie testowania w celu zweryfikowania części kodu komunikujących się z innymi usługami bez rozszerzania zakresu testu w celu uwzględnienia tych usług.

Te testy są oparte na kodzie wewnętrznym, który jest napisany, podczas gdy testy czarnej skrzynki są oparte na wymaganiach zewnętrznych funkcjonalnych produktu.

Celem

Dzięki tym testom celem jest osiągnięcie wysokiego poziomu pokrycia testów w kodzie. Należy aktywnie śledzić to pokrycie i tam, gdzie istnieją luki. W miarę dodawania kolejnych testów, które wykonują więcej ścieżek kodu, zwiększa się ogólna pewność co do bezpieczeństwa i niezawodności kodu.

Program Visual Studio

Narzędzia eksploratora testów w programie Visual Studio ułatwiają częste uruchamianie tych testów i szybkie uzyskiwanie opinii na temat współczynników pass/fail i lokalizacji awarii. Wiele platform testowych obsługuje również funkcje CodeLens, aby zobaczyć stan testu w lokalizacji samego testu, co ułatwia dodawanie i utrzymywanie zestawu testów. Eksplorator testów ułatwia również zarządzanie tymi testami, umożliwiając grupom testowym, niestandardowym listom odtwarzaniom testowym, filtrowaniu, sortowaniu, wyszukiwaniu i nie tylko.

Aby uzyskać więcej informacji, zobacz:

Program Visual Studio udostępnia również narzędzia do śledzenia pokrycia kodu. Te narzędzia umożliwiają zapewnienie, że wprowadzone zmiany kodu są objęte istniejącymi testami lub dodać nowe testy w celu pokrycia nowych i nietestowanych ścieżek kodu. Narzędzia pokazują również procent pokrycia kodu, aby upewnić się, że jest on utrzymywany powyżej poziomu docelowego w celu zapewnienia pewności ogólnej jakości kodu.

Aby uzyskać informacje o tych narzędziach, zobacz Testowanie pokrycia kodu — Visual Studio (Windows)

Na platformie Azure

Usługa Azure DevOps może również pomóc w śledzeniu wyników pokrycia kodu dla całego produktu w ramach procesu potoku kompilacji. Aby uzyskać więcej informacji, zobacz Przeglądanie pokrycia kodu — Azure Pipelines.

2.8 Historyczne przypadki testowe

Podsumowanie

Historyczne przypadki testowe, znane również jako przypadki testowe regresji, zapobiegają ponownemu ponownemu wystąpieniu starych problemów i zwiększają ogólny zakres testów produktu. Upewnij się, że po naprawieniu usterki projekt dodaje również odpowiedni przypadek testowy. Wraz z upływem czasu, w miarę utrzymywania się poprawek, ogólna niezawodność zestawu testów będzie się poprawiać, zapewniając lepsze zapewnienie niezawodności i bezpieczeństwa.

Kluczowe cechy i relacje z innymi sekcjami

Ponieważ testują one regresje błędów, te testy powinny być szybkie i łatwe do uruchomienia, dzięki czemu mogą być uruchamiane obok [Przypadków testowych opartych na kodzie] i współtworzyć ogólny zakres kodu produktu. Wraz z tym użycie rzeczywistych przykładów od klientów do zainspirowania nowych przypadków testowych jest doskonałym sposobem na poprawę zasięgu i jakości testów.

Program Visual Studio

Program Visual Studio umożliwia łatwe dodawanie testów do pakietu podczas wprowadzania zmian w celu naprawienia usterki oraz szybkiego uruchamiania testów i pokrycia kodu w celu zapewnienia, że wszystkie nowe przypadki zostaną uwzględnione. Odwoływanie się do identyfikatora usterki z systemu śledzenia problemów w kodzie, w którym piszesz test, jest dobrym sposobem łączenia testów regresji z odpowiednimi problemami. Wolisz używać usługi Azure Boards i planów testowych razem z programem Visual Studio:

  • kojarzenie testów, przypadków testowych i problemów; I
  • do śledzenia wszystkich aspektów problemu i odpowiadających mu testów.

Aby uzyskać więcej informacji, zobacz:

W końcu zintegrowanie tych testów z obszarem testowania jednostkowego, który ma obejmować sekcję kodu, pomaga zachować uporządkowaną i łatwiejszą organizację zestawu testów. Grupowanie testów w Eksploratorze testów umożliwia efektywne śledzenie testów, które należą do siebie. Aby uzyskać więcej informacji, zobacz Uruchamianie testów jednostkowych za pomocą Eksploratora testów — Visual Studio (Windows)

2.9 Rozmycie

Podsumowanie rozmycie (nazywane również testowaniem rozmytym) to zautomatyzowana technika testowania oprogramowania, która polega na dostarczaniu nieprawidłowych, nieoczekiwanych lub losowych danych jako danych wejściowych programu. Program jest następnie monitorowany pod kątem wyjątków, takich jak awarie, niepowodzenie wbudowane lub kompilator wstrzyknięte asercji kodu i potencjalne przecieki pamięci.

Wskazówki

Użyj rozmytego we wszystkich oprogramowaniu, które może przetwarzać niezaufane dane wejściowe, które osoba atakująca może kontrolować. Jeśli tworzysz nową aplikację i skojarzony z nim zestaw testów, uwzględnij rozmycie dla kluczowych modułów tak szybko, jak to możliwe. Uruchamianie rozmycia po raz pierwszy na kawałku oprogramowania prawie zawsze ujawnia rzeczywiste luki w zabezpieczeniach, które były wcześniej nieznane. Po rozpoczęciu rozmycie, nigdy się nie zatrzymaj.

Relacja z innymi sekcjami

Gdy rozmycie zgłasza błąd, zawsze zapewnia powtarzalny przypadek testowy, który demonstruje usterkę. Ten przypadek testowy można odtworzyć, rozwiązać, a następnie dodać do historycznych przypadków testowych.

W przypadku używania obu narzędzi do oczyszczania, takich jak Narzędzia do oczyszczania adresów (ASan) i rozmycie:

  • Najpierw uruchom normalne testy z włączonymi sanitizerami, aby sprawdzić, czy występują problemy, a następnie gdy kod jest czyszczący, rozpocznij rozmycie.
  • W przypadku języka C lub C++istnieją kompilatory, które automatyzują iniekcję asercji środowiska uruchomieniowego i metadanych, które umożliwiają usługę ASan. Po skompilowaniu dla aplikacji ASan wynikowe pliki binarne łączą się z biblioteką środowiska uruchomieniowego, która może dokładnie zdiagnozować 15+ kategorii błędów bezpieczeństwa pamięci z zerowymi wynikami fałszywie dodatnimi. W przypadku języka C lub C++, jeśli masz źródło, użyj biblioteki LibFuzzer, która wymaga, aby usługa ASan została włączona jako pierwsza.
  • W przypadku bibliotek napisanych w języku Java, C#, Python, Rust itd. użyj struktury AFL++.

Kluczowe cechy

  • Rozmycie znajduje luki w zabezpieczeniach często pomijane przez analizę programu statycznego, wyczerpujące testowanie funkcji i ręczną inspekcję kodu.
  • Rozmycie to skuteczny sposób znajdowania usterek dotyczących zabezpieczeń i niezawodności w oprogramowaniu, tak bardzo, że cykl życia tworzenia zabezpieczeń firmy Microsoft wymaga rozmycie w każdym niezaufanym interfejsie każdego produktu (zobacz również Modelowanie zagrożeń).
  • Zawsze używaj rozmytego oprogramowania, które może przetwarzać niezaufane dane wejściowe.
  • Rozmycie jest skuteczne w przypadku autonomicznych aplikacji z dużymi analizatorami danych.

Ciągła integracja/ciągłe wdrażanie na platformie Azure i w usłudze GitHub

Zmodyfikuj kompilacje, aby obsługiwać ciągłe tworzenie plików wykonywalnych korzystających z bibliotek LibFuzzer lub AFL++. Możesz dodać dodatkowe zasoby obliczeniowe wymagane do rozmycie w usługach, takich jak OSS-Fuzz lub OneFuzz.

2.10 Skanowanie aplikacji internetowych

Podsumowanie

W zakresie programu Microsoft Visual C++ w systemie Windows firma Microsoft zaleca:

  • Preferuj język TypeScript, JavaScript i ASP.NET dla aplikacji internetowych.
  • Nie zapisuj rozszerzeń internetowych w języku C++. Firma Microsoft ma przestarzałą usługę ActiveX.
  • Gdy kod jest kompilowany do programu Emscripten/WASM, nie ma już zastosowania języka C++ i innych narzędzi.
  • Firma Microsoft udostępnia restler, stanowy interfejs API REST rozmycie.

Przegląd i kluczowe cechy

Skaner aplikacji internetowej eksploruje aplikację internetową, przeszukuje jej strony internetowe i sprawdza je pod kątem luk w zabezpieczeniach. To przeszukiwanie obejmuje automatyczne generowanie złośliwych danych wejściowych i ocenę odpowiedzi aplikacji. Skanowanie aplikacji internetowych musi obejmować/obsługiwać następujące elementy:

  • Kataloguje wszystkie aplikacje internetowe w sieci, w tym nowe i nieznane, oraz skaluje z kilku aplikacji do tysięcy.
  • Głębokie skanowanie pod kątem wersji oprogramowania, usług i interfejsów API REST protokołu SOAP oraz interfejsów API używanych przez urządzenia przenośne.
  • Wstawianie elementów pierwotnych zabezpieczeń do tworzenia i wdrażania aplikacji w środowiskach DevOps. Te elementy pierwotne współpracują z przeszukiwarką.
  • Wykrywanie złośliwego oprogramowania.

2.11 Synchronizacja składnikowane składniki oprogramowania

Podsumowanie

Obsłuż kod C++, tak samo jak kod napisany w innych językach programowania, i zastosuj dowolne narzędzia analizy kompozycji oprogramowania (SCA) i analizy pochodzenia (OA) przyjęte przez firmę w kodzie C++. Przepływy pracy i skanowanie zabezpieczeń powinny być projektowane jako część systemów ciągłej integracji/ciągłego dostarczania.

Obrona nadrzędna

Aby ograniczyć ryzyko ataków na zależności nadrzędne, źródła/składniki innych firm powinny być przechowywane w zasobie kontrolowanym przez przedsiębiorstwo, na którym są uruchamiane narzędzia SCA i OA.

  • Narzędzia powinny skanować i ostrzegać w przypadku zidentyfikowania luk w zabezpieczeniach (w tym publicznych baz danych), takich jak: Strona główna | — Cve
  • Uruchom analizę statyczną na wszystkich składnikach oprogramowania zawartych w aplikacji/repozytorium, aby zidentyfikować wzorce kodu podatnego na zagrożenia.

Ochrona zależności

Przeprowadź i zachowaj inspekcję zależności, aby sprawdzić, czy wszystkie takie wystąpienia są uwzględniane i objęte narzędziami SCA i OA.

  • Składniki powinny być regularnie poddawane inspekcji i aktualizowane do najnowszych zweryfikowanych wersji.
  • Zależności zestawienia pakietów.
  • Narzędzia SCA/OA obejmują i przeprowadź inspekcję wszystkich zależności pakietów pochodzących z jednego źródła danych.

SBOM

Wygeneruj SBOM (rachunek za oprogramowanie materiałów) z produktem zawierającym listę wszystkich zależności, takich jak:

  • origin (na przykład adres URL (ujednolicony lokalizator zasobów))
  • version
  • spójność (na przykład skrót źródła SHA-256) i inne sposoby sprawdzania spójności, takich jak kompilacje deterministyczne.
  • Wymagaj i przeprowadź inspekcję plików SBOM w zależnościach oprogramowania lub utworzonych w ramach kompilacji, w tym systemu operacyjnego (oprogramowania open source).
  • Firma Microsoft ustandaryzuje program i zaleca program SPDX (Software Package Data Exchange) w wersji 2.2 lub nowszej | Linux Foundation jako format dokumentu SBOM.
  • Determinizm kompilacji może służyć do niezależnego tworzenia bitowych identycznych plików binarnych i zapewnienia niezależnych weryfikacji integralności:
    • Zaświadczenie innej firmy lub innej firmy o powtarzalności
    • Inne techniki, takie jak podpisywanie binarne za pośrednictwem zaufanego źródła certyfikatów, mogą również zapewnić integralność binarną.

Dodatkowe zasoby

Rozwiązania firmy Microsoft obejmują następujące wskazówki i produkty: