Roadmap: niente di questo esiste ancora

L'analisi del codice ha senso solo se la piattaforma capisce i controlli: risultati che appartengono a un commit, compaiono su una merge request e possono bloccarne il merge. Questa versione costruisce quella base, traduce l'interfaccia e permette di sceglierne il tema.

• Branch protetti: nessun push diretto, merge solo tramite una merge request, approvazioni e controlli obbligatori.
• Pipeline sulle merge request, con il loro stato mostrato sulla merge request e richiesto prima del merge.
• Variabili CI predefinite (commit, branch, merge request, pipeline) e rules per decidere quando un job viene eseguito.
• Artefatti di pipeline e un'API per caricare i report, che è ciò che useranno le analisi delle versioni successive.
• Rieseguire una pipeline dall'interfaccia, e pipeline pianificate.
• Token di accesso personali utilizzabili sull'API REST, con ambiti, e una descrizione OpenAPI generata dal codice.
• Un primo collegamento con ArtiFerris: pubblicare su un'istanza ArtiFerris un artefatto costruito da una pipeline.
• L'interfaccia in inglese, francese, italiano, spagnolo e tedesco. La lingua segue il browser alla prima visita, si può cambiare al volo ed è salvata nell'account. Le e-mail inviate da FerrisGit usano la lingua del destinatario e le pagine pubbliche seguono l'Accept-Language del lettore. La documentazione viene tradotta in un secondo momento.
• Modalità scura come impostazione: sistema, chiaro o scuro, salvata nell'account e applicata senza sfarfallio. Oggi l'interfaccia segue la preferenza del sistema e non ha un interruttore. Anche il logo della shell con l'accesso effettuato segue il tema.

FerrisGit si dota di un proprio motore di analisi invece di incapsulare strumenti di terze parti: un binario ferrisgit-scan eseguito da un job di pipeline, così l'analisi scala con i runner e il server resta leggero. I suoi analizzatori sono plugin che producono risultati in un modello vicino a SARIF, quindi i report di altri strumenti si possono importare accanto a quelli nativi.

• Il motore e l'archivio dei risultati: una scansione per commit, risultati identificati da un'impronta stabile e una baseline per branch per distinguere i risultati nuovi di una merge request da quelli vecchi.
• Rilevamento nativo dei segreti, nel diff di una merge request e in tutta la cronologia.
• Audit nativo delle dipendenze: i lockfile (Cargo.lock, package-lock.json, altri in seguito) confrontati con database pubblici di advisory come OSV.
• Risultati mostrati in linea nel diff della merge request e riassunti nella sua cronologia.
• Importazione di report SARIF di altri strumenti.

• Quality gate configurabili per repository: per esempio nessun nuovo risultato bloccante e una copertura minima sul codice nuovo. Un gate è un controllo obbligatorio, quindi può bloccare un merge.
• Una dashboard del repository: risultati aperti, la loro età, andamento per branch, debito tecnico e hotspot.
• Triage: segnare un risultato come falso positivo o come da non correggere, assegnarlo, sopprimerlo nel codice e conservarne la cronologia.
• Un file .ferrisgit/scan.yml per scegliere analizzatori, insiemi di regole e soglie, e per escludere percorsi.

L'intero repository viene analizzato a ogni push sul branch predefinito e a ogni merge request, e i gate guardano solo ciò che una merge request introduce (l'approccio "clean as you code"), così un progetto esistente resta adottabile.

• Parsing con tree-sitter, in modo che lo stesso motore legga più linguaggi. Prima Rust e TypeScript.
• Metriche: dimensione, complessità ciclomatica e cognitiva, duplicazione.
• Code smell e pattern di bug, come regole dichiarative e come regole native.
• Monitoraggio della copertura dei test (report LCOV e Cobertura), con la copertura di ciò che una merge request modifica.

• Static application security testing: prima regole basate su pattern, poi il flusso dei dati all'interno di una funzione.
• Scansione delle immagini dei container e dell'infrastructure-as-code.
• Un riepilogo di sicurezza su ogni merge request e una dashboard di sicurezza per il repository, con gravità e la possibilità di bloccare il merge oltre una gravità scelta.
• Risalire da ogni artefatto pubblicato su ArtiFerris al commit, alla merge request e alla pipeline che lo hanno prodotto, e mostrarlo nelle pagine delle release e delle pipeline di FerrisGit.
• Riportare i risultati delle scansioni degli artefatti di ArtiFerris nei controlli delle merge request.
• Esplorare un'identità condivisa, in modo che un solo account e una sola registrazione MFA funzionino su entrambe le piattaforme.

• Git su SSH e deploy key.
• Fork e merge request tra repository; rinominare e trasferire un repository con redirect.
• Merge con squash e rebase, riapertura di una merge request, merge request in bozza e CODEOWNERS.
• Menzioni (@nome), riferimenti alle issue (#12) e chiusura di una issue da un commit o da una merge request.
• Ricerca full-text nel codice, e importazione da GitHub e GitLab.
• Reimpostazione della password in autonomia, notifiche e-mail con impostazioni per utente, e single sign-on (OIDC, LDAP).
• Una pagina del registro di audit nell'amministrazione, metriche Prometheus e strumenti di backup e ripristino.
• Webhook con nuovi tentativi, un registro delle consegne e più eventi (push, release).

Idee senza una versione: il loro contenuto è ancora da definire.

• Agenti IA su un repository. Possibilità: un assistente di revisione sulle merge request, riepiloghi di merge request e commit, la spiegazione del perché una pipeline è fallita, smistamento ed etichettatura delle issue. Ciò che verrà rilasciato deve adattarsi a una piattaforma self-hosted: un endpoint del modello scelto dall'amministratore (anche locale), attivazione per singolo repository, credenziali con ambito limitato e ogni azione registrata.
• Un grafo dei commit nella vista del repository: branch, merge e tag disegnati insieme, accanto all'albero dei file e all'elenco dei commit che già esistono.
• Foto del profilo, archiviate in uno storage a oggetti compatibile con S3. Le iniziali restano come ripiego, e lo stesso storage potrebbe in seguito ospitare i file delle release e gli artefatti delle pipeline.

ArtiFerris conserva già pacchetti npm e immagini Docker/OCI e ne analizza le vulnerabilità. FerrisGit e ArtiFerris sono due metà complementari della stessa catena di consegna. Il collegamento cresce in tre passi: pubblicare da una pipeline (0.2), risalire da un artefatto al suo commit (0.6) e riportare i risultati delle scansioni nei controlli delle merge request (0.6). L'identità condivisa resta una questione aperta.