Die meisten Entwicklerteams führen zwei getrennte Gespräche über dieselbe Codebasis. Das eine dreht sich um die Sicherheit: Besteht ein Risiko durch SQL-Injection, ein fest codiertes Geheimnis oder eine ausnutzbare Abhängigkeit? Das andere um die Wartbarkeit: Ist diese Funktion zu komplex? Ist dieser Code dreimal dupliziert? Gibt es überflüssigen Code, den niemand zu löschen wagt?
Diese Gespräche finden üblicherweise mit unterschiedlichen Tools, von verschiedenen Teams und zu unterschiedlichen Zeiten statt. Ein Sicherheitsscanner markiert ausnutzbare Schwachstellen. Ein separates Qualitätssicherungstool, das oft unabhängig angeschafft und verwaltet wird, identifiziert wartungsintensive Schwachstellen. Zwei Lizenzen, zwei dashboards, zwei Parser durchlaufen denselben abstrakten Syntaxbaum, um zwei verschiedene Fragen zu beantworten.
Diese Trennung hat ihren Preis. Zuverlässigkeitsmängel (die Laufzeitfehler und nicht Sicherheitslücken verursachen) werden nicht mit der gleichen Sorgfalt priorisiert wie Sicherheitsbefunde, da sie außerhalb des Zuständigkeitsbereichs des Sicherheitsteams liegen. dashboardUnd wenn ein Team bereits eine statische Analyse-Engine hat, die jede Datei aus Sicherheitsgründen analysiert, ist die Einrichtung einer zweiten, unabhängigen Engine nur zur Überprüfung der Codequalität redundante Arbeit ohne gemeinsamen Nutzen.
Warum Codequalität wichtig ist (und wie sie sich von … unterscheidet) Code Security)
Codequalität und code security Beantworte zwei verschiedene Fragen. Code security Die Codequalität fragt: Ist dieser Code angreifbar? Die Codequalität fragt: Ist dieser Code wartbar? Eine Funktion kann vollkommen sicher sein und trotzdem ein fünfhundertzeiliges Code-Chaos darstellen, das niemand anfassen möchte. Und ein gut strukturiertes, leicht lesbares Modul kann dennoch eine kritische Sicherheitslücke aufweisen. Die beiden Disziplinen ersetzen einander nicht.
Die Kosten mangelnder Codequalität zeigen sich nicht sofort als Sicherheitslücke. Sie bemerkbar machen sich schleichend bemerkbar: Ein neuer Mitarbeiter benötigt zwei Wochen statt zwei Tage, um eine sichere Änderung vorzunehmen; eine Routinefunktion dauert drei Sprints, weil niemand vorhersehen kann, welche Auswirkungen ein duplizierter Codeblock an anderer Stelle haben wird; ein Bereitschaftsingenieur verbringt eine Stunde damit, einen Fehler in veraltetem Code aufzuspüren, der eigentlich schon vor einem Jahr hätte entfernt werden sollen. Nichts davon löst eine Sicherheitswarnung aus. All das schlägt sich in der Velocity nieder, und bis es in der Sprint-Retrospektive sichtbar wird, sind die Behebungskosten bereits hoch.
Das gilt auch für die Behandlung von Qualität mit der gleichen Strenge wie von Sicherheit: nicht weil ein Code-Gerücht eine Bedrohung darstellt, sondern weil das unkontrollierte Anhäufen von Wartungsschulden dazu führt, dass eine Codebasis zum Ort wird, an dem Funktionen sterben.
Der bessere Weg: Ein Motor, zwei Regelkataloge
Der Code Quality Scanner von Xygeni analysiert Quellcode auf Wartbarkeits- und Zuverlässigkeitsmängel: Code-Smells, Komplexitätsverletzungen, toter Code und Duplikation – Muster, die zwar keine Sicherheitslücke verursachen, aber Ausfälle, Regressionen und langsame Arbeitsteams zur Folge haben.
Die entscheidende Designentscheidung ist architektonischer, nicht kosmetischer Natur. Code Quality teilt seine statische Analyse-Engine mit Xygenis SAST ScannerDie gleichen Parser, die gleiche AST-Konstruktion, die gleiche Dateierkennung. Was sich unterscheidet, ist der Regelkatalog. Qualitätsregeln beziehen sich auf Qualität, nicht auf Sicherheit, und die Ergebnisse werden in einem separaten Qualitätsbereich der Xygeni-Plattform angezeigt. SAST und die übrigen Sicherheitsrisikotabellen.
Das Ergebnis: Teams erhalten aus demselben Analysedurchlauf eine Sicht auf Wartbarkeit und Sicherheit, ohne dass zwei unterschiedliche Aspekte zu einem einzigen verworrenen Ergebnis zusammengeführt werden. dashboard.
Zwei Wege zu einem besseren Signal in Ihrem Pipeline
Nicht alle Funktionen zur „Codequalität“ funktionieren intern auf die gleiche Weise. Viele CI/CD-native Qualitätswerkzeuge sind Aggregationsschichten: Sie analysieren Ihren Code nicht selbst.Sie importieren Ergebnisse des jeweils aktuell ausgeführten Linters (JavaScript-Linter, Python-Linter, Duplikatdetektor), die jeweils in ein gemeinsames JSON-Schema umformatiert und als eigene Schnittstelle konfiguriert werden. pipeline Schritt. Das ist flexibel, bedeutet aber auch, dass Ihr Qualitätssignal nur so konsistent ist wie die Anzahl der einzelnen Tools, Formate und Betreuer, die Sie miteinander verknüpft haben – eines pro Sprache.
Der Codequalitätsscanner von Xygeni geht einen anderen Weg: eine native Engine, die bereits für die Sicherheit zuständig ist, erweitert um einen Katalog mit Qualitätsregeln. Es muss kein sprachspezifischer Linter installiert, kein Berichtsformat neu formatiert und kein separater Job pro Tool verwaltet werden. Sie erhalten einen Befehl, ein einheitliches Schweregradmodell und eine einzige dashboard Abschnitt, weil die Analyse von vornherein nie auf verschiedene Tools aufgeteilt wurde.
Wie es funktioniert?
Code Quality läuft als eigener CLI-Befehl:
xygeni Qualität -d [Optionen] (xygeni code-quality funktioniert als Alias.)
Es teilt sein Optionsmodell mit xygeni sastJeder, der bereits den Sicherheitsscanner von Xygeni verwendet, wird die Benutzeroberfläche daher sofort wiedererkennen:
Generieren eines Codequalitätsberichts
Ein Scan erzeugt einen Codequalitätsbericht, den Sie an die Plattform senden, als JSON für CI-Artefakte exportieren oder einem Teamleiter übergeben können, ohne ihn direkt zu kontaktieren. dashboard Zugriff. Beides sind Einzeiler-Befehle:
# Scannen und direkt auf die Xygeni-Plattform hochladen
xygeni quality -n MyProject –upload
# Exportiere einen Codequalitätsbericht als JSON, nur kritische Ergebnisse
xygeni Qualität -d –detectors critical –format json –output quality.json
Nach dem Hochladen wird dieser Codequalitätsbericht automatisch im Qualitätsabschnitt angezeigt. dashboard: filterbar, mit ausklappbaren Details pro Ergebnis, Baselines und dem gleichen Berichtsverhalten, das Teams bereits verwenden für SAST.
Qualitätskontrolle parallel zu einem Sicherheitsscan
Für Teams, die beide Signale mit einem einzigen Pass erhalten möchten, SAST Der Scanner akzeptiert einen –include-quality Flagge:
xygeni sast -D –include-quality
Parce que SAST Die Scanner für Sicherheit und Codequalität teilen sich die Parser-Phase; dies ist effizienter als die direkte Ausführung der beiden Scanner. Es werden zwei separate Berichte erstellt – ein Sicherheits- und ein Qualitätsbericht –, die jeweils in einem eigenen Verzeichnis landen. dashboard Abschnitt. Das Flag ändert die Ausführung des Scans, nicht die Organisation der Ergebnisse.
Scannen ohne Verbindung
In abgeschotteten Umgebungen oder bei CI-Runnern ohne Zugriff auf die Xygeni-Plattform können Qualitätsscans lokal ausgeführt und später hochgeladen werden:
xygeni Qualität -d -n MeinProjekt
# …später von einem Host mit Internetverbindung:
xygeni report-upload -n MyProject -r depsdoctor-quality.json
Die Ergebnisse landen im Qualitätsteil genau so, wie sie bei einem Live-Scan auftreten würden: gleiche Triage, gleiche Vorgehensweise, gleiches Ausgangsverhalten.
Warum die Trennung von Qualität und Sicherheit wichtig ist
Es wäre einfach, Code-Smells in dieselbe Schweregradliste wie ausnutzbare Sicherheitslücken einzuordnen. Xygeni tut dies bewusst nicht. Eine duplizierte Funktion und eine SQL-Injection stellen nicht dasselbe Risiko dar, und eine Gleichbehandlung führt dazu, dass Teams entweder überreagieren, wenn es um die Wartbarkeit geht, oder auf tatsächliche Sicherheitsbedenken zu wenig reagieren. Die Regelkataloge, die Berichte und die dashboard Durch die Trennung der Ansichten bei gleichzeitiger gemeinsamer Nutzung der zugrundeliegenden Engine erhält jedes Team das für es relevante Signal, ohne für ein zweites statisches Analysetool bezahlen zu müssen.
Probieren Sie es aus: Codequalität ist ab heute über die Xygeni-Befehlszeilenschnittstelle verfügbar. Teams, die bereits damit arbeiten xygeni sast kann hinzufügen –include-quality zu ihrem Bestehenden pipeline in einer Zeile, kein neues Tool zum Einbinden, keine zweite dashboard überprüfen.
FAQ
Was ist Xygeni-Codequalität?
Xygeni Code Quality ist ein statischer Codeanalyse-Scanner, der Wartbarkeits- und Zuverlässigkeitsmängel erkennt, darunter Code-Smells, Komplexitätsverletzungen, toten Code und Duplikate. Er wird als eigenständiger Befehl ausgeführt (xygeni Qualität) und werden in einem separaten Qualitätsbereich der Xygeni-Plattform, getrennt von den Sicherheitsergebnissen, gemeldet.
Ist Codequalität dasselbe wie SAST?
Nein. Codequalität und SAST Sie nutzen zwar dieselbe zugrundeliegende Parsing-Engine, verwenden aber unabhängige Regelkataloge und erstellen unabhängige Berichte. SAST sucht nach Sicherheitslücken; die Codequalität sucht nach Mängeln in Bezug auf Wartbarkeit und Zuverlässigkeit.
Kann ich gleichzeitig einen Qualitätsscan und einen Sicherheitsscan durchführen?
Ja. Laufen xygeni sast -D –include-quality Führt beide Regelsätze in einem einzigen Durchlauf aus, was effizienter ist als die separate Ausführung der beiden Scanner, da sie die Parserstufe gemeinsam nutzen. Die Ergebnisse werden dennoch in zwei separaten Berichten und zwei separaten Dokumenten angezeigt. dashboard .
Benötige ich eine separate Lizenz für Code Quality?
Zum Hochladen und Anzeigen von Qualitätsergebnissen wird die Codequalitätsberechtigung benötigt, dieselbe, die auch zum Ausführen des Scans erforderlich ist.
Kann Code Quality ohne Internetzugang funktionieren?
Ja. Scans können lokal ohne die -hochladen Flagge, und der resultierende Bericht kann später von einem verbundenen Host aus hochgeladen werden. xygeni report-upload.
