Erstellen von zuverlässigen und sicheren C++-Programmen

  • Artikel

Die USA Regierungsveröffentlichung NISTIR 8397: Richtlinien für die Mindeststandards für die Überprüfung der Software für Entwickler enthält hervorragende Anleitungen zum Erstellen von zuverlässiger und sicherer Software in jeder Programmiersprache.

Dieses Dokument folgt der gleichen Struktur wie NISTIR 8397. Jeder Abschnitt:

  • fasst zusammen, wie Sie Microsoft-Entwicklerprodukte für C++ und andere Sprachen verwenden, um die Sicherheitsanforderungen dieses Abschnitts zu erfüllen, und
  • enthält Anleitungen zum Abrufen des größten Werts in den einzelnen Bereichen.

2.1 Bedrohungsmodellierung

Zusammenfassung

Die Bedrohungsmodellierung ist ein wertvoller Prozess, insbesondere bei Anwendung auf eine Weise, die skaliert wird, um Ihren Entwicklungsanforderungen gerecht zu werden und Rauschen zu reduzieren.

Empfehlungen

Die Bedrohungsmodellierung sollte ein Teil Ihres dynamischen Security Development Lifecycle (SDL) sein. Wir empfehlen, dass für Ihr Produkt als Ganzes, für ein bestimmtes Feature oder für eine wesentliche Design- oder Implementierungsänderung folgendes vorgesehen ist:

  • Verfügen Sie über einen soliden, dynamischen SDL, der ein frühzeitiges Engagement mit Entwicklerteams und die Rechte bei der Vorgehensweise ermöglicht.
  • Wenden Sie die Bedrohungsmodellierung gezielt an. Wenden Sie die Bedrohungsmodellierung auf alle Features an, beginnen sie jedoch taktisch mit verfügbar gemachten, komplexen oder kritischen Features. Wenden Sie sie stattdessen regelmäßig als Teil einer Top-Down-Produktüberprüfung an.
  • Wenden Sie die Bedrohungsmodellierung frühzeitig an (wie bei allen Sicherheitsanforderungen), wenn es immer noch die Möglichkeit gibt, den Entwurf zu ändern. Außerdem dienen Bedrohungsmodelle als Eingabe für andere Prozesse, z. B. Verringerung der Angriffsfläche oder Entwerfen für Sicherheit. Bedrohungsmodelle, die später erstellt werden, sind am besten "Umfragen" für Stifttests (Penetrationstests) oder Bereiche, die Sicherheitstests wie fuzzing benötigen. Nachdem Sie ein grundlegendes Bedrohungsmodell erstellt haben, planen Sie, das Iterieren fortzufahren, während sich die Angriffsfläche ändert.
  • Verwenden Sie Bestandsbestand und Compliance, um das Produkt entsprechend nachzuverfolgen und Sicherheitsartefakte (einschließlich Bedrohungsmodelle) zusammen mit den Ressourcen nachzuverfolgen, auf die sie angewendet werden. Dieser Ansatz ermöglicht eine bessere automatisierte Risikobewertung und den Schwerpunkt der Sicherheitsanstrengungen auf die spezifischen Komponenten oder Features, die sich ändern.
  • In Azure wurde das Microsoft Threat Modeling Tool 2022 für die Azure-Entwicklung aktualisiert. Weitere Informationen finden Sie in der Übersicht über das Microsoft Threat Modeling Tool – Azure

Unterstützende Faktoren und Methoden

Um bedrohungsmodellierung ordnungsgemäß anzuwenden und zu vermeiden, dass die folgenden Kernkonzepte zuerst berücksichtigt werden müssen, haben wir festgestellt, dass zuerst die folgenden Kernkonzepte berücksichtigt werden müssen.

Entwicklungsansatz

Verstehen Sie zunächst den Entwicklungsansatz des Teams. Für Teams mit agilen Entwicklungsworkflows, die täglich Dutzende von Änderungen an die Produktion pushen, ist es nicht praktisch oder sinnvoll, für jede funktionale Änderung ein Bedrohungsmodellupdate zu erfordern. Stattdessen sollten Sie von Anfang an beim Schreiben der funktionalen Anforderungen eines Features einen Sicherheitsanforderungen-Fragebogen einschließen. Der Fragebogen sollte sich auf spezifische Fragen zum Feature konzentrieren, um zu bestimmen, welche zukünftigen Aspekte Ihres SDL gelten. Beispiel:

  • Ändert sich das Feature in der Gestaltung der Art und Weise, wie wir Kundenisolation in einer mehrinstanzenübergreifenden Umgebung bereitstellen? Wenn ja, erwägen Sie, ein vollständiges Bedrohungsmodell auszuführen.
  • Lässt ein neues Feature Dateiuploads zu? Wenn ja, ist vielleicht eine Webanwendungssicherheitsbewertung besser geeignet.
  • Ist diese Änderung in erster Linie nur eine funktionale UI-Änderung? Wenn ja, ist vielleicht nichts über Ihre herkömmlichen automatisierten Tools hinaus erforderlich.

Die Ergebnisse des Sicherheitsfragebogens informieren, welche SDL-Techniken an welche Entwicklungseinheit gebunden werden sollen. Sie informiert auch Entwicklungspartner über die SDL-Zeitleiste der Features, damit sie zu den richtigen Zeiten zusammenarbeiten können.

Produktbestand

Zweitens Standard einen starken Bestandsbestand der Produkte enthalten, die Sie mit der Bewertung beauftragt haben. Produkte wachsen immer komplexer. Es ist üblich, Software für verbundene Geräte zu schreiben, die Folgendes haben:

  • Sensoren (z. B. Personenbahn und Fahrzeuge),
  • Bus-basierte Netzwerke, die mit anderen Komponenten im Fahrzeug sprechen (z. B. CANBUS oder SHAPES),
  • wireless/cellular/Bluetooth für die Kommunikation mit Kundengeräten und Cloud-Back-Ends,
  • maschinelles Lernen in der Cloud zurück in das Gerät oder eine Flottenverwaltungsanwendung,
  • und mehr

Bei solchen komplexen Produkten ist die Bedrohungsmodellierung von entscheidender Bedeutung. Wenn Sie einen starken Bestandsbestand haben, können Sie den gesamten Produktstapel anzeigen, um das vollständige Bild anzuzeigen, und die wichtigsten Stellen anzuzeigen, die ausgewertet werden müssen, um zu ermitteln, wie sich ein neues oder geändertes Feature auf die Produktsicherheit auswirkt.

Granularität und Integration

Richten Sie Systeme ein, um die Compliance mithilfe eindeutiger Metriken zu messen.

  • Messen Sie regelmäßig die Compliance für die Entwicklung auf Featureebene. Die Featurecompliance sollte in der Regel mit höherer Häufigkeit und geringerer Granularität gemessen werden, manchmal sogar im System des Entwicklers oder zur Code-Commit-/Zusammenführungszeit.
  • Bewerten Sie regelmäßig die Sicherheit für das breitere Produkt, in dem ein Feature oder eine Komponente verbraucht wird. Breitere Auswertungen erfolgen in der Regel mit geringerer Häufigkeit und breiterer Granularität, z. B. zur Modul- oder Systemtestzeit.

Skalierung

Bewahren Sie ein ordnungsgemäßes Bestandsinventarsystem auf, das Sicherheitsartefakte und die Ausgabe von Bedrohungsmodellüberprüfungen erfasst und bewahrt. Wenn Sie einen klaren Bestand haben, können Sie Die Ergebnisse der Überprüfung für Muster auswerten und intelligente Entscheidungen treffen, wie sie das Produktsicherheitsprogramm regelmäßig verfeinern.

Versuchen Sie, Anforderungsphasen-Sicherheitsfragebögen, Ergebnisse der Bedrohungsmodellierung, Ergebnisse der Sicherheitsbewertung und Ergebnisse aus automatisierten Tools zu kombinieren. Wenn Sie sie kombinieren, können Sie einen Standpunkt des relativen Risikos eines bestimmten Produkts automatisieren, idealerweise als "Dashboard", um Ihre Sicherheitsteams darüber zu informieren, worauf Sie sich konzentrieren müssen, um den besten Nutzen aus der Bedrohungsmodellierung zu erzielen.

2.2 Automatisierte Tests

Zusammenfassung

Automatisierte Tests sind eine wichtige Möglichkeit, um die Qualität und Sicherheit Ihres Codes sicherzustellen. Sie sind ein integraler Bestandteil der Unterstützung anderer Bereiche Erwähnung in diesem Dokument, z. B. Threat Modeling. Wenn sie mit anderen methoden für sicheres Codieren gekoppelt sind, können sie vor Fehlern und Sicherheitsrisiken schützen, die in die Codebasis eingeführt werden.

Schlüsselattribute

Tests sollten zuverlässig, konsistent und isoliert sein. Diese Tests sollten so viel code wie möglich abdecken. Alle neuen Features und Fehlerbehebungen sollten über entsprechende Tests verfügen, um die langfristige Sicherheit und Zuverlässigkeit des Codes sicherzustellen. Führen Sie automatisierte Tests regelmäßig und in so vielen Umgebungen wie möglich aus, um sicherzustellen, dass sie ausgeführt werden und dass sie alle Bereiche abdecken:

  • Der erste Ort, an dem sie ausgeführt werden sollen, befindet sich auf dem Computer, der die Änderungen vornimmt. Das Ausführen von Tests erfolgt am einfachsten innerhalb der IDE, die für die Bearbeitung verwendet wird, oder als Skript in der Befehlszeile, während der Entwickler die Änderungen vorgibt.
  • Die nächste Stelle, an der sie ausgeführt werden sollen, ist Teil des Commit-/Zusammenführungsprozesses der Pullanforderung.
  • Der letzte Ort zum Ausführen von Tests ist Teil einer Continuous Integration and Continuous Deployment (CI/CD)-Pipeline oder ihrer Releasekandidatenbuilds.

Der Umfang der Tests sollte bei jedem Schritt erhöht werden, wobei der letzte Schritt die vollständige Abdeckung für alle anderen Schritte bietet.

Kontinuierliche Verwendung und Standard intensität

Die Zuverlässigkeit von Tests ist ein wichtiger Bestandteil Standard die Wirksamkeit der Testsuite zu gewährleisten. Testfehler sollten zugewiesen und untersucht werden, wobei potenzielle Sicherheitsprobleme hohe Priorität erhalten und innerhalb eines eingabeaufforderungs- und vorbestimmten Zeitrahmens aktualisiert werden. Das Ignorieren von Testfehlern sollte keine gängige Praxis sein, sondern eine starke Begründung und Genehmigung erfordern. Testfehler aufgrund von Problemen innerhalb der Testsuite selbst sollten genauso behandelt werden wie andere Fehler, um zu verhindern, dass eine Verstrichene bei produktbedingten Problemen fehlen.

Arten von Tests, insbesondere Komponententests

Es gibt mehrere Arten von automatisierten Tests, und obwohl nicht alle auf alle Anwendungen anwendbar sind, enthält eine gute Testsuite eine Auswahl verschiedener Typen. Codebasierte Testfälle wie Komponententests sind die am häufigsten verwendeten und integralsten, gelten für alle Anwendungen und decken absichtlich so viele Codepfade wie möglich für die Korrektheit ab. Diese Tests sollten klein, schnell und nicht auf den Zustand des Computers wirken, damit die gesamte Testreihe schnell und häufig ausgeführt werden kann. Führen Sie nach Möglichkeit Tests auf vielen Computern mit unterschiedlichen Hardwaresetups aus, um Probleme abzufangen, die auf einem einzelnen Computertyp nicht reproduzierbar sind.

Visual Studio

Visual Studio Test Explorer unterstützt nativ viele der beliebtesten C++-Testframeworks und bietet Optionen zum Installieren von Erweiterungen für weitere Frameworks. Diese Flexibilität ist hilfreich für die Ausführung einer Teilmenge von Tests, die den Code abdecken, an dem Sie arbeiten, und erleichtert das Debuggen von Testfehlern, sobald sie auftreten. Visual Studio erleichtert auch das Einrichten neuer Testsammlungen für vorhandene Projekte und bietet hilfreiche Tools wie CodeLens, um diese Tests einfacher zu verwalten. Weitere Informationen zum Schreiben, Ausführen und Verwalten von C/C++-Tests mit Visual Studio finden Sie unter Schreiben von Komponententests für C/C++ – Visual Studio (Windows).

In Azure und GitHub CI/CD

Tests, die eine tiefere Überprüfung durchführen und länger ausgeführt werden müssen, z. B. statische Analyse, Komponentenerkennung usw., eignen sich gut für Pull-Anforderungstests oder kontinuierliche Integrationstests. Azure DevOps- und GitHub-Aktionen vereinfachen die automatische Ausführung von Validierungen und blockieren Codeüberprüfungen, wenn eine Überprüfung fehlschlägt. Durch die automatisierte Erzwingung wird sichergestellt, dass der gesamte eingecheckte Code basierend auf diesen strengeren Überprüfungen sicher ist. Die Azure-Pipelines und die Azure DevOps-Buildüberprüfung werden hier beschrieben:

2.3 Codebasierte oder statische Analyse

Die zusammenfassung statische Code-/Binäranalyse sollte standardmäßig aktiviert sein, damit sie standardmäßig sicher ist. Statische Analysen analysieren ein Programm für erforderliche Sicherheits- und Sicherheitsrichtlinien zum Zeitpunkt der Erstellung, nicht zur Ausführungszeit, wenn ein Exploit auf dem Computer des Kunden auftreten kann. Statische Analysen können das Programm im Quellcodeformular oder in kompilierter ausführbarer Form analysieren.

Empfehlungen Microsoft empfiehlt Folgendes:

  • Aktivieren Sie die statische Analyse für alle C++-Programme sowohl für den Eingabequellcode (vor der Kompilierung) als auch für die ausführbaren Binärdateien (nach der Kompilierung). "Aktivieren" kann bedeuten, während jedes Builds auf dem Computer des Entwicklers Eine Analyse auszuführen, oder als separater Build, um den Code später oder als Checkin-Anforderung zu prüfen.
  • Integrieren Sie statische Analysen in CI-Pipelines als Form von Tests.
  • Statische Analyse ist per Definition mit falsch positiven Ergebnissen enthalten und ist bereit, diese Tatsache in Ihre Qualitätsfeedbackschleife zu integrieren. Lassen Sie sich schnell alle Warnungen mit niedriger falsch positiver Warnung im Vorfeld aktivieren. Seien Sie dann proaktiv, um die Anzahl der Regeln schrittweise zu erhöhen, für die Ihre Codebasis Warnungs-sauber kompiliert, während Sie regelmäßig weitere Regeln hinzufügen, die wichtige Fehler auf Kosten von allmählich höheren falsch positiven Ergebnissen kennzeichnen (zunächst, bevor die Codebasis auch für diese Regeln sauber wurde).
  • Verwenden Sie immer die neuesten unterstützten Versionen von Visual Studio, und richten Sie Ihre Entwicklungsumgebung ein, um die neuesten Patchversionen schnell zu nutzen, sobald sie verfügbar sind, ohne dass sie in die nächste Entwicklungsstufe/den nächsten Zyklus verschoben werden.

Wichtige Tools beachten und verwenden Sie Folgendes:

Hinweise:

  • /analyze ermöglicht die statische Analyse von C++-Code zur Kompilierungszeit, um kritische Sicherheits- und Zuverlässigkeitscoderisiken zu identifizieren. Sie sollte im gesamten Entwicklungs-Zeitleiste eines C++-Programms aktiviert werden. Beginnen Sie, indem Sie mindestens die "Microsoft Native Recommended" standardmäßig als Mindestbasislinie aktivieren. Lesen Sie dann die Dokumentation, wie Sie weitere Regeln angeben, insbesondere die C++-Kernrichtlinienregeln, wie sie von Ihren Engineeringrichtlinien benötigt werden. Die Statische Analysefunktion des Quellcodes ist sowohl in der Visual C++-IDE als auch in den Befehlszeilen-Buildtools verfügbar.
  • /W4und /WX sollte nach Möglichkeit aktiviert werden, um sicherzustellen, dass Sie Ihren Code sauber d auf hohen Warnstufen (W4) kompilieren und Warnungen als Fehler behandeln, die behoben werden müssen (WX). Diese Optionen ermöglichen das Auffinden nicht initialisierter Datenfehler, die andere statische Analysetools nicht überprüfen können, da die Fehler erst sichtbar werden, nachdem das Compiler-Back-End interprocedural analyse und inlining ausgeführt hat.
  • BinSkim-Binäranalyse stellt sicher, dass Projekte eine breite Palette von Sicherheitsfeatures ermöglichen. BinSkim generiert PDBs und andere Ausgaben, die es einfacher machen, die Verwahrkette zu überprüfen und effizient auf Sicherheitsprobleme zu reagieren. Microsoft empfiehlt, das BinSkim-Tool auszuführen, um alle ausführbaren Binärdateien (.sysoder .exe) zu analysieren, .dll die für Ihre Programme erstellt oder genutzt werden. Der BinSkim-Benutzerhandbuch enthält eine Liste der unterstützten Sicherheitsstandards. Microsoft empfiehlt, alle Vom BinSkim-Tool als "Fehler" gemeldeten Probleme zu beheben. Probleme, die als "Warnungen" gemeldet werden, sollten selektiv ausgewertet werden, da die Lösung auswirkungen auf die Leistung haben kann oder nicht erforderlich ist.

In Azure und GitHub CI/CD empfiehlt Microsoft immer die Aktivierung von Quellcode und binärer statischer Analyse in Release-CI/CD-Szenarien. Führen Sie die Quellanalyse sofort auf dem Computer des lokalen Entwicklers oder zumindest für jeden Commit oder Pull-Anforderung aus, um Quellfehler so früh wie möglich abzufangen und die Gesamtkosten zu minimieren. Fehler auf binärer Ebene werden tendenziell langsamer eingeführt, daher kann es ausreichen, binäre Analysen in weniger häufigen CI/CD-Szenarien (z. B. nachts oder wöchentliche Builds) auszuführen.

2.4 Überprüfung auf hartcodierte geheime Schlüssel

Zusammenfassung

Codieren Sie keine geheimen Schlüssel innerhalb der Software. Sie können geheime Schlüssel aus dem Quellcode effizient finden und entfernen, indem Sie zuverlässige Tools verwenden, mit denen Ihre gesamte Quellcodebasis überprüft werden kann. Sobald Sie Geheime gefunden haben, verschieben Sie sie an einen sicheren Ort, der auf die Richtlinie zum sicheren Speichern und Verwenden von Geheimschlüsseln folgt.

Problem

"Geheime Schlüssel" bezeichnet Entitäten, die Identität einrichten und Zugriff auf Ressourcen gewähren oder zum Signieren oder Verschlüsseln vertraulicher Daten verwendet werden. Beispiele sind Kennwörter, Speicherschlüssel, Verbindungszeichenfolge und private Schlüssel. Es ist verlockend, Geheimnisse im Softwareprodukt zu bewahren, damit sie bei Bedarf von der Software leicht abgerufen werden können. Diese hartcodierten Geheimnisse können jedoch zu schwerwiegenden oder katastrophalen Sicherheitsvorfällen führen, da sie leicht entdeckt werden und verwendet werden können, um Ihren Dienst und Ihre Daten zu kompromittieren.

Prävention

Geheime Schlüssel, die im Quellcode (als Nur-Text oder verschlüsseltes Blob) hartcodiert sind, sind eine Sicherheitslücke. Hier sind allgemeine Richtlinien zum Vermeiden von geheimen Schlüsseln im Quellcode:

  • Verwenden Sie ein Precheckin-Tool, um potenzielle hartcodierte geheime Schlüssel im Code zu scannen und abzufangen, bevor Sie die Quellcodeverwaltung übermitteln.
  • Fügen Sie keine Klartextanmeldeinformationen in Quellcode- oder Konfigurationsdateien ein.
  • Speichern Sie keine Klartextanmeldeinformationen in SharePoint, OneNote, Dateifreigaben usw. Sie können sie auch per E-Mail, Chat usw. teilen.
  • Verschlüsseln Sie kein Geheimnis mit einem leicht auffindbaren Entschlüsselungsschlüssel. Speichern Sie z. B. keine PFX-Datei zusammen mit einer Datei, die ihr Kennwort enthält.
  • Verschlüsseln Sie kein Geheimnis mit einer schwachen Entschlüsselung. Verschlüsseln Sie z. B. keine PFX-Datei mit einem schwachen oder allgemeinen Kennwort.
  • Vermeiden Sie verschlüsselte Anmeldeinformationen im Quellcode. Verwenden Sie stattdessen Platzhalter in Ihrer Quelle, und lassen Sie es Ihrem Bereitstellungssystem ermöglichen, sie durch geheime Schlüssel aus genehmigten Stores zu ersetzen.
  • Wenden Sie dieselben Prinzipien auf geheime Schlüssel in Umgebungen an, z. B. Tests, Staging usw. wie bei Produktionsbereitstellungen. Angreifer zielen häufig auf Nichtproduktionssysteme ab, da sie weniger gut verwaltet werden, und verwenden Sie sie dann, um in die Produktion zu pivotieren.
  • Teilen Sie geheime Schlüssel nicht zwischen Bereitstellungen (z. B. Tests, Staging, Produktion).

Während sie nicht direkt mit hartcodierten Geheimschlüsseln verbunden sind, denken Sie daran, geheime Schlüssel für Ihren Test, Ihre Entwicklung und Produktion zu schützen:

  • Drehen Sie Ihre geheimen Schlüssel regelmäßig und wann immer sie verfügbar gemacht wurden. Die Möglichkeit, geheime Schlüssel zu drehen/erneut bereitzustellen, ist ein Beweis für ein sicheres System. Vor allem das Fehlen dieser Funktion ist noch stärkere Beweise für eine unvermeidliche Sicherheitsanfälligkeit.
  • Geben Sie dem allgemeinen Entwicklerprinzip nicht zu, dass "meine Testanmeldeinformationen kein Risiko schaffen". In der Praxis tun sie fast immer.
  • Ziehen Sie in Betracht, sich von geheimen Schlüsseln (z. B. Kennwörtern, Bearerschlüsseln) vollständig vor RBAC-/identitätsgesteuerten Lösungen als eine gute technische Lösung zu bewegen, die das geheime Missmanagement vollständig umgehen kann.

Erkennung

Ältere Komponenten Ihres Produkts enthalten möglicherweise versteckte hartcodierte Geheimschlüssel im Quellcode. Manchmal können geheime Schlüssel von Desktopcomputern von Entwicklern in Remote-Verzweigungen schleichen und in der Release-Verzweigung zusammengeführt werden, wobei geheime Schlüssel unbeabsichtigt geleert werden. Um geheime Schlüssel zu entdecken, die sich möglicherweise in Ihrem Quellcode verbergen, können Sie Tools verwenden, mit denen Sie Ihren Code auf hartcodierte geheime Schlüssel überprüfen können:

Wartung

Wenn Anmeldeinformationen in Ihrem Quellcode gefunden werden, müssen Sie den verfügbar gemachten Schlüssel sofort ungültig machen und eine Risikoanalyse basierend auf der Exposition durchführen. Auch wenn Ihr System weiterhin ausgeführt werden muss, können Sie einen geheimen Manager für die Behebung mit den folgenden Schritten aktivieren:

  1. Wenn die Wartung den Wechsel zu verwalteten Identitäten ermöglicht oder das Ablegen in einem geheimen Manager wie Azure Key Vault (AKV) erfordert, führen Sie dies zuerst aus. Stellen Sie dann mit der aktualisierten Identität oder dem aktualisierten Schlüssel erneut zur Seite.
  2. Ungültiges Geheimnis verfügbar gemacht.
  3. Führen Sie die Überwachung/Risikobewertung potenzieller Schäden durch, die auf Kompromittierung zurückzuführen sind.

Um kryptografische Schlüssel und andere geheime Schlüssel zu schützen, die von Cloud-Apps und -Diensten verwendet werden, verwenden Sie Azure Key Vault mit einer entsprechenden Zugriffsrichtlinie.

Wenn eine Exposition bestimmte Kundendaten/PII kompromittiert, ist möglicherweise andere Compliance-/Berichterstellungsanforderungen erforderlich.

Entfernen Sie die jetzt ungültigen geheimen Schlüssel aus Dem Quellcode, und ersetzen Sie sie durch alternative Methoden, die die geheimen Schlüssel nicht direkt im Quellcode verfügbar machen. Suchen Sie nach Möglichkeiten, geheime Schlüssel nach Möglichkeit mithilfe von Tools wie Azure AD zu beseitigen. Sie können Ihre Authentifizierungsmethoden aktualisieren, um verwaltete Identitäten über Azure Active Directory zu nutzen. Verwenden Sie genehmigte Stores nur zum Speichern und Verwalten von Geheimschlüsseln wie Azure Key Vault (AKV). Weitere Informationen finden Sie unter:

Azure DevOps (AzDO)

AzDO-Benutzer können ihren Code über GitHub Advanced Security für Azure DevOps (GHAzDO) scannen. GHAzDO ermöglicht es Benutzern auch, geheime Expositionen zu verhindern, indem push-Schutz für ihre Repositorys aktiviert wird, um potenzielle Expositionen abzufangen, bevor sie jemals verloren gehen. Weitere Informationen zum Erkennen hartcodierter Geheimschlüssel im Code in Azure DevOps finden Sie unter Secret Scanning for Github Advanced Security for Azure DevOps in jedem der folgenden Links:

In GitHub

Geheime Überprüfung ist auf GitHub.com in zwei Formen verfügbar:

  • Geheime Scanwarnungen für Partner. Wird automatisch für alle öffentlichen Repositorys ausgeführt. Alle Zeichenfolgen, die mit Mustern übereinstimmen, die von Partnern für die Geheimnisüberprüfung angegeben wurden, werden direkt an den jeweiligen Partner gemeldet.
  • Geheime Überprüfungswarnungen für Benutzer. Sie können zusätzliche Überprüfungen für Repositorys aktivieren und konfigurieren, die im Besitz von Organisationen sind, die GitHub Enterprise Cloud verwenden und über eine Lizenz für GitHub Advanced Security verfügen. Diese Tools unterstützen auch private und interne Repositorys.

GitHub bietet bekannte Muster geheimer Schlüssel für Partner und Benutzer, die für Ihre Anforderungen konfiguriert werden können. Weitere Informationen finden Sie unter:

Hinweis

GitHub Advanced Security für Azure DevOps bietet die gleichen geheimen Scan-, Abhängigkeitsscan- und CodeQL-Codescanlösungen, die bereits für GitHub-Benutzer verfügbar sind, und integriert sie nativ in Azure DevOps, um Ihre Azure Repos und Pipelines zu schützen.

Weitere Ressourcen

2.5 Ausführen mit sprach- und vom Betriebssystem bereitgestellten Prüfungen und Schutz

Zusammenfassung

Die binäre Härtung erfolgt durch Anwenden von Kompilierungszeitsicherheitssteuerelementen. Dazu gehören Entschärfungen, die:

  • Verhindern von ausnutzbaren Sicherheitsrisiken im Code,
  • Aktivieren von Laufzeiterkennungen, die Sicherheitsabwehr bei der Ausbeutung auslösen, und
  • Ermöglichen Sie die Datenproduktion und -archivierung, um den Schaden zu begrenzen, der durch Sicherheitsvorfälle verursacht wird.

Binäre Verbraucher müssen sich für Windows-Sicherheitsfeatures entscheiden, um den vollen Vorteil der Härtung zu erzielen.

Microsoft bietet eine Reihe von Spezifischen Einrichtungen für C++-Projekte, mit denen Entwickler sichereren und sichereren Code schreiben und versenden können. C++-Entwickler sollten auch Sicherheitsstandards einhalten, die für Sprachen gelten, die ausführbaren Code generieren. Microsoft Standard tains BinSkim, eine öffentliche OSS-Binärüberprüfung, die die Verwendung vieler Schutzmechanismen erzwingt, die in diesem Abschnitt beschrieben werden. Weitere Informationen zu BinSkim finden Sie im Binskim-Benutzerhandbuch | Github

Steuerelemente auf Binärer Ebene unterscheiden sich je nach Anwendung im Engineeringprozess. Sie sollten zwischen Compiler- und Linkeroptionen unterscheiden, die: strikt kompilierte Zeit, Ändern der Codegenerierung mit Laufzeitaufwand und Ändern der Codegenerierung, um Kompatibilität mit Betriebssystemschutz zu erzielen.

Entwicklereinstellungen sollten möglichst viele statische Analysen aktivieren, die Produktion privater Daten aktivieren, um das Debuggen zu beschleunigen usw. Releasebuilds sollten auf eine geeignete Kombination aus Sicherheits-, Leistungs- und anderen Problemen bei der Codegenerierung abgestimmt werden. Releaseprozesse müssen so konfiguriert werden, dass öffentliche und private Builddaten ordnungsgemäß generiert und verwaltet werden (z. B. öffentliche oder private Symbole).

Bleiben Sie auf dem neuesten Stand: Immer aktuelle Compiler und Tools verwenden

Kompilieren Sie den gesamten Code mit aktuellen Toolsets, um von aktueller Sprachunterstützung, statischer Analyse, Codegenerierung und Sicherheitskontrollen zu profitieren. Da Compiler sich auf jede generierte Komponente auswirken, ist das Potenzial für Regressionen bei der Toolaktualisierung relativ hoch. Die Verwendung veralteter Compiler verursacht ein bestimmtes Risiko für Korrekturmaßnahmen, während sie auf einen Sicherheitsvorfall reagieren, da Teams möglicherweise nicht genügend Zeit zum Upgrade von Compilern haben. Microsoft empfiehlt Teams, die Einrichtung zu entwickeln, um Compilerupdates regelmäßig zu aktualisieren und zu testen.

Verwenden sicherer Entwicklungsmethoden, Sprachversionen, Frameworks/APIs

Code sollte Entwicklungsmethoden, Sprachversionen, Frameworks, APIs usw. verwenden, die risiken minimieren, indem sicherheit und Einfachheit in C++ gefördert werden, einschließlich:

Sichere Abhängigkeiten nutzen

Binärdateien sollten nicht mit unsicheren Bibliotheken und Abhängigkeiten verknüpft werden. Entwicklungsteams sollten alle externen Abhängigkeiten nachverfolgen und CVEs/identifizierte Sicherheitsrisiken in diesen Komponenten beheben, indem sie auf sicherere Versionen aktualisieren, wenn diese Sicherheitsrisiken unterliegen.

Maximieren von Code-Provenanzgarantien und Effizienz der Sicherheitsreaktion

Die Kompilierung sollte starke Code-Provenienzgarantien ermöglichen, um die Einführung von Hintertüren und anderen schädlichen Code zu erkennen und zu verhindern. Die resultierenden Daten, die auch für das Debuggen und die Untersuchung wichtig sind, sollten für alle Softwareversionen archiviert werden, um eine effiziente Sicherheitsantwort zu erzielen, wenn sie kompromittiert werden. Die folgenden Compilerswitche generieren Informationen, die für eine Sicherheitsantwort von entscheidender Bedeutung sind:

  • /ZH:SHA_SHA256 in Visual C++ – Stellt sicher, dass ein kryptografisch sicherer Algorithmus verwendet wird, um alle PDB-Quelldateihashes zu generieren.
  • /Zi, /ZI (Debuginformationsformat) in Visual C++ – Stellen Sie zusätzlich zum Veröffentlichen entfernter Symbole zum Sammeln von Absturzdaten und anderen szenarien für öffentliche Verwendung sicher, dass Builds private PDBs für alle veröffentlichten Binärdateien erstellen und archivieren. Binäre Analysetools erfordern vollständige Symbole, um zu überprüfen, ob viele Sicherheitsminderungen zur Kompilierungszeit aktiviert wurden. Private Symbole sind bei der Sicherheitsreaktion kritisch und senken die Debugging- und Untersuchungskosten, wenn Ingenieure fahren, um Schäden zu bewerten und zu begrenzen, wenn ein Exploit auftritt.
  • /SOURCELINK in Visual C++ Linker – Sourcelink-Datei in PDB einschließen: Quelllink ist ein sprach- und quellcodeverwaltungsunabhängiges System, das das Quelldebugging für Binärdateien bereitstellt. Das Quelldebugging erhöht die Effizienz des Bereichs der Vorabüberprüfungen der Sicherheitsüberprüfungen und der Reaktion auf Vorfälle nach der Veröffentlichung.

Aktivieren von Compilerfehlern zum Verhindern von Problemen zur Codeerstellungszeit

Die Kompilierung sollte sicherheitsrelevante Compilerprüfungen als fehlerhafte Fehler aktivieren, z. B.:

Kennzeichnen von Binärdateien als kompatibel mit Sicherheitsminderungen für Betriebssystemlaufzeiten

Compiler- und Linkereinstellungen sollten Codegenerierungsfeatures verwenden, die die Ausführung bösartiger Codes erkennen und mindern, einschließlich:

Verhindern der Offenlegung vertraulicher Informationen

Compilereinstellungen sollten sich für die Verhinderung vertraulicher Informationen entscheiden. In den letzten Jahren haben Forscher unbeabsichtigte Informationslecks entdeckt, die mit Hardwarefeatures wie spekulativer Ausführung stammen.

Auf Softwareebene können vertrauliche Daten an Angreifer übertragen werden, wenn unerwartet ein Verlust aufgetreten ist. Fehler beim Zero-Initialisieren von Puffern und anderen Puffermissbrauchs können private vertrauliche Daten an Angreifer, die vertrauenswürdige API aufrufen, durchlecken. Diese Problemklasse wird am besten behandelt, indem zusätzliche statische Analysen aktiviert und sichere Ressourcencontainer verwendet werden, wie zuvor beschrieben.

  • /Qspectre - Mildern Sie spekulative Ausführungs-Side-Channel-Angriffe – Fügt Barriereanweisungen ein, die die Offenlegung vertraulicher Daten verhindern, die durch spekulative Ausführung erzeugt werden. Diese Entschärfungen sollten für Code aktiviert werden, der vertrauliche Daten im Arbeitsspeicher speichert und über eine Vertrauensgrenze hinweg ausgeführt wird. Microsoft empfiehlt immer, leistungsrelevante Auswirkungen auf geeignete Benchmarks zu messen, wenn Spectre-Mitigations aufgrund der Möglichkeit, Laufzeitüberprüfungen in leistungskritische Blöcke oder Schleifen einzuführen. Diese Codepfade können Entschärfungen über den spectre(nomitigation)declspec Modifizierer deaktivieren. Projekte, die "/Qspectre" aktivieren, sollten auch mit Bibliotheken verknüpft werden, die auch mit diesen Gegenmaßnahmen kompiliert werden, einschließlich der Microsoft-Laufzeitbibliotheken.

2.6 Black box test cases

Zusammenfassung

Black box tests verlassen sich nicht darauf, die inneren Arbeiten der getesteten Komponente zu kennen. Black box tests are designed to test the end-to-end functionality of the features in the product at any layer or level. Black box tests can be functional tests, UI tests, performance tests, and integration tests. Black box tests are valuable for measuring general reliability and functional correctness, and ensuring that the product behaves as expected.

Beziehung zu anderen Abschnitten

Diese Arten von anforderungsbasierten Tests sind nützlich, um die Annahmen im Bedrohungsmodell zu validieren und potenzielle Bedrohungen zu decken, wie in diesem Abschnitt beschrieben. Diese Tests sind nützlich, um die Integration zwischen separaten Komponenten des Produkts zu testen, insbesondere solche, die sich über vertrauenswürdige Grenzen erstrecken, wie im Bedrohungsmodell beschrieben. Black box test cases are also useful for testing all kinds of edge cases for user input validation. Das Testen bekannter Edgefälle und Fehlerfälle sind beide hilfreich. Fuzzing ist auch nützlich, um weniger offensichtliche Fälle zu testen.

Automatisierung und Regression

Führen Sie diese Tests regelmäßig aus, und vergleichen Sie die Ergebnisse mit früheren Läufen, um bruchbrechende Änderungen oder Leistungsregressionen abzufangen. Außerdem kann das Ausführen dieser Tests auf vielen verschiedenen Computern und Installationssetups dazu beitragen, alle Probleme zu behandeln, die sich aus verschiedenen Architekturen oder Setupänderungen ergeben können.

Absturzabbilder

Diese Tests helfen beim Auffinden von Problemen mit zuverlässigkeit, in der Lage zu sein, viele verschiedene Szenarien zu testen, die zu Abstürze, Blockaden, Deadlocks usw. führen können. Durch das Sammeln von Absturzabbildern als Teil von Testfehlern können Sie die Abbilder direkt in Visual Studio importieren, um weiter zu untersuchen, welche Teile des Codes auf diese Probleme stoßen. Wenn Sie Funktionstests in Visual Studio ausführen, können Sie Fehler auf einfache Weise replizieren und debuggen, indem Sie genau sehen, wo innerhalb des schwarzen Felds der Test fehlschlägt, und Sie können Korrekturen schnell testen.

Informationen zu den ersten Schritten mit Debuggingtests finden Sie unter Debug-Komponententests mit Dem Test-Explorer – Visual Studio (Windows)

In Azure

Azure DevOps kann auch bei der Verwaltung und Überprüfung dieser Tests mit der Verwendung von Testplänen helfen. Diese Tests können verwendet werden, um die Genehmigung mit manueller Überprüfung sicherzustellen und automatisierte Tests auszuführen, die den Produktanforderungen zugeordnet sind. Weitere Informationen zu Azure Test-Plänen und deren Verwendung zum Ausführen automatisierter Tests finden Sie hier:

2.7 Codebasierte Testfälle

Zusammenfassung

Codebasierte Testfälle sind ein integraler Bestandteil Standard Die Sicherheit und Zuverlässigkeit Ihres Produkts zu gewährleisten. Diese Tests sollten klein und schnell sein und sollten sich nicht gegenseitig beeinflussen, damit sie parallel ausgeführt werden können. Codebasierte Tests sind für Entwickler einfach, lokal auf ihrem Entwicklungscomputer auszuführen, wenn sie Änderungen am Code vornehmen, ohne sich Gedanken darüber machen zu müssen, ihren Entwicklungszyklus zu verlangsamen.

Typen und Beziehungen zu anderen Abschnitten

Zu den gängigen Typen von codebasierten Testfällen gehören:

  • Komponententests,
  • parametrisierte Tests zur Abdeckung von Funktionen mit mehreren Eingabetypen,
  • Komponententests, um jede Testkomponente getrennt zu halten, und
  • Simuliertes Testen, um Teile des Codes zu überprüfen, die mit anderen Diensten kommunizieren, ohne den Umfang des Tests zu erweitern, um diese Dienste selbst einzuschließen.

Diese Tests basieren auf dem internen Code, der geschrieben wurde, während Black Box-Tests auf den externen funktionalen Anforderungen des Produkts basieren.

Ziel

Durch diese Tests ist das Ziel, eine hohe Testabdeckung über Ihren Code zu erreichen. Sie sollten diese Abdeckung aktiv verfolgen und wo Lücken vorhanden sind. Wenn Sie weitere Tests hinzufügen, die mehr Codepfade ausführen, erhöht sich das Gesamtvertrauen in die Sicherheit und Zuverlässigkeit Ihres Codes.

Visual Studio

Mit den Test-Explorer-Tools in Visual Studio können Sie diese Tests häufig ausführen und schnell Feedback zu Pass-/Fail-Raten und Fehlerspeicherorten erhalten. Viele der Testframeworks unterstützen auch CodeLens-Features, um den Teststatus am Standort des Tests selbst zu sehen, wodurch das Hinzufügen und Standard Beibehalten der Testsuite vereinfacht wird. Der Test-Explorer erleichtert auch die Verwaltung dieser Tests, sodass Testgruppen, benutzerdefinierte Testlisten, Filtern, Sortieren, Suchen und vieles mehr möglich sind.

Weitere Informationen finden Sie unter:

Visual Studio bietet außerdem Tools zum Nachverfolgen der Codeabdeckung. Mit diesen Tools können Sie sicherstellen, dass Codeänderungen, die Sie vornehmen, von vorhandenen Tests abgedeckt werden, oder neue Tests hinzufügen, um neue und ungetestete Codepfade abzudecken. Die Tools zeigen auch den Prozentsatz der Codeabdeckung an, um sicherzustellen, dass sie über einem Zielniveau für das Vertrauen in die allgemeine Codequalität Standard.

Informationen zu diesen Tools finden Sie unter Codeabdeckungstests – Visual Studio (Windows)

In Azure

Azure DevOps kann auch bei der Nachverfolgung von Codeabdeckungsergebnissen für das gesamte Produkt als Teil des Buildpipelineprozesses helfen. Weitere Informationen finden Sie unter Überprüfen der Codeabdeckung – Azure Pipelines.

2.8 Historische Testfälle

Zusammenfassung

Historische Testfälle, auch regressionstestfälle genannt, verhindern, dass alte Probleme wieder auffinden und die Gesamttestabdeckung des Produkts erhöhen. Sie sollten sicherstellen, dass beim Beheben eines Fehlers auch ein entsprechender Testfall hinzugefügt wird. Im Laufe der Zeit, da Korrekturen vorgenommen werden, wird die Gesamtfestigkeit der Testsuite weiter verbessert, wodurch eine bessere Zuverlässigkeit und Sicherheit gewährleistet wird.

Wichtige Qualitäten und Beziehungen zu anderen Abschnitten

Da sie auf Fehlerregressionen testen, sollten diese Tests schnell und einfach ausgeführt werden, damit sie zusammen mit den [Codebasierten Testfällen] ausgeführt werden können und zur Gesamtcodeabdeckung des Produkts beitragen können. Dazu ist die Verwendung realer Beispiele von Kunden, um neue Testfälle zu inspirieren, eine hervorragende Möglichkeit, die Abdeckung und Qualität von Tests zu verbessern.

Visual Studio

Mit Visual Studio können Sie der Suite problemlos Tests hinzufügen, während Sie die Änderungen vornehmen, um den Fehler zu beheben, und die Tests und codeabdeckung schnell ausführen, um sicherzustellen, dass alle neuen Fälle berücksichtigt werden. Das Verweisen auf die Fehler-ID aus Ihrem Problemverfolgungssystem in Ihrem Code, in dem Sie den Test schreiben, ist eine gute Möglichkeit, Regressionstests mit den entsprechenden Problemen zu verbinden. Verwenden Sie Azure Boards und Testpläne zusammen mit Visual Studio:

  • Tests, Testfälle und Probleme zuzuordnen; Und
  • um alle Aspekte eines Problems und der entsprechenden Tests nachzuverfolgen.

Weitere Informationen finden Sie unter:

Schließlich hilft die Integration dieser Tests in den Komponententestbereich, der den Codeabschnitt abdecken soll, dazu beiträgt, die Testsuite organisiert und einfacher zu verwalten. Sie können die Testgruppierung des Test-Explorers verwenden, um die zusammen stehenden Tests effektiv nachzuverfolgen. Weitere Informationen finden Sie unter Ausführen von Komponententests mit Test Explorer – Visual Studio (Windows)

2.9 Fuzzing

Sammel-Fuzzen (auch als Fuzz-Tests bezeichnet) ist eine automatisierte Softwaretesttechnik, bei der ungültige, unerwartete oder zufällige Daten als Eingabe für ein Programm bereitgestellt werden. Das Programm wird dann auf Ausnahmen wie Abstürze, fehlerhafte integrierte oder compilerinjizierte Code assertionen und potenzielle Speicherverluste überwacht.

Leitfaden

Verwenden Sie Fuzzing für alle Software, die möglicherweise nicht vertrauenswürdige Eingaben verarbeiten, die ein Angreifer steuern kann. Wenn Sie eine neue Anwendung und die zugehörige Testsuite erstellen, schließen Sie die Fuzzing für Schlüsselmodule so früh wie möglich ein. Das erstmalige Ausführen von Fuzzing auf einem Softwareteil deckt fast immer tatsächliche Sicherheitslücken auf, die zuvor unbekannt waren. Sobald Sie mit dem Fuzzen beginnen, beenden Sie es nie.

Beziehung zu anderen Abschnitten

Wenn beim Fuzzen ein Fehler gemeldet wird, stellt sie immer einen reproduzierbaren Testfall bereit, der den Fehler veranschaulicht. Dieser Testfall kann reproduziert, aufgelöst und dann zu den historischen Testfällen hinzugefügt werden.

Bei Verwendung beider Sanitizer wie Address Sanitizer (ASan) und Fuzzing:

  • Führen Sie zuerst Ihre normalen Tests mit aktivierten Bereinigungsfunktionen aus, um zu sehen, ob Probleme auftreten, und nachdem der Code sanitizer-sauber Fuzzing starten.
  • Für C oder C++ gibt es Compiler, die das Einfügen von Laufzeit assertionen und Metadaten automatisieren, die ASan aktivieren. Bei der Kompilierung für ASan verknüpfen die resultierenden Binärdateien mit einer Laufzeitbibliothek, die genau 15 Kategorien von Speichersicherheitsfehlern mit null falsch positiven Ergebnissen diagnostizieren kann. Verwenden Sie für C oder C++ bei Verwendung von "LibFuzzer", bei dem ASan zuerst aktiviert werden muss.
  • Verwenden Sie für Bibliotheken, die in Java, C#, Python, Rust usw. geschrieben wurden, das AFL++-Framework.

Schlüsselqualitäten

  • Fuzzing findet Schwachstellen, die häufig von statischer Programmanalyse, erschöpfenden Featuretests und manueller Codeüberprüfung übersehen werden.
  • Fuzzing ist eine effektive Möglichkeit, Sicherheits- und Zuverlässigkeitsfehler in der Software zu finden, sodass der Microsoft Security Development Lifecycle bei jeder nicht vertrauenswürdigen Schnittstelle jedes Produkts fuzzing erfordert (siehe auch Bedrohungsmodellierung).
  • Verwenden Sie immer Fuzzing für Software, die möglicherweise nicht vertrauenswürdige Eingaben verarbeiten.
  • Fuzzing ist für eigenständige Anwendungen mit großen Datenparsern effektiv.

Azure und GitHub CI/CD

Ändern Sie Ihre Builds, um die kontinuierliche Erstellung von ausführbaren Dateien zu unterstützen, die LibFuzzer oder AFL++ verwenden. Sie können zusätzliche Computerressourcen hinzufügen, die für Fuzzen bei Diensten wie OSS-Fuzz oder OneFuzz erforderlich sind.

2.10 Webanwendungsüberprüfung

Zusammenfassung

Im Rahmen von Microsoft Visual C++ unter Windows empfiehlt Microsoft Folgendes:

  • Bevorzugen Sie TypeScript, JavaScript und ASP.NET für Webanwendungen.
  • Schreiben Sie keine Weberweiterungen in C++. Microsoft hat ActiveX veraltet.
  • Wenn Code in Emscripten/WASM kompiliert wird, gelten nicht mehr C++ und andere Tools.
  • Microsoft stellt RESTler bereit, ein zustandsbehafteter REST-API-Fuzzer.

Übersicht und Schlüsselqualitäten

Ein Webanwendungsscanner durchforstet eine Webanwendung, indem er seine Webseiten durchforstet und auf Sicherheitsrisiken überprüft. Diese Durchforstung umfasst die automatische Generierung bösartiger Eingaben und die Auswertung der Antworten der Anwendung. Wichtig ist, dass das Scannen von Webanwendungen Folgendes abdecken/unterstützen muss:

  • Katalogisiert alle Web-Apps in Ihrem Netzwerk, einschließlich neuer und unbekannter Apps, und skaliert von einer Handvoll Apps auf Tausende.
  • Umfassende Suche nach Softwareversionen, SOAP- und REST-API-Diensten und APIs, die von mobilen Geräten verwendet werden.
  • Einfügen von Sicherheitsgrundtypen in die Anwendungsentwicklung und -bereitstellung in DevOps-Umgebungen. Diese Grundtypen funktionieren mit dem Crawler.
  • Schadsoftwareerkennung.

2.11 Überprüfen der enthaltenen Softwarekomponenten

Zusammenfassung

Behandeln Sie Ihren C++-Code genauso wie Code, der in anderen Programmiersprachen geschrieben wurde, und wenden Sie alle Software Composition Analysis (SCA) and Origin Analysis (OA)-Tools an, die von Ihrem Unternehmen auf Ihren C++-Code übernommen werden. Workflows und Sicherheitsscans sollten als Teil von CI/CD-Systemen (kontinuierliche Integration und kontinuierliche Bereitstellung) entworfen werden.

Upstream-Verteidigung

Um das Risiko von Angriffen auf vorgelagerte Abhängigkeiten zu verringern, sollten Quellen/Komponenten von Drittanbietern auf einer unternehmensgesteuerten Ressource gespeichert werden, mit der SCA- und OA-Tools ausgeführt werden.

  • Tools sollten überprüfen und warnen, wenn Sicherheitsrisiken (einschließlich öffentlicher Datenbanken) identifiziert werden, z. B.: Start | CVE
  • Führen Sie statische Analysen für alle Softwarekomponenten aus, die in Ihrer Anwendung/Repository enthalten sind, um anfällige Codemuster zu identifizieren.

Abhängigkeitsschutz

Führen Sie eine Überprüfung der Abhängigkeiten durch und Standard, um zu überprüfen, ob alle diese Vorkommen von Ihren SCA- und OA-Tools berücksichtigt und abgedeckt werden.

  • Komponenten sollten regelmäßig überwacht und auf die neuesten überprüften Versionen aktualisiert werden.
  • Paketfeedabhängigkeiten.
  • SCA/OA-Tools umfassen und überwachen alle Paketabhängigkeiten, die aus einem einzigen Feed stammen.

SBOM

Erstellen Sie ein SBOM (Softwareabrechnung von Materialien) mit Ihrem Produkt, in dem alle Abhängigkeiten aufgeführt sind, z. B.:

  • origin (z. B. URL (Uniform Resource Locator))
  • version
  • Konsistenz (z. B. SHA-256-Quellhash) und andere Mittel zur Überprüfung der Konsistenz wie deterministische Builds.
  • Erfordern und überwachen Sie SBOM-Dateien in Softwareabhängigkeiten oder erstellt als Teil eines Builds, einschließlich OSS (Open-Source-Software).
  • Microsoft ist standardisiert und empfiehlt SPDX (Software Package Data Exchange) Version 2.2 oder höher | Linux Foundation als SBOM-Dokumentformat.
  • Builddeterminismus kann verwendet werden, um bitweise identische Binärdateien unabhängig zu produzieren und unabhängige Überprüfungen der Integrität bereitzustellen:
    • Nachweis von Erstanbietern oder Drittanbietern zur Reproduzierbarkeit
    • Andere Techniken wie die binäre Signatur über eine vertrauenswürdige Zertifikatquelle können auch einige Sicherheiten der binären Integrität bieten.

Weitere Ressourcen

Microsoft-Lösungen umfassen die folgenden Anleitungen und Produkte: