Sicurezza della software supply chain, registrata da ogni build
La Sua software supply chain incontra il Suo prodotto nella build CI. CRACI esegue i Suoi job GitHub Actions su runner sicuri e registra ogni dipendenza che scaricano, controlla che cosa può raggiungere ogni build e continua a monitorare le vulnerabilità in ciò che Lei ha distribuito.
Runner sicuri per GitHub Actions
Cambi runs-on in craci e i Suoi job GitHub Actions vengono eseguiti sui runner di CRACI, mentre le esecuzioni restano visibili in GitHub. Ogni job ha la propria macchina virtuale isolata su Linux x86-64 o ARM64, ospitata in Europa. Le build sono circa due volte più veloci che sui runner ospitati da GitHub, grazie a hardware più veloce, code più brevi e caching.
Una SBOM registrata da ogni build
CRACI registra, non scansiona. Un proxy sul runner che riconosce i pacchetti vede ogni pacchetto che il job scarica da npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download di Yocto e OpenEmbedded, compresi i pacchetti ripristinati dalle cache CI. La SBOM di ogni job riporta uno stato di completezza e si esporta in CycloneDX o SPDX con le dipendenze transitive e la licenza dichiarata di ogni componente.
Decida che cosa può raggiungere una build
Una policy di egress stabilisce a quali host un job può connettersi: negazione o autorizzazione predefinita, 24 preset integrati di sorgenti software, sorgenti personalizzate tipizzate per registry di pacchetti e Git, e regole di rete esplicite. La policy viene convalidata prima dell'avvio del job e opera in modalità fail closed, e le violazioni generano un alert. Una dipendenza o un passaggio di build compromesso non può inviare di nascosto dati a un host che Lei non ha mai approvato.
Provenance per ciò che distribuisce
La REST API pubblica restituisce SBOM, tracce di rete e provenance per ogni job, tutte registrate dalla stessa build. Le evidenze nascono dalla build stessa, senza passaggi aggiuntivi nel workflow.
Monitoraggio delle vulnerabilità dopo il rilascio
CRACI continua a rivalutare le SBOM di ciò che Lei ha distribuito man mano che vengono pubblicate nuove vulnerabilità e aggrega i risultati di tutte le build e di tutti i repository. I team di sicurezza li esaminano e inoltrano ciascuno al team responsabile della correzione. I policy gate possono bloccare una build in base ai risultati o a una licenza, VEX è supportato, le SBOM dei fornitori vengono monitorate insieme alle Sue build e la vista di inventario mostra quali versioni del software sono distribuite su quali prodotti.
Evidenze per clienti e auditor
Clienti, auditor e normative chiedono sempre più spesso una SBOM per ogni release e un registro di come sono state gestite le vulnerabilità. CRACI esporta le SBOM in CycloneDX o SPDX, comprese le vulnerabilità rilevate nei loro componenti, e una REST API pubblica restituisce SBOM, tracce di rete e provenance. Le stesse evidenze supportano il Cyber Resilience Act dell'UE, NIS2, i requisiti SBOM della FDA e i controlli ISO 27001 sulla supply chain.
Le domande che solleva un incidente della supply chain
Quando un pacchetto, una action CI o un registry viene compromesso, le prime ore servono a capire se si è colpiti. Queste sono le domande che si pongono i team, e i punti in cui il registro della build di CRACI dà la risposta.
| La domanda | Come risponde CRACI |
|---|---|
| Qualcuna delle nostre build ha scaricato la versione compromessa del pacchetto? | La SBOM di ogni build elenca i pacchetti che il job ha effettivamente scaricato, quindi si cerca tra le build registrate invece di scansionare di nuovo i repository. |
| Quali dei nostri prodotti e delle nostre release sono colpiti? | Le SBOM monitorate vengono rivalutate di continuo e la vista di inventario associa le versioni del software ai prodotti su cui sono distribuite. |
| Un passaggio di build potrebbe aver inviato dei secret da qualche parte? | La traccia di rete di ogni job registra le connessioni effettuate, e la policy di egress blocca gli host esterni alla policy prima che vengano raggiunti. |
| Questa SBOM è abbastanza completa da poterla consegnare? | La SBOM di ogni job ne indica la completezza: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. |
| Chi se ne occupa, e possiamo dimostrare che è stato gestito? | I risultati vengono esaminati e inoltrati ai team responsabili, e le SBOM si esportano in CycloneDX o SPDX con le vulnerabilità rilevate nei loro componenti. |
CRACI copre la build e ciò che distribuisce. Scansione del codice, scansione dei secret e analisi di raggiungibilità restano compito dei Suoi strumenti di application security. Oggi è supportato GitHub Actions, con altri sistemi CI in roadmap.
Sicurezza della software supply chain: le risposte
Che cosa copre, perché va nella CI/CD e dove si colloca CRACI
Che cos'è la sicurezza della software supply chain?
La sicurezza della software supply chain protegge tutto ciò che entra nel Suo software tra il primo commit e il rilascio: dipendenze open source, immagini base, strumenti di build, action CI di terze parti, la pipeline CI stessa e gli artefatti che distribuisce. Significa sapere quali sono questi elementi, controllarne la provenienza e dimostrare che cosa è entrato in ogni release.
Perché proteggere la software supply chain nella CI/CD?
La build di release è il punto in cui le dipendenze vengono risolte, scaricate e impacchettate. Una build di produzione non è la build su un portatile: intervalli di versioni, tag modificabili e cache fanno sì che possa scaricare qualcosa di diverso. Un registro acquisito durante l'esecuzione della build di release è l'unico registro affidabile di ciò che è stato distribuito, e il runner della build è il punto in cui si può controllare che cosa la build può raggiungere.
In che cosa CRACI si differenzia da uno scanner per la sicurezza della supply chain?
Gli scanner leggono i file a posteriori: un manifest, un lockfile, il codice sorgente o un binario finito. CRACI è il runner dei Suoi job GitHub Actions, quindi osserva la build mentre avviene e registra i pacchetti che ogni job ha effettivamente scaricato, compresi i pacchetti ripristinati dalle cache CI. Ogni SBOM indica la propria completezza, una policy di egress controlla che cosa la build può raggiungere e l'API restituisce SBOM, tracce di rete e provenance.
CRACI sostituisce i miei workflow GitHub Actions?
No. CRACI sostituisce il runner, non GitHub Actions. Lei cambia runs-on in craci, e i Suoi workflow, i trigger e la cronologia delle esecuzioni restano in GitHub.
Quali sistemi CI e quali piattaforme supporta CRACI?
Oggi GitHub Actions; altri sistemi CI sono in roadmap, tra cui GitLab CI e Jenkins. I runner sono Linux su x86-64 e ARM64, con Windows e macOS in roadmap.
CRACI esegue SAST, scansione dei secret o analisi di raggiungibilità?
No. CRACI registra e controlla la build, monitora le vulnerabilità in ciò che Lei ha distribuito e produce le evidenze. La scansione del Suo codice alla ricerca di difetti o secret, e l'analisi di raggiungibilità, sono compiti di uno strumento di application security.
Dove vengono conservati i dati delle mie build?
CRACI è ospitato in Europa, su infrastruttura bare metal europea, e i dati vengono conservati per 180 giorni per impostazione predefinita, con conservazione personalizzata nel piano Enterprise. CRACI non conserva il Suo codice sorgente. CRACI è certificato ISO 27001; i dettagli sono nel Trust Center.
Veda che cosa scaricano davvero le Sue build
Prenoti una demo per vedere la SBOM, la traccia di rete, la policy di egress e la provenance che CRACI registra per una build GitHub Actions
Prenota una demo