Erkenntnisse zum Softwaretest aus dem CrowdStrike-Vorfall

Die CrowdStrike-Katastrophe wird als Beispiel dafür in die Geschichte eingehen, wie mangelnde Konzentration auf Qualität und Softwaretests dem Image eines Anbieters und der Benutzerbasis schadet. Was auch immer die Grundursachen sind, es ist fair, CrowdStrike Zeit zu geben, seine Probleme zu analysieren und Ergebnisse mitzuteilen. Lassen Sie uns diese Situation jedoch nutzen, um einige allgemeine Beobachtungen zur Softwarequalität anzustellen.

Das Gleichgewicht zwischen Geschäftsrisiko und Softwarequalitätskosten

Angesichts der Häufigkeit der Updates, die CrowdStrike in seinem schwierigen Sicherheitsgeschäft veröffentlicht, ist es offensichtlich, dass die Automatisierung ihrer Entwicklungsprozesse hervorragend ist. Hochautomatisierte CI/CD-basierte Workflows sind in der modernen Softwareentwicklung absolut unverzichtbar. Kontinuierliche Integration und Bereitstellung verbessern die Effizienz der Softwareteams und ermöglichen Softwareentwicklung im großen Maßstab.

Wenn Sie den gesamten Prozess automatisiert und instrumentiert haben, können Sie Zahlen und Statistiken einsehen – und die Kosten besser verstehen. Wenn Sie messen können, sind Sie versucht, zu optimieren. Besonders in einer Branche, die ständigem Druck ausgesetzt ist, schlank, flexibel und reaktionsschnell zu sein. Die Abwägung von Geschäftsrisiken und den Kosten der Softwarequalität ist in der Branche ein bekanntes Problem.

Test- und Qualitätsprozesse sind einfache Optimierungsziele. Optimierung bedeutet oft, die Anzahl der Tests zu reduzieren. Wir wollen damit nicht sagen, dass dies im Fall CrowdStrike passiert ist, aber dieser Geist ist bei Softwareunternehmen sichtbar. Die Implementierung mehrerer Testtechniken kostet Zeit und Mühe. Außerdem entstehen Wartungskosten.

Zeit und Kosten des Tests

Selbst wenn wir ein mäßig komplexes System betrachten, das aus Frontend und Backend mit Microservices besteht und alles mit C++, Java und vielleicht Python implementiert ist, muss ein solider Qualitätssicherungsprozess wahrscheinlich Folgendes umfassen:

• Statische Analyse für alle Programmiersprachen
• Unit-Test
• API-Tests
• Service-Virtualisierung
• Last- und Leistungstests

Ebenfalls, Codeabdeckung sollten aus allen Arten von Laufzeittests gesammelt werden. Dies ist ein erheblicher Implementierungs- und Wartungsaufwand.

Selbst wenn sie erfolgreich eingesetzt werden, verfallen Testverfahren, deren Wartung teurer ist, mit der Zeit und werden aufgegeben. Teams überprüfen regelmäßig Statistiken mit Fehlern, die bei einer bestimmten Testmethode gefunden wurden, und fragen sich: Ist es unseren Aufwand wert?

Mit der Zeit konzentrieren sich Teams eher auf ein oder zwei Testarten, die sich leicht automatisieren und warten lassen. Grüne Häkchen neben Pull Requests erzeugen mit der Zeit falsches Vertrauen und unterdrücken das Nachdenken darüber, ob das Risiko ausreichend gemindert ist.

Die obige Schlussfolgerung ist nicht bahnbrechend. Das war schon immer so. Unseren Beobachtungen zufolge nimmt jedoch paradoxerweise mit zunehmendem Automatisierungsgrad die Toleranz der Teams gegenüber testbezogenen Ausgaben und Verzögerungen ab.

Ein umfassender, nach links verschobener Testansatz

Die Wahrheit über Softwaretests ist, dass es kein Patentrezept gibt. Qualität kann man nicht durch Testen in Software einbauen. Stattdessen ist ein ganzheitlicher Ansatz für den gesamten SDLC erforderlich, der Folgendes umfasst:

1. Erstellen Sie von Anfang an hochwertige Software mit einem Shift-Left-Testansatz.
2. Entwicklung einer robusten und umfassenden Teststrategie zur Steigerung der Code-Vertrauenswürdigkeit.

Es gibt viele Testtechniken – jede davon ist gut geeignet, eine bestimmte Klasse von Problemen zu erkennen. Hohe Softwarequalität und Zuverlässigkeit erfordern Kombination mehrerer Testmethoden. Die sogenannte Optimierung Ihres gesamten Testprozesses auf die Einbeziehung nur einer oder zwei Methoden ist eine Tortur.

Die Versuchung, die Tests zu reduzieren, ist noch größer, wenn es keine Vorschriften für bestimmte Vorgehensweisen gibt. Für sicherheitskritische Systeme gibt es spezielle Normen, die eine Risikoanalyse vorschreiben und den Einsatz einer Reihe von Softwaretesttechniken empfehlen. Wenn Sie ein Produkt auf den Markt bringen möchten, müssen Sie nachweisen, dass es den Normen entspricht.

Funktionale Sicherheitsstandards kategorisieren Funktionen normalerweise nach ihrer Kritikalität und bieten verschiedene Empfehlungsstufen für bestimmte Testtechniken. Unten sehen Sie ein Beispiel aus ISO 26262, einem beliebten Standard in der Automobilindustrie.

Die Einzelheiten dieser Tabelle sind für unsere Diskussion nicht wichtig. Die relevante Erkenntnis ist, dass Sicherheitsnormen verschiedene Kritikalitätsstufen für Systeme (AD) unterscheiden und verschiedene Empfehlungen zum Testen von Systemen enthalten. Wenn Sie auf eine bestimmte Testmethode verzichten möchten, die die Norm für eine bestimmte Risikostufe als angemessen erachtet, müssen Sie Ihrem Gutachter eine wirklich solide Begründung liefern.

Der Sicherheitsprozess umfasst Gefahrenanalyse und Risikobewertung. Dies ist eine Grundlage für die Definition von Sicherheitszielen, die Implementierung von Funktionen und entsprechende Tests entsprechend einem definierten Risikoniveau. Ohne in branchenspezifische Fachsprache zu verfallen, geht es darum, kritische Szenarien zu definieren und sicherzustellen, dass diese verhindert oder ausreichend getestet werden.

Fazit

Im Fall von Falcon scheint jedes Szenario, das den Computer am Booten hindert, kritisch zu sein. Es sollten Sicherheitsmaßnahmen dagegen ergriffen werden. Zumindest sollten umfangreiche Tests durchgeführt werden, um das Problem zu erkennen. Und diese Tests sollten priorisiert werden.

Die Entwicklung sicherheitskritischer Software ist enorm teuer. Nein, wir schlagen nicht vor, alle Produkte mit den gleichen Einschränkungen zu entwickeln wie in der sicherheitskritischen Welt. Das wäre unpraktisch und aus geschäftlicher Sicht schwer zu rechtfertigen.

Es ist jedoch interessant zu beobachten, wie scheinbar unkritische Systeme wie CrowdStrikes Falcon unser Leben beeinflussen. Störungen im Notrufbetrieb gefährden sicherlich die Gesundheit und möglicherweise sogar das Leben einiger unglücklicher Personen.

Was können Entwicklungsteams daraus also lernen?

• Seien Sie sich der Dynamik bewusst, die sie ständig dazu drängt, Abstriche zu machen und zugunsten kurzfristiger Geschäftsgewinne Kompromisse bei der Qualität einzugehen, und widerstehen Sie ihnen.
• Verstehen Sie die wahre Kritikalitätsstufe der von ihnen erstellten Systeme, einschließlich des Geschäftsrisikos für das Unternehmen.
• Ein besseres Verständnis für bewährte Vorgehensweisen und Prozesse in Branchen zu erlangen, in denen Produkte direkte Auswirkungen auf das Leben von Menschen haben, kann eine hilfreiche Übung und eine wertvolle Inspirationsquelle sein.

Durch Hebelwirkung Parasoft C- und C++-Lösungen für die statische Analyse, Unit-Tests, kontinuierliche Integration und Überwachung hätte CrowdStrike seine Software-Update-Probleme in Echtzeit erkennen und beheben und so die Integrität seiner Software-Releases aufrechterhalten können.

Unser Expertenteam ist der Ansicht, dass Softwaretests eine Ingenieurdisziplin sind und dass die Vermeidung von Software-Katastrophen Zeit und Mühe erfordert. Unsere Lösungen helfen Teams, Kosten zu minimieren und die Kontrolle über Geschäftsrisiken zurückzugewinnen. Jede Art von Geschäft mit hohen Einsätzen kann von unserer Expertise in den Bereichen statische Code-Analysatoren, Code-Abdeckung, Unit-Test-Frameworks, API-Tests, Service-Virtualisierung und mehr profitieren.