Roadmap: nichts davon existiert bisher

Code-Scans ergeben nur Sinn, wenn die Plattform Prüfungen versteht: Ergebnisse, die zu einem Commit gehören, an einem Merge Request erscheinen und einen Merge stoppen können. Diese Version baut dieses Fundament, übersetzt die Oberfläche und lässt das Design wählen.

• Geschützte Branches: kein direkter Push, Merge nur über einen Merge Request, erforderliche Freigaben und erforderliche Prüfungen.
• Pipelines für Merge Requests, deren Status am Merge Request angezeigt und vor dem Merge verlangt wird.
• Vordefinierte CI-Variablen (Commit, Branch, Merge Request, Pipeline) und rules, die entscheiden, wann ein Job läuft.
• Pipeline-Artefakte und eine API zum Hochladen von Berichten, die die Scans der nächsten Versionen nutzen.
• Eine Pipeline über die Oberfläche erneut ausführen, und geplante Pipelines.
• Persönliche Zugriffstokens, die sich mit Geltungsbereichen in der REST-API verwenden lassen, und eine aus dem Code erzeugte OpenAPI-Beschreibung.
• Eine erste Verbindung zu ArtiFerris: ein von einer Pipeline gebautes Artefakt in eine ArtiFerris-Instanz veröffentlichen.
• Die Oberfläche auf Englisch, Französisch, Italienisch, Spanisch und Deutsch. Die Sprache folgt beim ersten Besuch dem Browser, lässt sich jederzeit wechseln und wird im Konto gespeichert. Die E-Mails von FerrisGit nutzen die Sprache des Empfängers, und die öffentlichen Seiten folgen dem Accept-Language des Lesers. Die Dokumentation wird danach übersetzt.
• Dunkelmodus als Einstellung: System, hell oder dunkel, im Konto gespeichert und ohne Aufblitzen angewendet. Heute folgt die Oberfläche der Systemeinstellung und hat keinen Schalter. Auch das Logo der angemeldeten Oberfläche folgt dem Design.

FerrisGit bekommt eine eigene Analyse-Engine, statt Werkzeuge von Drittanbietern zu umhüllen: eine Binärdatei ferrisgit-scan, die ein Pipeline-Job ausführt, sodass die Analyse mit den Runnern skaliert und der Server schlank bleibt. Ihre Analyzer sind Plugins, die Befunde in einem SARIF-nahen Modell erzeugen, sodass sich Berichte anderer Werkzeuge neben den nativen importieren lassen.

• Die Engine und der Befundspeicher: ein Scan pro Commit, Befunde mit stabilem Fingerabdruck und eine Baseline pro Branch, um die neuen Befunde eines Merge Requests von den alten zu unterscheiden.
• Native Erkennung von Secrets, im Diff eines Merge Requests und in der gesamten Historie.
• Native Prüfung von Abhängigkeiten: Lockfiles (Cargo.lock, package-lock.json, später weitere) werden mit öffentlichen Advisory-Datenbanken wie OSV abgeglichen.
• Befunde, die inline im Diff des Merge Requests angezeigt und in dessen Verlauf zusammengefasst werden.
• Import von SARIF-Berichten anderer Werkzeuge.

• Quality Gates, pro Repository konfigurierbar: zum Beispiel kein neuer blockierender Befund und eine Mindestabdeckung für neuen Code. Ein Gate ist eine erforderliche Prüfung und kann daher einen Merge blockieren.
• Ein Repository-Dashboard: offene Befunde, ihr Alter, Trend pro Branch, technische Schulden und Hotspots.
• Triage: einen Befund als False Positive oder als "won't fix" markieren, zuweisen, im Code unterdrücken und die Historie behalten.
• Eine Datei .ferrisgit/scan.yml, um Analyzer, Regelsätze und Schwellenwerte zu wählen und Pfade auszuschließen.

Das gesamte Repository wird bei jedem Push auf den Standard-Branch und bei jedem Merge Request analysiert, und die Gates betrachten nur, was ein Merge Request neu einbringt (der Ansatz "clean as you code"), sodass sich ein bestehendes Projekt weiterhin einführen lässt.

• Parsing über tree-sitter, damit dieselbe Engine mehrere Sprachen liest. Zuerst Rust und TypeScript.
• Metriken: Größe, zyklomatische und kognitive Komplexität, Duplikate.
• Code Smells und Fehlermuster, als deklarative und als native Regeln.
• Verfolgung der Testabdeckung (LCOV- und Cobertura-Berichte), mit der Abdeckung dessen, was ein Merge Request ändert.

• Static Application Security Testing: zuerst Musterregeln, danach Datenfluss innerhalb einer Funktion.
• Scans von Container-Images und Infrastructure as Code.
• Eine Sicherheitszusammenfassung an jedem Merge Request und ein Sicherheits-Dashboard für das Repository, mit Schweregraden und der Möglichkeit, Merges ab einem gewählten Schweregrad zu blockieren.
• Jedes in ArtiFerris veröffentlichte Artefakt bis zu Commit, Merge Request und Pipeline zurückverfolgen, die es erzeugt haben, und es auf den Release- und Pipeline-Seiten von FerrisGit anzeigen.
• Die Scan-Ergebnisse der Artefakte aus ArtiFerris in die Prüfungen der Merge Requests zurückbringen.
• Eine gemeinsame Identität prüfen, sodass ein Konto und eine MFA-Registrierung auf beiden Plattformen funktionieren.

• Git über SSH und Deploy Keys.
• Forks und Merge Requests zwischen Repositories; Umbenennen und Übertragen eines Repositorys mit Weiterleitungen.
• Squash- und Rebase-Merges, Wiedereröffnen eines Merge Requests, Draft-Merge-Requests und CODEOWNERS.
• Erwähnungen (@name), Issue-Verweise (#12) und das Schließen eines Issues aus einem Commit oder Merge Request.
• Volltextsuche im Code und Import von GitHub und GitLab.
• Passwort-Zurücksetzung in Eigenregie, E-Mail-Benachrichtigungen mit Einstellungen pro Benutzer und Single Sign-on (OIDC, LDAP).
• Eine Audit-Log-Seite in der Administration, Prometheus-Metriken und Werkzeuge für Sicherung und Wiederherstellung.
• Webhooks mit Wiederholungsversuchen, einem Zustellprotokoll und mehr Ereignissen (Push, Release).

Ideen ohne Version; was sie umfassen, ist noch festzulegen.

• KI-Agenten für ein Repository. Denkbar sind: ein Review-Assistent für Merge Requests, Zusammenfassungen von Merge Requests und Commits, die Erklärung, warum eine Pipeline fehlgeschlagen ist, sowie Triage und Labeling von Issues. Was erscheint, muss zu einer selbst gehosteten Plattform passen: ein Modell-Endpunkt, den der Administrator wählt (auch ein lokaler), Aktivierung pro Repository, Zugangsdaten mit begrenztem Umfang und jede Aktion protokolliert.
• Ein Commit-Graph in der Repository-Ansicht: Branches, Merges und Tags gemeinsam gezeichnet, neben dem Dateibaum und der Commit-Liste, die es bereits gibt.
• Profilfotos, gespeichert in S3-kompatiblem Objektspeicher. Die Initialen bleiben als Ersatz, und derselbe Speicher könnte später Release-Dateien und Pipeline-Artefakte aufnehmen.

ArtiFerris speichert bereits npm-Pakete und Docker/OCI-Images und prüft sie auf Schwachstellen. FerrisGit und ArtiFerris sind zwei einander ergänzende Hälften derselben Auslieferungskette. Die Verbindung wächst in drei Schritten: Veröffentlichen aus einer Pipeline (0.2), ein Artefakt bis zu seinem Commit zurückverfolgen (0.6) und die Scan-Ergebnisse in die Prüfungen der Merge Requests zurückbringen (0.6). Eine gemeinsame Identität bleibt eine offene Frage.