Verwenden Sie Agentic AI, um intelligentere API-Tests zu generieren. In wenigen Minuten. Erfahren Sie mehr >>
Eine Unze Prävention: Sicherheit durch Software-Codierungsstandards
Die Implementierung und Aufrechterhaltung des richtigen Codierungsstandards für Ihre Entwicklungsprojekte ist der Schlüssel zur Bereitstellung sicherer Softwarelösungen. In diesem Beitrag erläutert unser Experte, warum Sie sicherstellen sollten, dass Sie den richtigen Codierungsstandard einhalten und wie Sie dies tun können.
Die Implementierung und Aufrechterhaltung des richtigen Codierungsstandards für Ihre Entwicklungsprojekte ist der Schlüssel zur Bereitstellung sicherer Softwarelösungen. In diesem Beitrag erläutert unser Experte, warum Sie sicherstellen sollten, dass Sie den richtigen Codierungsstandard einhalten und wie Sie dies tun können.
Software hat sich vom Desktop auf nahezu alles ausgeweitet, was wir berühren. Von intelligenten Thermostaten über Infusionspumpen bis hin zu Autos ist Software allgegenwärtig und wächst stetig. Die sogenannten „Dinge“ des Internets der Dinge (IoT) enthalten zunehmend mehr Logik. Damit steigt auch das Ausfallrisiko. Viele dieser Geräte werden in sicherheitskritischen Bereichen wie der Medizin und der Automobilindustrie eingesetzt, wo sie ein hohes Verletzungsrisiko bergen.
Die meisten Unternehmen, die Geräte bauen, betrachten die aktuelle Softwareentwicklung zu Recht als eine fast schon verrückte Truppe von Cowboys und Chaos. Doch es gibt Hoffnung. Software KANN und MUSS als Ingenieurspraxis behandelt werden. Kodierungsstandards, die fester Bestandteil guter Softwareentwicklungspraxis sind, führen uns vom „Build, Fail, Fix“-Zyklus zu einem „Design, Build, Deliver“-Zyklus mit hoher Qualität, Sicherheit und Schutz.
Wie sich herausstellt, bieten dieselben Standards auch Vorteile in den Bereichen Cybersicherheit, da sie doppelte Pflichten erfüllen. Dieser Beitrag beschreibt:
Die Auswirkungen von Software auf die reale Welt werden häufig nicht berücksichtigt. Eines meiner Hauptthemen, über das ich als Evangelist bei Parasoft ständig diskutiere, ist, dass Softwareentwicklung eigentlich Engineering sein sollte.
Wir nennen Softwareentwickler häufig Softwareentwickler, aber das ist nicht unbedingt die richtige Bezeichnung für ihre heutige Arbeitsweise. Die Weiterentwicklung zu einer guten Software-Engineering-Praxis führt dazu, dass die Kosten sinken und die Qualität steigt. Ein wesentlicher Teil davon ist die Übernahme von Standards – insbesondere von Codierungsstandards.
Das Zeitalter softwaredefinierter Fahrzeuge, medizinischer und industrieller IoT-Geräte sowie ständig vernetzter Geräte ist angebrochen. Software schleicht sich in Produkte, Geräte und andere Orte ein, an die wir nie gedacht hätten. Wir müssen jetzt gründlich über die Software in diesen Produkten und die damit verbundenen Auswirkungen nachdenken.
Eines der interessanten Dinge, die ich zu erklären versuche, ist, dass das Erstellen guter Software sich vom Erstellen eines Autos unterscheidet. Wenn ich versuche, ein hochwertiges Auto zu bauen, muss ich mehr für Materialien und mehr Zeit für den Bau aufwenden. Es stellt sich heraus, dass Sie in Software nicht mehr für die Erstellung hochwertiger Software ausgeben. Sie geben mehr aus, um Software von schlechter Qualität zu erstellen.
Wir müssen verstehen, dass in der Software die meisten Fehler vom Programmierer stammen, der sie in das Produkt einfügt. Wenn wir bei der Entwicklung der Software keine Fehler mehr einführen können, können wir viel bessere Software zu einem niedrigeren Preis haben.
Dieses Zitat hier stammt aus einem Vortrag aus dem Jahr 1972 mit dem Titel „Der bescheidene Programmierer,“ geschrieben von Edsger W. Dijkstra. Es ist auch heute noch sehr relevant.
Es ist wichtig zu wissen, wie sich Qualität auf die Kosten der Softwareentwicklung auswirkt. Kapern JonesDer Forscher beobachtet dies seit Jahrzehnten und führt jährlich eine Umfrage zu den Softwarekosten durch. Die Zahlen ändern sich von Jahr zu Jahr kaum. Die Daten zeigen, dass die typischen Kosten für Software – von den Anforderungen über die Programmierung bis hin zur Wartung – mit jeder Phase steigen. Die Art und Weise, wie Teams mit der Qualität umgehen, entscheidet jedoch darüber, ob ihr Prozess gesund oder „pathologisch“ ist.
Softwarequalität 2011: Ein Überblick über den Stand der Technik in der Software – Capers Jones
Es macht Sinn, dass die Kosten relativ gering sind, wenn wir einen Fehler direkt beim Schreiben des Codes finden – zum Beispiel ein paar Minuten Zeit eines Entwicklers. Wenn es gelingt, 85 % der Fehler in der Entwicklungsphase zu beseitigen, hat das große Auswirkungen auf die Kosten. Betrachten Sie die mittlerweile berühmte Grafik von Capers Jones, die die durchschnittlichen Kosten für die Behebung von Fehlern in jeder Entwicklungsphase zeigt:
Quellen – Applied Software Measurement, Capers Jones, 1996, Building Security into The Software Life Cycle, Marco M. Morana, 2006
Die Behebung von Fehlern nach der Veröffentlichung kostet etwa 16,000 US-Dollar (möglicherweise viel mehr), basierend auf Untersuchungen zu realen Unternehmen, die echte Software entwickeln, und nicht auf einem theoretischen Modell. Wenn wir uns die späten Qualitäts- und Sicherheitsbemühungen wie Penetrationstests ansehen, stellen wir fest, dass die hier festgestellten Sicherheitsprobleme am teuren Ende des Zyklus liegen. Es ist wahrscheinlich 15-mal so teuer wie das Auffinden von Schwachstellen durch Tests im Vergleich zu frühen Sicherheitsüberprüfungen.
Ein veralteter und nachweislich falscher Ansatz besteht darin, die Qualität Ihrer Software durch Tests am Ende des Lebenszyklus, kurz vor der Veröffentlichung, zu verbessern. In der Fertigungswelt ist man sich bewusst, dass dies unmöglich ist, aber aus irgendeinem Grund glauben wir, Qualität und Sicherheit in die Software hineintesten zu können.
Die Gründe, warum ich sage, dass Softwareentwicklung fast nie Engineering ist, sind diese gemeinsamen Merkmale der aktuellen Softwareentwicklung:
Das Ziel von Software-Codierungsstandards besteht darin, bewährte Programmierpraktiken einzuführen, die zu sicherem, zuverlässigem, testbarem und wartbarem Code führen. In der Regel bedeutet dies, bekannte unsichere Codierungspraktiken oder Code zu vermeiden, der unvorhersehbares Verhalten verursachen kann. Dies wird in Programmiersprachen wie C und C++ von entscheidender Bedeutung, in denen das Potenzial hoch ist, unsicheren oder unsicheren Code zu schreiben.
Ich denke jedoch, dass sich die Branche mit diesen Programmierstandards verirrt hat. In den letzten zehn Jahren haben sich die Tools (z. B. statische Analysetools) von der Erkennung potenziell problematischer Codes, die unsicher sind oder eine bekannte Sprachschwäche aufweisen, zu einem Fokus auf die Suche nach Fehlern als eine Form des frühen Testens, auch als Linksverschiebung bezeichnet, verschoben.
Obwohl das Suchen nach Fehlern wichtig ist, ist das Erstellen von Sound-Software eine produktivere Aktivität. Was wir tun sollten, ist die Erstellung und Durchsetzung von Standards, um die Situation zu vermeiden, in der Fehler überhaupt erst auftreten - und noch weiter nach links zu verschieben.
Um dies zu sichern, betrachten Sie die Forschungsprojekte Dies wurde vom Software Engineering Institute (SEI) durchgeführt, wo nicht überraschend festgestellt wurde, dass Sicherheit und Zuverlässigkeit Hand in Hand gehen und dass die Sicherheit von Software anhand der Anzahl und Art der festgestellten Qualitätsfehler vorhergesagt werden kann. Darüber hinaus sind kritische Fehler häufig Codierungsfehler, die durch Inspektionen und Tools wie statische Analysen verhindert werden können.
Dieser Beitrag geht nicht näher auf jeden dieser Codierungsstandards ein, es gibt jedoch eine beträchtliche Menge an Arbeit in den folgenden Industriestandards. Obwohl ihre Anwendung möglicherweise spezifisch für einen bestimmten Typ ist, werden diese Standards in vielen Branchen übernommen. Hier sind einige Beispiele etablierter Codierungsstandards für Sicherheit und Schutz.
Lassen Sie uns überlegen MISRA C., das ich erwähnt habe, ist nicht nur für Automobilanwendungen gedacht. Es handelt sich jedoch um einen Standard, der seit 1998 verwendet wird und klar definiert ist. Es wird alle paar Jahre aktualisiert. Während sich die Sprachen C und C++ weiterentwickeln, entwickeln sie auch die Standards dafür weiter. Es handelt sich um einen sehr flexiblen Standard, der unterschiedliche Schweregrade berücksichtigt und über eine dokumentierte Strategie für den Umgang und die Dokumentation von Abweichungen verfügt.
Da es sich um eine Technologie handelt, die Verstöße gegen Codierungsstandardrichtlinien, wie z. B. die statische Analyse, erkennen kann, berücksichtigen neuere Versionen von MISRA, welche Richtlinien entscheidbar (mit hoher Präzision durch Tools erkennbar) sind und welche nicht. Dies bringt uns zum Thema der Einführung und Durchsetzung und der Bedeutung statischer Analysetools in Codierungsstandards.
Untersuchungen zeigen, dass eine unzureichende Fehlerbeseitigung die Hauptursache für qualitativ schlechte Software ist. Programmierer sind zu etwa 35 % effizient darin, Fehler in ihrer eigenen Software zu finden. Später im Entwicklungszyklus liegen die meisten Fehler, die wir nach all den Design-Reviews, Peer-Reviews, Unit-Tests und Funktionstests beseitigen können, bei etwa 75 %.
Eine statische Analyse kann bei ordnungsgemäßer Verwendung in einem vorbeugenden Modus die Fehlerbeseitigung auf etwa 85% erhöhen. Der Schwerpunkt der statischen Analyse für die meisten Unternehmen liegt heute jedoch auf der Erkennung und der schnellen Lösung.
Weitere Vorteile sind möglich, wenn statische Analysewerkzeuge verwendet werden, um bekannte schlechte Programmierpraktiken und Sprachfunktionen zu verhindern. Hier kommen Codierungsstandards als Richtlinien und Teilmengen der Programmiersprache ins Spiel, die verhindern, dass häufig auftretende Fehler wie Pufferüberläufe oder fehlende Initialisierung in den Code geschrieben werden.
Stellen Sie sich ein Beispiel vor, bei dem beim Testen ein ziemlich komplexer Pufferüberlauffehler erkannt wird, möglicherweise mit einem dynamischen Anwendungssicherheitstool (DAST). Dies ist ein Glücksfall, da Ihr Test gerade den Codepfad ausgeführt hat, der den Fehler enthält. Sobald es erkannt und debuggt wurde, muss es erneut getestet werden und so weiter. Bei einer statischen Analyse mithilfe der Flussanalyse wurde dieser Fehler möglicherweise ebenfalls gefunden, dies hängt jedoch von der Komplexität der Anwendung ab.
Die Erkennung von Laufzeitfehlern ist präzise, überprüft jedoch nur die von Ihnen ausgeführten Codezeilen. Es ist also nur so gut wie Ihre Testcode-Abdeckung. Überlegen Sie, ob ein Codierungsstandard den Code verboten hat, der diesen Fehler überhaupt aktiviert hat.
Codierungsstandards wie MISRA C beschreiben beispielsweise nicht, wie nicht initialisierter Speicher erkannt wird, sondern leiten Programmierer vielmehr dazu an, Code zu schreiben, der gar nicht erst zu einem solchen Fehler führt. Ich glaube, das ist eher ein technischer Ansatz: Programmieren nach bekannten und anerkannten Standards. Nehmen wir zum Beispiel Tiefbau und Brückenbau.
Wir würden nicht den Ansatz verfolgen, eine Brücke zu bauen und sie dann zu testen, indem wir immer größere Lastwagen darüber fahren, bis sie einstürzt, das Gewicht des letzten erfolgreichen Lastwagens messen und sie dann erneut bauen, um diesem neuen Gewicht standzuhalten. Dieser Ansatz wäre jedoch dumm, er ähnelt jedoch nicht unähnlich der Art und Weise, wie wir an die Softwareentwicklung herangehen.
Sobald ein Softwareteam einen Codierungsstandard anwendet und die statische Analyse ordnungsgemäß angewendet wird, kann es Fehler frühzeitig erkennen und verhindern. Mit anderen Worten, anstatt frühzeitig einen Fehler zu finden, was gut ist, ändert das Team die Art und Weise, wie Code geschrieben wird, was besser ist!
Betrachten Sie die Heartbleed Verletzlichkeit. Es gibt jetzt Detektoren für diese spezielle Sicherheitsanfälligkeit, aber es gibt eine Möglichkeit, Code so zu schreiben, dass Heartbleed überhaupt nicht hätte passieren können. Prävention ist eine bessere und sicherere Methode.
Dykstra sagte: „Wer wirklich zuverlässige Software möchte, wird feststellen, dass er von vornherein Mittel und Wege finden muss, die Mehrzahl der Fehler zu vermeiden.“ Eine solide Präventionsmethode ist kostengünstiger als die Kosten für die Behebung dieser Fehler.
Codierungsstandards verkörpern fundierte technische Prinzipien für die Programmierung in ihren jeweiligen Sprachen und bilden die Grundlage für jeden präventiven Ansatz. Die Kosten für gute Software sind geringer als die Kosten für schlechte Software. Wenn Sie heute keine statische Analyse verwenden oder sie nur zur Früherkennung verwenden, werfen Sie einen Blick auf die statischen Analysetools von Parasoft für C und C ++, Javacsowie C # und VB.NET mit einer umfangreichen Bibliothek von Checkern für alle gängigen Sicherheitsstandards.
Weiterführende Inhalte
