Wann ersetzt Software Composition Analysis (SCA) SAST oder DAST?

Die kurze Antwort lautet nie. Dort habe ich Ihnen gerade genug Zeit gespart, damit Sie das Richtige tun und SAST und DAST ausführen und daran arbeiten können, Ihren Code zu härten, anstatt zu versuchen, die Sicherheit in Ihrer Anwendung zu testen.

Klingt das nach den Anfängen eines Geschwätzes? Kann sein. Aber schauen Sie, jedes Mal, wenn eine neue Technologie, ein neuer Prozess oder eine neue Technik hinzukommt, denken Menschen, dass dies die Antwort auf alles ist. Es wird die Software-Sicherheit lösen, Entwicklungs- und Testzeit sparen und vielleicht sogar den Welthunger beseitigen, während es dabei ist. Ok, ich werde dramatisch. Zu sagen, dass SCA letztendlich SAST ersetzen wird, bedeutet im Wesentlichen, dass Sie Ihre eigenen nicht mehr überprüfen müssen, da Sie nach bekannten Schwachstellen im Code anderer Personen suchen.

Was ist Software Composition Analysis (SCA)?

SCA ist Software Composition Analysis. Theoretisch funktioniert es Hand in Hand mit einer Software-Stückliste (etwas, das derzeit meistens nicht existiert) und verfolgt die anderen Bibliotheken und Komponenten, die in Ihrer Anwendung verwendet werden. Derzeit scannen diese Tools meist nur die Open-Source-Komponenten für Ihre Anwendung und arbeiten nicht unbedingt mit einer Stückliste. ((HINWEIS: Einige dieser Tools führen auch andere Funktionen aus, z. B. das Ausschneiden und Einfügen von Snippets aus OSS-Projekten oder das Erkennen und Verwalten von OSS-Lizenzproblemen. Beide sind interessant und wichtig, aber immer noch kein Ersatz für das, was SAST tut.)

Eine Hauptfunktion von SCA besteht darin, Komponenten in Ihrer Anwendung auf bekannte Schwachstellen zu überprüfen. Dies ist wichtig, damit Sie Zero-Day-Probleme vermeiden und das Problem beheben können, dass Sie möglicherweise keine Quelle für einige Komponenten haben und daher SAST nicht für diese verwenden können.

OWASP bietet Tools für die Sicherheit der Lieferkette

Ich muss sagen, dass SCA sicherlich ein wertvoller Bestandteil Ihres Toolkits zur Sicherung Ihrer Softwaresysteme ist. Die beliebte und nützliche Sicherheitsorganisation Open Web Application Security Project (OWASP) hat dieses Konzept sogar in die neueste Version der beliebten OWASP Top 10-Liste der kritischsten Sicherheitsrisiken aufgenommen. Es erscheint als Artikel A9 - Verwenden von Komponenten mit bekannten Sicherheitslücken. Wenn Sie OWASP nicht verwenden, sollten Sie dies wahrscheinlich tun. Wenn Sie Ihre Anwendung nicht auf bekannte Sicherheitslücken überprüfen CVEund  NVD Datenbanken sollten Sie. Solche Quellen verfolgen echte Angriffe und welche Patches und anderen Abhilfemaßnahmen verfügbar sind.

OWASP hat sogar ein Tool namens erstellt OWASP-Abhängigkeitsprüfung das kann diese Arbeit für Sie erledigen. Wie alles, was OWASP zu bieten hat, ist es kostenlos. Dependency-Check ist ein Dienstprogramm zur Analyse der Softwarezusammensetzung, das Projektabhängigkeiten identifiziert und prüft, ob bekannte, öffentlich bekannt gegebene Schwachstellen vorliegen.

Die Sicherheit der Software-Lieferkette ist ein kritischer Bestandteil der Anwendungssicherheit

Ich muss zugeben, dass die Software-Lieferkette vor nicht allzu vielen Jahren ein meist übersehenes Thema war. Einige Schlüsselpersonen, von denen viele Teil der Software Supply Chain Assurance-Forum (SSCA) hat hart daran gearbeitet, diese Schwachstelle in der Anwendungssicherheit hervorzuheben, indem es sich nicht nur auf Ihren Code, sondern auch auf Ihre Lieferkette konzentrierte. In der Tat, SSCA-Forum, das von der gehostet wird US Verteidigungsministerium (Verteidigungsministerium), Department of Homeland Security (DHS), Allgemeine Dienstverwaltung (GSA) und die National Institute of Standards and Technology (NIST) hieß früher Software Assurance Forum (SwA) und änderte den Namen, um die Lieferkette stärker in den Fokus zu rücken. Aber die Absicht war es erweitern den Fokus, nicht von Ihrem Code auf den eines anderen verschieben.

Dieses Software- und Supply-Chain-Assurance-Forum (SSCA) bietet Regierungs-, Industrie- und akademischen Teilnehmern aus der ganzen Welt die Möglichkeit, ihr Wissen und ihre Expertise in Bezug auf Software- und Lieferkettenrisiken, effektive Praktiken und Minderungsstrategien, Tools und Technologien sowie Lücken in Bezug auf Personen, Prozesse oder Technologien auszutauschen beteiligt.

In der Praxis handelt es sich bei SCA um eine Testaktivität, bei der sichergestellt wird, dass Ihre Anwendung anhand einer Liste überprüft wird und mit dieser Liste übereinstimmt (z. B. bekannte Schwachstellen wie NVD). Umgekehrt ist SAST in erster Linie KEINE Testfunktion (Häresie, ich weiß ...), sondern eine technische Funktion. Der kleinste Wert von SAST besteht darin, eine Schwachstelle oder Schwachstelle früher zu finden als dies beim Pen-Test der Fall wäre. Der größte Wert von SAST besteht darin, Sie an erster Stelle beim Härten Ihres Codes zu unterstützen. Versuchen Sie nicht länger, Lecks zu schließen und Code zu erstellen, der überhaupt nicht leckt. Nur so können Sie bei der Anwendungssicherheit die Nase vorn haben. Wenn Sie es perfekt machen, benötigen Sie immer noch SCA, da Sie immer noch das Problem all dieser Komponenten in Ihrer Anwendung sowie anderer Programme haben, mit denen es interagiert, und des Betriebssystems selbst. Wenn Sie SCA gut machen, brauchen Sie immer noch SAST, denn während Sie Probleme im Code anderer Leute behoben haben, haben Sie nichts für sich selbst getan. Die Zwecke ergänzen sich, ersetzen sich nicht.

Zusammenfassend ist SCA großartig, Sie wollen es, tatsächlich brauchen Sie es. Ich bin froh, dass es mehr Aufmerksamkeit bekommt als in der Vergangenheit. Zu sagen, dass es DAST oder SAST ersetzen wird, ist wie zu sagen, dass Sie einen Hammer haben und keinen Schraubendreher benötigen.