Überlegen Sie einmal, welches Ziel ein Ingenieur bei der Verwendung eines statischen Analysetools wie CodeSonar anstrebt. Die folgende Abbildung skizziert den Prozess:

Als Minimum liefert das Tool eine Liste mit Warnmeldungen, die vom Ingenieur in der Regel durchgesehen wird. Leider besteht dabei jedoch immer die Möglichkeit, dass das Tool eine Warnung ausgegeben hat, obwohl es gar keinen Grund dafür gibt. Die erste Aufgabe des Ingenieurs ist es also, die Warnungen in wahr positive Warnungen vor einem wirklichen Problem und falsch positive Warnungen vor einem in Wirklichkeit nicht existenten Problem einzuteilen. Danach kann man darangehen, die wirklichen Probleme durch Reparieren des Codes zu beseitigen.

Wie kann man die Qualität eines statischen Analysetools beurteilen? Aussagefähig ist in diesem Fall die Qualität der vom Tool produzierten Liste. Wie genau ist sie? Wie hoch ist die Rücklaufquote? Von wesentlich größerer Bedeutung ist jedoch die vom Ingenieur gefilterte Liste der gemeldeten Probleme. Wenn das Tool ein reales Problem meldet, dieses aber vom Ingenieur verworfen wird, haben wir in unserem Streben nach Verbesserung der Sicherheit und Zuverlässigkeit der Software keinen Fortschritt erzielt. Was nützt es, wenn das Tool von einem Problem Kenntnis hat, aber dieses Wissen an keine Person weitergibt, die Abhilfe schaffen kann?

Diese Perspektive ist der Beweggrund für viele Features und Designalternativen von CodeSonar. CodeSonar produziert weit mehr als nur eine Liste potenzieller Gefahrenstellen im Code. Ziel ist es stets, den Ingenieur möglichst effektiv arbeiten zu lassen. Für viele Warnungen zeigt CodeSonar einen Pfad durch den Code auf, der das Problem demonstriert, und versieht diesen Pfad mit Bedingungen, die erfüllt sein müssen, damit das Problem auftritt. Es wird sogar natürliche Sprache generiert, um die Bedingungen und wichtige Punkte entlang des exemplarischen Pfads zu erläutern.

Zusätzlich wartet CodeSonar mit fortschrittlichen Code-Navigations- und Visualisierungs-Features auf. Diese helfen dem Anwender beim Verstehen des Kontexts, in dem ein Fehler auftritt. Dies kann wichtig für das Ausarbeiten einer Reparaturlösung sein.

Kurz gesagt, können statische Analysetools mehr als nur eine Liste mit Problemen erstellen. Stattdessen soll CodeSonar den Ingenieuren bei der Entwicklung von Software helfen, die besser und sicherer ist.

Diese Zielsetzung hat ein weit größeres Ausmaß als die simple Defekterkennung. Sie motiviert GrammaTechs Umwechseln von der Forschung in die Entwicklung. Anders als bei anderen Anbietern von Softwaretools ist das kommerzielle Geschäft bei GrammaTech mit einem Forschungszweig verknüpft, in dem unter anderem mehr als 20 promovierte Mitarbeiter daran arbeiten, Techniken und Technologien im Bereich der Softwareanalyse, der Transformation, der Überwachung und der autonomen Funktionen voranzubringen.

Viele der von CodeSonar gebotenen Funktionen begannen als Forschungsprojekte in der Forschungsabteilung von GrammaTech. Zum Beispiel beruhen die Visualisierungs-Features von CodeSonar auf Forschungsarbeiten für die US-Armee zur Visualisierung von 20.000 Codezeilen aus 20.000 Fuß, auf Forschungsarbeiten für die US-Marine zur Untersuchung fein abgestufter Semantiken aus der Froschperspektive sowie Forschungen für einen Kunden, der sich eine neue Möglichkeit wünschte, die Möglichkeiten zur Ausnutzung einer Schwachstelle zu ermitteln.

Derzeit laufen GrammaTechs Forschungsarbeiten zur automatisierten Codeerzeugung und -reparatur auf ein potenzielles Feature von CodeSonar hin, das Reparaturen für erkannte Defekte vorschlagen könnte. Compiler leisten dies bereits bei einigen trivialen Problemen (z. B. fehlenden Semikolons). Bei GrammaTech ist man aber der Auffassung, dass fortschrittliche Analysetechniken auch für subtile, schädliche Fehler automatisch Reparaturmöglichkeiten aufzeigen können.

Forschungsprojekte dieser Art helfen CodeSonar, den umfangreicheren Softwareabsicherungs- und Security-Missionen gerecht zu werden. Neue Releases dieses Produkts sowie die fortlaufenden Verbesserungen und Bugfixes sind alle darauf fokussiert, unsere Forschungsarbeit dem Embedded-Entwickler zugutekommen zu lassen und ihm beim Entdecken, Verstehen und Reparieren von Softwaredefekten zu helfen.