CAST Application Intelligence Platform (AIP)

Softwarequalität bewerten: Wissenswertes zu CISQ und OMG

Stellen Sie sich einmal vor, Sie möchten eine Ihrer selbst entwickelten Anwendungen auf deren Qualität hin überprüfen. Um eine möglichst zuverlässige Aussage über die Effizienz, Stabilität und Sicherheit der Applikation zu bekommen, setzen Sie beispielsweise ein Analysetool wie CAST AIP (Application Intelligence Platform) ein. Doch woher nehmen Sie die Gewissheit, dass das Analysewerkzeug auch auf die richtigen Methoden und Standards setzt, mit denen die Zuverlässigkeit einer Software sichergestellt werden kann?

Genau für diesen Zweck gibt es umfassende Regelwerke, auf denen Analysetools wie die CAST AIP basieren. So werden für die Beurteilung einer Anwendung bis zu 1.200 Bewertungskriterien herangezogen, die die Software anhand bestimmter Qualitätsindikatoren bemisst und bewertet. Hierbei werden vor allem Kriterien überprüft wie Leistungseffizienz, Zuverlässigkeit, Sicherheit, Administration und Anpassungsfähigkeit .

Leistungseffizienz: Besonders der Quellcode und die Eigenschaften der zugehörigen Software-Architektur stellen die Leistungseffizienz einer Anwendung sicher. Die Effizienz einer Applikation spielt vor allem in Hochleistungsumgebungen eine große Rolle, da es hier auf schnelle Transaktionen ankommt und ein möglichst verlustfreies Ausführen des Quellcodes im Vordergrund steht. Damit gibt die Analyse dieses Kriteriums Aufschluss darüber, wie sich fehlerhafter Code negativ auf die Unternehmensziele einer Firma auswirken kann. So spielt die Leistungseffizienz beispielsweise bei kundenorientierten Applikationen wie einem Onlineshop eine große Rolle.

Zuverlässigkeit: Elastizität und Stabilität sagen etwas über die Zuverlässigkeit einer Software-Anwendung aus. Denn nichts ist gravierender und schwerwiegender als mögliche Programmausfälle oder -abbrüche, mit denen Anwender konfrontiert werden. So wird anhand bekannter ISO-Kennzahlen eine Anwendung unter anderem daran bemessen, wie viele Mängel sich aufgrund von Programmierfehlern nachträglich eingeschlichen haben, was die Anwendung insgesamt instabiler macht. Daher werden in diesem Fall Kriterien wie Softwarecrashes, Softwareausfälle und Softwarefehler betrachtet, die einen direkten Einfluss auf Anwender haben.

Sicherheit: Die schlechte Programmierung und eine unzureichende Anwendung der zugrunde liegenden Software-Architektur sind maßgeblich für mögliche Sicherheitsverletzungen verantwortlich. Das Ergebnis der Software-Analyse dieses Kriteriums stellt eine Risikoabschätzung dar, mit welchem Aufwand sich unternehmenskritische Software-Schwachstellen identifizieren und beheben lassen.

Transferierbarkeit: Software lässt sich vor allem dann mit einem angemessenen Aufwand kontinuierlich verbessern, wenn sich der zugehörige Quellcode möglichst gut verwalten lässt. Damit lässt sich der Aufwand recht gut einschätzen, der notwendig ist, um die betreffenden Stellen im Quellcode zu identifizieren und zu eliminieren. Das sorgt gleichzeitig für einen geringen Unabhängigkeitsgrad von einzelnen Software-Entwicklern, die an der Programmierung der Anwendung beteiligt waren.

Änderbarkeit: Wie viel Aufwand ist nötig, um den Quellcode einer Anwendung gemäß der erforderlichen oder gewünschten Anforderungen seitens der Anwender/Kunden anzupassen? Anhand des Kriteriums „Anpassungsfähigkeit“ wird genau diese Frage beantwortet.

Organisationen wie CISQ und ISO geben die Qualitätstandards vor

Doch auf welchen Qualitätskriterien beruhen die genannten Analysemethoden, die von Vereinigungen und Organisationen wie dem Software Engineering Institute (SEI), der International Standards Organizations (ISO), dem Consortium for IT Software Quality (CISQ) und IEEE (International Electrical und Electronics Engineers) entwickelt und verabschiedet wurden und werden?

Organisationen wie CISQ und OMG sorgen für fehlerfreie Anwendungssoftware

Nun, um diese Frage zu beantworten, reicht ein Besuch der CISQ-Webseite, auf der unter anderem all die 86 Software-Schwachstellen aufgeführt werden, anhand derer die Leistung, Zuverlässigkeit, Sicherheit, Leistungseffizienz und Administration einer Software bewertet werden können. Dazu gehören ganz triviale Fehler wie Buffer Overflow genauso wie die Umwandlung in einen kompatiblen Datentyp. Schön an dieser Liste sind die zahlreichen Lösungsvorschläge, die für jede einzelne Software-Schwachstelle angeboten werden.

Automatisierte Function Point-Methode zur quantitativen Beurteilung von Sourcecode

Neben den qualitativen Softwarekriterien, die sich mithilfe der CISQ-Standards überprüfen lassen, kommt auch der quantitativen Bewertung einer Anwendung eine immer größere Rolle zu. So ließen sich bis Mitte 2000 keine automatisierten Aussagen über den Umfang eines Sourcecodes treffen. Diesen Misstand behob die im Jahr 2014 verabschiedete Spezifikation „Automated Function Points“, die ein gemeinsames Projekt der Object Management Group (OMG) und CISQ darstellt. Hierbei werden anhand der ISO-Norm 20926 zahlreiche Regeln zurate gezogen.

So stehen zur quantitativen Bewertung einer Anwendung insgesamt fünf Elementarprozesse zur Verfügung, die einzeln bewertet werden. Das sind laut Spezifikation IFPUG-CPM 4.3.1 Eingaben (External Input, EI), Ausgaben (External Output, EO), Abfragen (External Inquiry, EQ), interne Datenbestände (Internal Logical File, ILF) und Referenzdaten (External Interface File, EIF).

Disclaimer: Dieser Blogbeitrag ist im Auftrag der Firma CAST entstanden, die mir bei der Ausgestaltung und Formulierung nahezu freie Hand lässt.

CRASH-Report - Beitragsbild

CRASH-Report: So sicher bzw. unsicher sind .NET- und Java-Applikationen

CWE. Drei Buchstaben, die für „Common Weakness Enumeration“ stehen und die etwas über die Schwachstellen einer Software-Applikation aussagen. Erstellt hat die zugehörige Liste eine Gruppe von Leuten, die sich seit vielen Jahren mit dem Thema beschäftigen. Diese Community nennt sich MITRE, hinter der sich ein Zusammenschluss namhafter Firmen wie Apple, Hewlett Packard Enterprise, IBM und auch CAST verbirgt.

Letztere hat im eigenen Forschungslabor einen globalen Benchmark erstellt, der sich CRASH-Report nennt. CRASH steht für CAST Research on Application Software Health und repräsentiert eine umfangreiche Liste von individuellen Spezialanwendungen sowie hochangepassten SAP-Installationen, die auf mögliche Schwachstellen und deren Korrelationen untersucht wurden. Diese Benchmark-Testreihe enthält zahlreiche interessante Ergebnisse und Erkenntnisse, die Anbieter von unternehmenskritischen Applikationen und ihre Software-Entwickler kennen sollten.

Download-Tipp: Hier gibt es den aktuellen CRASH-Report gegen Registrierung for free.

1.388 Apps, 278 Mio. Zeilen Code und zwei Entwicklungsumgebungen

Der CRASH-Report hat insgesamt 1.388 unterschiedlichste Anwendungen untersucht, die insgesamt 278 Millionen Code-Zeilen aufweisen. Gemein ist diesen Applikationen zweierlei: Sie wurden in Java EE (Enterprise Edition) oder Microsoft .NET programmiert, und von den 1.388 Software-Anwendungen wiesen bis auf wenige Ausnahmen sämtliche Applikationen mehr oder weniger schwerwiegende Programmierfehler auf.

CRASH-Report - Erhebungsdaten

Allerdings, und das ist die erste Erkenntnis des CRASH-Reports, konnte keine direkte Verbindung zwischen der Größe der Anwendung (gemessen an den Codezeilen) und der Fehlerwahrscheinlichkeit innerhalb des Programmcodes festgestellt werden. Ausnahmen stellen hierbei kleinere Anwendungen dar, die mithilfe von .NET entwickelt wurden. Aber, und auch das zeigt der CWE-Benchmark, ist die Streuung möglicher Fehler bei .NET-Anwendungen deutlich höher als bei getesteten Java-Programmen.

Bestimmte Applikationstypen sind sicherer als andere

Eine weitere interessante Erkenntnis bezüglich der möglichen Programmierfehler innerhalb einer Anwendung betrifft die Applikationstypen, die sich anhand der zugehörigen Branche unterscheiden lassen. So zeigt der CRASH-Report, dass Software-Programme aus den Bereichen Finanzdienstleistungen, Telekommunikation und IT-Consulting deutlich fehleranfälliger sind als Anwendungen, die bei Energieversorgern und öffentlichen Versorgungsunternehmen zum Einsatz kommen. Im Vergleich dieser beiden Bereiche ist die Wahrscheinlichkeit eines fehlerbehafteten Codes fast doppelt so hoch.

Auch hier zeigt sich eine enorme Schwäche vieler .NET-Applikationen, die verglichen mit ähnlichen Java-Anwendungen deutlich unsicherer sind. Das betrifft vor allem die Bereiche Energieversorgung, Versicherungswesen, IT-Consulting und Produktionsgewerbe. Hier konnte ebenfalls eine doppelt so hohe Wahrscheinlichkeit für einen schadhaften Code festgestellt werden.

Software-Entwicklungsmethoden beeinflussen die Programmqualität

Ein weiteres aufschlussreiches Ergebnis betrifft die Art und Weise, welche Entwicklungsmethoden bei der Erstellung von Applikationen zum Einsatz kommen. So zeigt der CRASH-Report, dass vor allem .NET-Anwendungen ein enormes Fehlerpotential aufweisen, die mithilfe des Wasserfallmodells entwickelt wurden. Der Bericht geht sogar so weit, dass angenommen werden kann, dass diese .NET-Applikationen besonders anfällig für Cyber-Attacken und Exploits sind.

Java: Je höher die Update-Zyklen, desto fehleranfälliger die Anwendung

Schließlich sei noch auf den Zusammenhang zwischen Fehleranfälligkeit einer Anwendung und deren Update-Zyklen hingewiesen. So stellen vor allem Java-Applikationen eine hohe Gefahrenquelle für das einsetzende Unternehmen dar, die mehr als sechs Mal pro Jahr ein Update erfahren. Dies ist vor allem für Anbieter von Software eine interessante Erkenntnis, bei denen agile Software-Entwicklungsmethoden eingesetzt werden. Dazu gehört auch der gerade aufstrebende Bereich der DevOps-Entwicklung.

CRASH-Report - Update-Zyklen

Zu guter Letzt gibt es noch zwei gute Nachrichten: Bei aller Fehleranfälligkeit, vor allem von .NET-Anwendungen, hat die Wahrscheinlichkeit eines schadhaften Codes laut CRASH-Report weder etwas damit zu tun, ob die Applikation intern oder extern entwickelt wurde, noch wo dies geschieht, also unter regionalen Aspekten.

CRASH-Report - Übersicht

Disclaimer: Dieser Blogbeitrag ist im Auftrag der Firma CAST entstanden, die mir bei der Ausgestaltung und Formulierung freie Hand lässt.