PHP Code Audit Kosten: Was ein professionelles Review in Deutschland kostet und was Sie dafür bekommen
Die meisten Unternehmen, die uns nach einem PHP Code Audit fragen, wissen bereits, dass ihre Anwendung Probleme hat. Was sie nicht wissen: Was kostet ein professionelles Review, steht der Preis in einem vernünftigen Verhältnis zur Größe ihres Systems, und was halten sie am Ende tatsächlich in den Händen? Dieser Beitrag beantwortet diese Fragen mit Zahlen vom deutschen Markt, denn "kommt drauf an" ist keine brauchbare Antwort, wenn Sie eine Position ins Budget für das nächste Quartal eintragen müssen.
Wir haben an anderer Stelle beschrieben, was ein Audit untersucht und wie das Review aufgebaut ist und wie Sie Ihre Codebasis vorbereiten, bevor der Auditor kommt. In diesem Beitrag geht es ums Geld: PHP Code Audit Kosten, was sie bestimmt und woran Sie erkennen, ob Sie Gegenwert bekommen haben.
Wofür Sie bezahlen
Ein Audit ist kein Durchlauf einer statischen Analyse. PHPStan auf Level 8 liefert bei jeder Anwendung, die seit sechs Jahren in Produktion läuft, ein paar tausend Befunde, und diese Liste bekommen Sie an einem Nachmittag kostenlos. Was Sie bezahlen, ist Urteilsvermögen: ein Senior Engineer, der den Code, das Schema, die Deployment-Pipeline und die Testsuite liest und Ihnen sagt, welche der tausend Befunde wichtig sind, in welcher Reihenfolge, und was die Behebung jeweils kosten wird.
Ein vollständiges Review einer PHP-Anwendung deckt sechs Bereiche ab. Architektur, also wie der Code geschichtet ist und ob die Geschäftslogik an einer Stelle liegt, die Sie testen können. Sicherheit, von den offensichtlichen Injection- und Authentifizierungsproblemen bis hin zum Umgang mit Secrets und Sessions. Performance, meist dominiert von Datenbankzugriffsmustern. Datenbankdesign, einschließlich Migrationen, Indizes und der Frage, ob das Schema noch zu dem passt, was die Anwendung tut. Testabdeckung, und wichtiger noch, ob die vorhandenen Tests eine Regression überhaupt erkennen würden. Und der Deployment-Prozess, denn eine Codebasis, die nur eine einzige Person an einem Freitagnachmittag ausrollen kann, ist ein Risiko, egal wie sauber die Klassen sind.
Jeder Bereich bekommt einen schriftlichen Befund mit Schweregrad, einer Aufwandsschätzung für die Behebung und einer Empfehlung. Der Bericht schließt mit einer priorisierten Liste, die Sie direkt in ein Backlog übernehmen können. Wenn ein Angebot, das Sie erhalten, das Ergebnis nicht ungefähr in diesen Begriffen beschreibt, fragen Sie nach, was Sie eigentlich kaufen.
PHP Code Audit Kosten nach Anwendungsgröße
Die Preise unten spiegeln wider, was unabhängige Berater und kleine Spezialstudios in Deutschland für Arbeit auf Senior-Niveau verlangen, im Bereich von 120 bis 200 EUR pro Stunde. Große Beratungshäuser verlangen mehr und besetzen die Arbeit typischerweise mit weniger erfahrenen Leuten. Offshore-Anbieter verlangen weniger, und die Qualität schwankt stärker als der Preis.
Eine kleine Anwendung mit bis zu etwa 30.000 Zeilen PHP, einer einzelnen Datenbank und ohne separate Services braucht drei bis fünf Arbeitstage. Rechnen Sie mit 4.000 bis 8.000 EUR. In dieser Größe kann der Auditor den Großteil des Codes tatsächlich lesen, statt Stichproben zu nehmen, und der Bericht fällt meist sehr konkret aus.
Eine mittelgroße Anwendung zwischen 30.000 und 150.000 Zeilen, mit einer Handvoll Integrationen, einer Queue und vielleicht einem Legacy-Modul, das niemand anfasst, braucht sechs bis zwölf Tage. Planen Sie 8.000 bis 20.000 EUR ein. Hier landen die meisten Symfony- und Laravel-Systeme, die seit vier bis acht Jahren in Produktion sind, und es ist die Kategorie, in der ein Audit am häufigsten eine Entscheidung verändert, weil das Team das System meist nicht mehr als Ganzes überblickt.
Eine große Anwendung mit mehr als 150.000 Zeilen, oder alles mit mehreren Services, mehreren Datenbanken oder einer gemischten PHP-5- und PHP-8-Codebasis, dauert zwei bis fünf Wochen. 20.000 bis 45.000 EUR sind realistisch, und jenseits davon sollte der Auftrag in Phasen geschnitten werden, statt als ein Block gekauft zu werden.
Drei Dinge treiben den Preis innerhalb einer Kategorie nach oben. Keine Testsuite, weil der Auditor das Verhalten durch Lesen statt durch Ausführen herausfinden muss. Keine Dokumentation und niemand mehr im Team, der den ursprünglichen Code geschrieben hat, was die halbe Arbeit zur Archäologie macht. Und eine Compliance- oder Übernahmefrist, die den Zeitplan verdichtet und meist einen zweiten Reviewer erfordert.
Zwei Dinge drücken ihn nach unten. Guter Zugang ab Tag eins (Repositories, eine Staging-Umgebung, die der Produktion ähnelt, Datenbankdumps ohne personenbezogene Daten) und eine klare Frage. "Ist diese Codebasis eine sichere Grundlage für die nächsten drei Jahre?" ist eine abgegrenzte Frage. "Sagen Sie uns alles, was falsch ist" ist es nicht, und wird entsprechend bepreist.
Festpreis oder Time and Materials
Bei einem Audit bevorzugen wir einen Festpreis nach einem kurzen Scoping-Gespräch, und wir finden, Sie sollten darauf bestehen. Anders als bei einem Refactoring-Auftrag, bei dem niemand ehrlich sechs Monate Arbeit abschätzen kann, bevor der Code analysiert wurde, hat ein Audit einen begrenzten Input. Der Auditor kann sich in einer Stunde Repository-Größe, Anzahl der Abhängigkeiten und das Schema ansehen und eine Zahl nennen, die auf 15 Prozent genau stimmt.
Ein Anbieter, der sich weigert, den Preis für ein Audit festzulegen, sagt Ihnen entweder, dass er sich Ihr System noch nicht angesehen hat, oder dass er den Auftrag wachsen lassen will. Beides sind Gründe, weiterzusuchen.
Was ein Festpreis enthalten sollte: das Discovery-Interview, die automatisierte Analyse, das manuelle Review, den schriftlichen Bericht und eine Präsentation der Ergebnisse vor den Entscheidern auf Ihrer Seite. Was er nicht enthalten sollte: irgendetwas zu reparieren. Halten Sie Audit und Behebung getrennt, auch wenn am Ende dieselbe Firma beides macht. Ein Auditor, der gleichzeitig auf die Folgearbeit bietet, hat einen Grund, mehr Probleme zu finden, als es gibt.
Was der Bericht enthalten muss
Wir haben Audit-Berichte anderer Anbieter gelesen, die unsere Kunden erhalten haben, bevor sie zu uns kamen. Die schlechten haben ein gemeinsames Muster: Sie sind lang, bestehen überwiegend aus Tool-Output, und die Empfehlungen sind so allgemein, dass sie auf jede PHP-Anwendung der Welt passen. "Testabdeckung verbessern." "Veraltete Abhängigkeiten aktualisieren." "Eine geschichtete Architektur in Betracht ziehen." Dafür mussten Sie keine 12.000 EUR bezahlen.
Ein Bericht, der sein Geld wert ist, hat vier Eigenschaften.
Jeder Befund nennt einen Ort. Eine Datei, eine Klasse, eine Query, einen Konfigurationswert. Wenn ein Befund sagt "mehrere Controller enthalten Geschäftslogik", sollte er sie auflisten und sagen, mit welchem man anfangen soll.
Jeder Befund hat einen Kostenrahmen. Keine präzise Schätzung, aber eine Größenordnung: Stunden, Tage oder Wochen. Ohne das können Sie nicht priorisieren, und Priorisierung ist der ganze Sinn der Übung.
Die Befunde sind gegen Ihr Risiko gewichtet, nicht gegen ein Lehrbuch. Ein fehlender Index auf einer Tabelle mit 400 Zeilen ist kein Befund. Ein fehlender Index auf der Tabelle, die Ihr Rechnungslauf jede Nacht durchsucht, schon. Der Auditor muss verstanden haben, wofür die Anwendung da ist.
Und der Bericht beantwortet die Frage, die Sie tatsächlich gestellt haben. Wenn Sie das Audit in Auftrag gegeben haben, um zwischen Refactoring und Neubau zu entscheiden, sollte auf der letzten Seite stehen, welches von beiden, mit Begründung. Wir haben wie man diese Entscheidung trifft ausführlich beschrieben, und ein gutes Audit ist der Input für dieses Framework.
Aus den Befunden eine Roadmap machen
Der Bericht ist nur nützlich, wenn danach etwas passiert, und unserer Erfahrung nach wird genau hier das Geld am häufigsten verschwendet. Das PDF geht herum, alle sind sich einig, dass es gründlich ist, und sechs Monate später hat sich nichts geändert, weil die Befunde nie ins Backlog gekommen sind.
Die Lösung ist mechanisch. Nehmen Sie die priorisierte Liste und machen Sie aus jedem Punkt ein Ticket, in das Befund, Ort und Aufwandsschätzung hineinkopiert werden. Gruppieren Sie die Tickets in drei Ströme. Der erste ist alles, was der Bericht als Sicherheits- oder Datenintegritätsrisiko markiert hat; das geht vor Feature-Arbeit, egal was die Roadmap sagt. Der zweite ist die strukturelle Arbeit, die den Rest freischaltet: meist einen Test-Harness um das riskanteste Modul legen und den Deployment-Prozess festzurren. Der dritte ist der lange Schwanz, der neben Features mit einem festen Kapazitätsanteil eingeplant wird (15 bis 20 Prozent sind üblich), der nie auf null fällt.
Wenn das Audit ein Refactoring-Programm empfohlen hat, ist der Bericht zugleich Ihr Scope-Dokument für das nächste Angebot. Wir haben beschrieben, was Refactoring-Dienstleistungen kosten und wie man einen Partner bewertet; der Punkt hier ist, dass ein sauber durchgeführtes Audit das nächste Angebot deutlich genauer macht, weil derjenige, der darauf bietet, nicht mehr raten muss.
Wann sich ein Audit lohnt und wann nicht
Ein Audit zahlt sich in vier Situationen aus. Vor einer Übernahme oder Finanzierungsrunde, wenn ohnehin ein Dritter auf den Code schauen wird und Sie es vorher wissen wollen. Wenn ein Team ein System geerbt hat, das niemand im Haus geschrieben hat. Wenn dieselbe Art von Produktionsvorfall immer wieder auftritt und das Team nicht erklären kann, warum. Und bevor ein Budget für ein Modernisierungsprogramm freigegeben wird, denn ein Audit für 15.000 EUR ist eine günstige Versicherung für einen Neubau für 200.000 EUR.
Es lohnt sich nicht, wenn Sie bereits wissen, was falsch ist, und nur die Kapazität fehlt, es zu beheben. Wenn Ihr Lead Developer die zehn schlimmsten Probleme der Codebasis aus dem Kopf aufzählen kann, mit Fundstellen, brauchen Sie niemanden, der sie für 150 EUR die Stunde aufschreibt. Stecken Sie das Geld in die Behebung. Es lohnt sich auch nicht für eine Anwendung, die innerhalb eines Jahres abgeschaltet wird, es sei denn, eine Aufsichtsbehörde oder ein Käufer verlangt es.
Der Fragebogen, den wir vor jedem Audit verschicken
Bevor wir ein Angebot machen, schicken wir dem Kunden eine kurze Liste von Fragen. Die Antworten bestimmen die Preiskategorie und, wichtiger noch, den Zuschnitt des Auftrags. Wir teilen sie hier, weil sie zugleich ein guter Selbsttest dafür ist, ob Sie bereit sind, ein Audit zu beauftragen.
Wofür ist die Anwendung da, wer nutzt sie, und was passiert mit dem Geschäft, wenn sie einen Tag ausfällt? Wie viele Zeilen PHP, welches Framework in welcher Version, und welche PHP-Version läuft in Produktion? Wie viele Datenbanken, externe Integrationen und Hintergrundprozesse sind beteiligt? Gibt es eine Testsuite, und läuft sie in CI bei jeder Änderung? Wie wird die Anwendung deployt, und wie viele Personen können das? Wer hat den ursprünglichen Code geschrieben, und sind diese Personen noch für Fragen erreichbar? Welche Entscheidung wollen Sie mit den Ergebnissen treffen? Und gibt es eine Frist, die von außerhalb der Technik getrieben wird, etwa eine Finanzierungsrunde, eine Übernahme oder eine Compliance-Anforderung?
Wenn Sie alle acht an einem Nachmittag beantworten können, sind Sie bereit. Wenn Ihnen bei der Hälfte auffällt, dass niemand im Team es weiß, ist das selbst schon ein Befund, und das stärkste Argument dafür, das Audit zu machen.
Zusammenarbeit mit Wolf-Tech
Wir führen PHP- und Symfony-Audits für Unternehmen in Deutschland und dem übrigen Europa durch, meist vor einem Modernisierungsprogramm, einer Finanzierungsrunde oder einem Verkauf. Der Auftrag läuft zum Festpreis, der Bericht nennt für jeden Befund Ort und Aufwand, und wir halten das Audit von jeder Behebungsarbeit getrennt, damit die Befunde ehrlich bleiben. Code Quality Consulting ist der Einstieg dafür. Wenn Sie ein Angebot möchten, schicken Sie die Antworten auf den Fragebogen oben an hello@wolf-tech.io oder schauen Sie auf wolf-tech.io vorbei, und wir sagen Ihnen, was das Review kosten würde und ob Sie überhaupt eines brauchen.