S.E.I. Code Audit Leistungen

Einleitung

Grundsätzlich unterscheidet man zwischen White-Box-Audit und Black-Box-Audit. Ersteres bietet Einsicht in den Quellcode, letzteres auditiert die Applikation ohne Einsicht. Weiterhin kann man Software grundsätzlich zur Design-Time auditieren – also als Quellcode und auch zur Run-Time – also als laufendes Programm.

Beispielhafte Leistungen & Leistungscluster (Daten Gruppen)

Nachfolgend einige Beispiele für ein White-Box-Audit zur Design-Time (Code Review):

Wie wird entwickelt?

• Wird zeitgemäß entwickelt?
• Wird ein Version Control System bzw.
  ein Source Code Repository eingesetzt?       
• Wird in Branches bspw. nach gitflow entwickelt?
• Wie werden externe Libraries eingebunden? Wie werden deren Versionen sichergestellt bzw. was passiert bei einem Update?
• Gibt es bspw. Continuous Integration?

Code Qualität, Sicherheit & Stil

Code Qualität ist eine Frage des Anspruchs, der Erfahrung und der Programmiersprache bzw. des Einsatzgebietes. Je nach konkreter Sachlage sollte eine Reihe von Fragen  gestellt werden, viele davon sind eher wahrscheinlicher oder unwahrscheinlicher positiv zu beantworten.

Beispiele:

• Wird bei der Übergabe von Werten an Funktionen der Datentyp überprüft, bzw. ein expliziter Datentyp erwartet?
• Ist robust programmiert worden, bspw. sind I/O Operationen in try/catch Blöcken gekapselt?
• Werden alle Eingaben vom Nutzer escaped, bzw. Cross-Site-Scripting o.ä. ausgeschlossen?
• Je nach Sprache ist auf Speichermanagement zu achten. Werden reservierte Speicherblöcke wieder freigegeben? Werden Datenbankverbindungen wieder geschlossen?
• Error Handling: Ein Error Handler muss seinen Status aufräumen und ggf. Speicher wieder freigeben, egal wo der Fehler passiert. Zum Error-Handling sind eine Reihe von Fragen
  zu stellen.
• Thread Safety: So anzuwenden ist das Laufen im Multi-Threading sicher zu gewährleisten, bspw. in dem globale (statische) Variablen durch Locks geschützt werden.
• Gibt es Coding Guidelines und sind diese eingehalten worden?
• Wie hoch ist der Grad der Kapselung (generisch vs. spezifisch oder auch Grad der Normalisierung)?

Dokumentation

• Wie ist die Abdeckung der Dokumentation im Code, z.B. für Klassen, Methoden, Funktionen, Interfaces usw?
• Liegt bspw. eine Klassenreferenz vor?
• Liegt ein Datenmodell vor, bspw. in UML?
• Hat jedes Modul, ggf. auch jede Klasse einen Autor, eine Version?
• Liegt ein Betriebshandbuch vor?
   

Testing

• Wie hoch ist die Test-Coverage?
• Liegen Unit-Tests vor?
• Sind Fehlerbedingungen und nicht valide Parameter in Tests definiert?
• Werden Interfaces getestet?
• Werden automatisierte Tests durchgeführt? Bspw. auch Frontend-Tests?

Performance

• Es liegen Mengengerüste vor und das System ist im Rahmen dieser Mengengerüste getestet worden.
• Die Deploymentumgebung ist definiert, bspw. werden Debug Optionen (automatisch) ausgeschaltet.
• Es gibt eine Caching Infrastruktur.
• Generell ist die Infrastruktur für den geplanten Einsatz der Applikation ausreichend ausgebaut.

Infrastruktur

Die Infrastruktur kann zur Design-Time bewertet und getestet werden. Zur Laufzeit sollte sie gegen ein definiertes Mengengerüst getestet werden. In diesem Kontext können auch Last- und Penetration-Tests sinnvoll sein. Diese können offen und verdeckt durchgeführt werden. Typische Fragen für Web-Infrastrukturen im öffentlichen Internet sind bspw.:

• Kommt eine Web-Application-Firewall zum Einsatz?
• Wie werden Änderungen auf dem System durchgeführt? Gibt es ein Backend?
• Wie ist das Backend geschützt?
• Wie werden Authentifizierung, Autorisierung und Accounting durchgeführt?
• Für welches Mengengerüst ist das System gebaut? Schafft das System diese Nutzerzahlen?
• Welche Nutzerzahlen kann das System ab?
• Welche Reserven hat das System?
• Wie werden Angriffe wahrgenommen und abgewehrt?
• Sind Fragen im Kontext Wettbewerb, Spionage und Kriminalität zu stellen? Es gibt z.B. Kunden die sich schriftlich bestätigen lassen, dass man nicht der Scientology Bewegung angehört. Sehr oft wird auch eine zukünftige Tätigkeitt für bestimmte Wettbewerber ausgeschlossen.

Betrieb

Wenn man Software programmieren lässt, kann man auch einige Fragen zu den Programmierern stellen, bspw.

• Liegt eine Liste mit Namen der Mitarbeiter vor, welche an dem Projekt gearbeitet haben?
• Fragen im Kontext Wettbewerb, Spionage

Fragen zum Betrieb rund um das Thema IT Service Management bzw. ITIL (IT Infrastructure Library). Beispiele:

• Wie werden Änderungen (Changes) am System durchgeführt?
• Gibt es Prozesse für das Incident, Problem, Change und Security Management?
• Gibt es ein Service Level Agreement? Gibt es Wartungsfenster?

Mögliche Randthemen

Über ein Code Audit hinaus können weitere Aspekte abgeklärt werden:

• Juristische Aspekte wie z.B. bei einem Shop AGB, Widerrufsbelehrung, Preisauszeichnung
  u.a.m.
• Usability Aspekte; wie der Nutzer mit der Software umgehen bzw. interagieren kann
• Existiert ein Style Guide, ist er umsetzbar bzw. zu welchem Grad wird er umgesetzt?

Voraussetzungen

Für ein Code Audit, gleich welcher Ausprägung und Programmiersprache werden Experten benötigt. S.E.I. verfügt mit seinen Partnern über einen Experten-Pool  unterschiedlichster  Software Entwicklungserfahrungen, die dem jeweiligen Kunden für AUDITS zur Verfügung gestellt werden können. 

Auftraggeber beauftragen S.E.I. mit einem Code Audit, um Risiken zu erkennen, zu minimieren und ggf. zu externalisieren. Eventuell sollen Garantien ausgesprochen werden, bzw. werden implizit Sicherheiten suggeriert, welche bei einem nachfolgenden Vorfall gegebenenfalls eingefordert werden. Diese Risiken bedürfen eines kompetenten Managements.
 

Fragen zu den einzelnen Ausführungen
beantworten wir  Ihnen gern:

Jürgen Neumann, S.E.I. Geschäftsleitung Tel. 0228-26731-61
und Peter Eulberg, S.E.I. AUDIT Experte