Code-Audit für Symfony-Projekte: Was ein Audit-Bericht enthalten muss, bevor Sie übernehmen, investieren oder modernisieren

Inhalt

1. Ausgangslage: Wofür Sie den Bericht brauchen
2. Drei Arten von Audits im Vergleich
3. Was ein Audit-Bericht für Symfony-Projekte enthalten muss
4. Woran Sie einen brauchbaren Bericht erkennen
5. Bevor Sie unterschreiben

Am 04.11.2026 hat Symfony mehrere Sicherheitskorrekturen veröffentlicht, darunter für CVE-2026-118514 und CVE-2026-118516. In vielen Projekten schlägt composer audit seitdem an. Ein öffentlicher Pull Request vom 08.11.2026 bringt die Folge auf den Punkt: Das Audit in der CI scheitert auf jedem Branch. Für ein gepflegtes Projekt ist das ein Arbeitsauftrag für den nächsten Tag. Für ein Projekt, das gerade gekauft, übernommen oder mit Budget versehen werden soll, ist es eine Frage, die vor der Unterschrift beantwortet sein muss: Wie viele solcher Baustellen liegen noch im Code, und was kostet es, sie zu schließen?

Genau hier scheitern viele Übernahmen und Investitionen. Nicht am Code selbst, sondern daran, dass die Entscheidung ohne belastbares Bild von seinem Zustand getroffen wurde. Die Überraschungen kommen dann im ersten halben Jahr, wenn das Budget bereits verplant ist. Ein Code-Audit soll das verhindern. Das gelingt aber nur, wenn der Bericht die richtigen Fragen beantwortet. Dieser Artikel zeigt, was in einen Audit-Bericht für Symfony-Projekte gehört und woran Sie einen Bericht erkennen, der Ihnen bei der Entscheidung tatsächlich hilft.

Ausgangslage: Wofür Sie den Bericht brauchen

Ein Code-Audit ist kein Selbstzweck. Es steht fast immer vor einer von drei Entscheidungen. Bei einer Übernahme wollen Sie wissen, ob ein neuer Dienstleister das Projekt sicher weiterführen kann. Bei einer Investition oder einem Kauf wollen Käufer oder Investor wissen, welche technischen Risiken im Preis stecken. Bei einer Modernisierung will die Geschäftsführung wissen, ob sich das System schrittweise verbessern lässt oder ob ein größerer Umbau ansteht.

Im Umfeld von Unternehmenskäufen heißt diese Prüfung Technical Due Diligence: eine technische Sorgfaltsprüfung vor einer Geschäftsentscheidung. Der Code-Audit ist meist ihr Kern. Der Unterschied zu einer Selbsteinschätzung ist wichtig. Der Risiko-Check vor der Projektübernahme hilft Ihnen, selbst einzuschätzen, worauf Sie achten sollten. Ein Audit ist dagegen ein eigenständiges Ergebnis, das ein Dritter erstellt und das Sie an Dritte weitergeben können: an die Geschäftsführung, an einen Käufer, an den nächsten Dienstleister.

Drei Arten von Audits im Vergleich

Automatisierter Scan

Werkzeuge prüfen Abhängigkeiten, Codestil und statische Analyse und erzeugen einen Bericht. Das geht schnell und liefert harte Messpunkte. Was fehlt, ist die Einordnung. Ein Scan sagt Ihnen, dass es eine bestimmte Zahl an Befunden gibt. Er sagt nicht, welche davon den Betrieb gefährden und welche kosmetisch sind. Für eine Investitionsentscheidung reicht das selten.

Manuelles Kurz-Audit

Ein erfahrener Entwickler sieht sich das Projekt gezielt an, nutzt dieselben Werkzeuge und ordnet die Ergebnisse ein. Der Bericht konzentriert sich auf die größten Risiken und die wichtigsten Aufwandstreiber. Für viele Übernahmen und Modernisierungsentscheidungen ist das die wirtschaftlich passende Tiefe. Die Grenze: Einzelne Bereiche werden nur stichprobenartig geprüft. Ein guter Bericht sagt offen, welche.

Vollständiges Audit für Dritte

Alle Bereiche werden systematisch geprüft, inklusive Build, Deployment und Lizenzlage. Der Bericht ist so geschrieben, dass er an Käufer, Investoren oder Gremien weitergegeben werden kann, auf Wunsch ohne Codeauszüge, falls der Code unter NDA steht. Das ist die richtige Tiefe, wenn viel Geld an der Entscheidung hängt oder Dritte sich auf den Bericht verlassen sollen.

Die falsche Wahl kostet in beide Richtungen. Ein reiner Scan vor einem Kauf wiegt Sie in falscher Sicherheit, weil die wirklich teuren Probleme selten in einer Werkzeugausgabe stehen. Ein vollständiges Audit vor einer kleinen internen Modernisierung bindet Budget, das in der Umsetzung fehlt.

Was ein Audit-Bericht für Symfony-Projekte enthalten muss

Abhängigkeitslage

Der härteste Messpunkt eines Audits. composer audit zeigt bekannte Sicherheitslücken in den installierten Paketen, die aktuellen Symfony-Advisories vom 04.11.2026 sind ein gutes Beispiel. Dazu gehört die Frage, wie alt die Abhängigkeiten insgesamt sind. Eine verbreitete Kennzahl dafür ist libyear: die Summe der Zeit, die jede Abhängigkeit hinter ihrer aktuellen Version liegt. Der Bericht sollte beides nennen und einordnen, welche Pakete sich mit wenig Aufwand aktualisieren lassen und welche einen größeren Versionssprung erfordern.

# Bekannte Sicherheitslücken in den installierten Paketen
composer audit

# Veraltete direkte Abhängigkeiten, getrennt nach Patch-, Minor- und Major-Rückstand
composer outdated --direct

Die zweite Ausgabe ist für Entscheider die wichtigere. Patch- und Minor-Rückstände sind Routine. Major-Rückstände sind Projekte mit eigenem Budget.

Support-Status

Der Bericht muss sagen, wie lange die eingesetzten Versionen noch Sicherheitsupdates bekommen. Die nächsten Fristen liegen dicht beieinander: Der Bugfix-Support für Symfony 6.4 endet im November 2026, der Security-Support für PHP 8.2 am 31.12.2026, Symfony 8.1 erreicht im Januar 2027 sein Supportende. Ein Projekt auf einer dieser Versionen hat einen festen Termin für den nächsten Versionswechsel. Welche Frist für Ihr Projekt tatsächlich zählt, beschreibt der Artikel zu PHP 8.2 End of Life und Symfony 6.4.

Statische Analyse

Mit welchem PHPStan-Level läuft das Projekt, und wie groß ist die Baseline, also die Liste bekannter Befunde, die bewusst ignoriert werden? Ein hohes Level mit riesiger Baseline sagt mehr über ein Projekt als ein niedriges Level ohne Baseline. Warum diese Kennzahlen auch bei der Partnerwahl zählen, steht im Artikel Symfony-Partner auswählen.

Testabdeckung und Testarten

Eine Prozentzahl allein reicht nicht. Der Bericht sollte sagen, welche Bereiche durch Tests abgesichert sind und welche Art von Tests es gibt: Unit-Tests für Logik, Integrationstests für Datenbank und Schnittstellen, funktionale Tests für die wichtigsten Abläufe. Entscheidend ist, ob die geschäftskritischen Wege geschützt sind, etwa Checkout, Rechnungserstellung oder Datenimporte.

Architektur und Kopplung

Wie stark hängen die Teile des Systems voneinander ab? Lässt sich ein Bereich ändern, ohne andere zu berühren? Diese Frage entscheidet darüber, ob eine schrittweise Modernisierung möglich ist oder ob jede Änderung das ganze System betrifft. Wenn ein Projekt sich in fachliche Einheiten schneiden lässt, ist eine Ablösung im laufenden Betrieb realistisch. Wie das aussieht, beschreibt der Artikel zum Strangler-Fig-Muster mit Symfony.

Build und Deployment

Lässt sich das Projekt aus dem Repository heraus reproduzierbar bauen und ausliefern? Oder hängt das Deployment an einem Rechner, einem Skript außerhalb der Versionskontrolle oder dem Wissen einer einzelnen Person? Dieser Punkt wird oft übersehen und ist bei Übernahmen einer der häufigsten Gründe für Verzögerungen. Ohne lesenden Zugriff auf Server und Pipeline kann ein Audit ihn nicht beurteilen. Der Bericht muss das dann offen sagen.

Dokumentationsstand

Gibt es eine Beschreibung der Architektur, der Schnittstellen und der Betriebsabläufe? Ist sie aktuell? Dokumentation entscheidet darüber, wie schnell ein neues Team produktiv wird und wie abhängig das Projekt von einzelnen Personen ist.

Lizenzlage Open Source

Welche Lizenzen haben die eingesetzten Pakete, und passen sie zum Geschäftsmodell? Die composer.lock ist die Grundlage dafür, eine Software Bill of Materials (SBOM) macht sie maschinenlesbar. Für Käufer und Investoren ist dieser Punkt oft wichtiger als für das Entwicklerteam. Wer Plugins oder Bundles an Dritte ausliefert, braucht die SBOM ohnehin, wie der Artikel zur CRA-Meldepflicht zeigt. Eine rechtliche Bewertung der Lizenzen ersetzt der Bericht nicht.

Woran Sie einen brauchbaren Bericht erkennen

Viele Audit-Berichte scheitern nicht an der Prüfung, sondern an der Darstellung. Eine lange Liste von Befunden ohne Gewichtung lässt den Leser genau dort allein, wo er Hilfe braucht. Ein brauchbarer Bericht beantwortet für Entscheider drei Fragen.

Welche Risiken bestehen? Gemeint sind Risiken für Betrieb, Sicherheit und Weiterentwicklung, nach Dringlichkeit sortiert. Ein ungepatchtes Sicherheitsproblem in einer öffentlich erreichbaren Komponente gehört nach oben, uneinheitlicher Codestil nach unten.

Was treibt den Aufwand? Der Bericht sollte benennen, welche Befunde viel Arbeit bedeuten und welche wenig. Ein Major-Upgrade mit Auswirkungen auf das ganze Projekt ist etwas anderes als ein Dutzend Patch-Updates. Wie sich solche Befunde gegenüber der Geschäftsführung in Budget übersetzen lassen, beschreibt der Artikel Technische Schulden quantifizieren.

In welcher Reihenfolge sollte vorgegangen werden? Ein guter Bericht endet mit einer Empfehlung, was zuerst passieren muss und was warten kann. Erst Sicherheitslücken und Supportenden, dann Build und Dokumentation, dann Architektur.

Ebenso wichtig ist, was ein Bericht nicht leisten kann. Er bewertet den Zustand zu einem Zeitpunkt. Er ersetzt keinen Penetrationstest, keine rechtliche Prüfung und keine Aufwandsschätzung für ein konkretes Umsetzungsprojekt. Ein seriöser Bericht nennt diese Grenzen und benennt Bereiche, die nur stichprobenartig oder gar nicht geprüft wurden. Fehlt dieser Abschnitt, ist Vorsicht angebracht.

Bevor Sie unterschreiben

Wer ein Symfony-Projekt übernimmt, kauft oder modernisieren will, sollte vor der Entscheidung wissen, worauf er sich einlässt. Legen Sie vor der Beauftragung fest, welche Entscheidung der Bericht tragen soll, wer ihn lesen wird und welche Zugänge der Prüfer bekommt. Steht der Code unter NDA, klären Sie den Ablauf vorab, wie im Artikel zur Projektübernahme mit NDA beschrieben. Achten Sie im fertigen Bericht weniger auf die Zahl der Befunde als auf die Gewichtung und die empfohlene Reihenfolge. Und prüfen Sie, ob seine Grenzen benannt sind. Wenn der Bericht steht, ist der nächste Schritt meist die Umsetzung. Den Einstieg dafür finden Sie unter Legacy-Migration und Symfony-Entwicklung.