Upload SBOM su Dependency-Track nella pipeline

[pintorig]

Aggiunge alla pipeline il caricamento dell'SBOM su Dependency-Track, traducendo in GitHub Actions il job GitLab dependency-track-upload usato su GovDesk.

Cosa cambia

.github/workflows/maven.yml — nuovo job dependency-track-upload:

• dipende dal job sbom esistente e ne scarica l'artifact sbom-report
• carica sbom/cyclonedx/bom.cdx.json sotto il progetto padre GovPay-Backend
• gira su tag e sui branch main/master/staging; forzabile con la variabile FORCE_DTRACK_UPLOAD_JOB, disattivabile con DISABLE_DTRACK_UPLOAD_JOB, che ha la precedenza
• continue-on-error riproduce l'allow_failure differenziato di GitLab: bloccante su tag e branch protetti, tollerante sulle esecuzioni forzate
• versione e flag latest seguono la logica dell'originale: su tag la versione e' il tag ed e' marcata latest, sui branch protetti e' il nome del branch, altrimenti dev
• uno step di verifica prerequisiti controlla separatamente secret, script e SBOM, con un messaggio dedicato per ciascuno

script/sbom/upload-sbom-parent-required.sh — adattamento GovPay dello script GovDesk upload-sbom-dependency-track.sh:

• la gerarchia a 4 livelli (root / group / parent / leaf) e' collassata a un solo livello. Il progetto padre deve gia' esistere e nessun livello intermedio viene creato, coerentemente col nome parent-required
• la firma passa da 7-8 argomenti a 3: <API_KEY> <FILE_SBOM> <PARENT_PROJECT>
• nome e versione del progetto foglia sono ricavati dai metadati dell'SBOM (metadata.component), sovrascrivibili con DTRACK_PROJECT_NAME e DTRACK_VERSION. L'override serve sui branch, dove la versione Maven e' -SNAPSHOT mentre su Dependency-Track vogliamo il nome del branch

Correzioni rispetto allo script di origine

Valgono anche per lo script GovDesk da cui deriva:

• i nomi dei progetti venivano interpolati direttamente nel sorgente Python (p.get('name') == '$name' e la costruzione del body JSON). Un nome contenente un apice rompeva lo script; ora i valori passano per variabili d'ambiente
• il file di risposta di curl era l'hardcoded /tmp/dtrack-upload-response.txt, condiviso fra esecuzioni concorrenti; ora e' un mktemp con cleanup su trap

Verifiche fatte

Testati i percorsi che non richiedono il server: argomenti mancanti, SBOM assente, estrazione dei metadati da un SBOM CycloneDX reale, override via ambiente e lookup del padre fallito. Tutti escono con exit code 1, quindi il job CI fallisce correttamente. YAML del workflow validato.

Non e' stato possibile testare l'upload vero. Richiede un Dependency-Track raggiungibile e una API key valida.

Prerequisiti prima del merge

• secret GOVPAY_DTRACK_API_KEY configurato sul repository, con permessi VIEW_PORTFOLIO, PROJECT_CREATION_UPLOAD, BOM_UPLOAD e PORTFOLIO_MANAGEMENT (quest'ultimo perche' sui tag la versione viene marcata latest)
• progetto GovPay-Backend gia' presente su Dependency-Track, senza versione
• raggiungibilita' di https://lab.link.it/dependency-track da un runner ubuntu-latest: e' il punto piu' incerto, perche' nessun workflow GovPay contatta oggi host interni. Se il servizio non e' esposto pubblicamente serve un runner self-hosted

Rollout

La stessa modifica si replica identica sugli altri progetti backend Java, cambiando solo il progetto padre per govpay (GovPay-Legacy). govpay-console e govpay-portal sono Angular e richiedono un generatore SBOM per npm, quindi un lavoro diverso.