Due modi per vedere CRACI all'opera sulle Sue build
Scelga quello che Le è più utile adesso e imposteremo la chiamata di conseguenza.
Artūrs Vavilovs
Account Executive, CRACI · Helsinki
CRACI è un team di 14 persone a Helsinki, sostenuto da Lifeline Ventures. Stiamo seguendo personalmente l'onboarding di ogni team prima della disponibilità generale, e non Le chiederemo di smontare nulla per scoprire se tutto questo Le è utile.
Che cosa vedremo
- Puntare un workflow rappresentativo su CRACI (runs-on: craci) e confrontare fianco a fianco tempi di build e costi
- Esaminare la SBOM registrata dalla build, comprese le dipendenze nascoste che gli strumenti basati sul lockfile non vedono
- Vedere come la policy di egress blocca le connessioni di cui una build non ha bisogno, prima che lascino il runner
I tempi di build sono un motivo di lamentela nel Suo team, o tutti li hanno ormai accettati in silenzio?
- Come le SBOM e i registri delle vulnerabilità della build si inseriscono nei framework a cui deve attenersi: CRA, NIS2, ISO 27001, SOC 2 e PCI DSS
- Vedere come ogni build distribuita viene monitorata alla ricerca di nuove vulnerabilità e come lo storico delle build mostra quali build ne contenevano una e per quanto tempo
- Se il CRA si applica alla Sua azienda, come CRACI presenta alle autorità le notifiche di vulnerabilità per Suo conto
Quando una vulnerabilità colpisce una dipendenza, quanto tempo Le serve per capire quali delle Sue release la contengono?
Scelga un orario
Scelga una fascia oraria, aggiunga nome ed email e l'invito verrà inviato immediatamente.
Che cosa può verificare durante la chiamata
Build circa 2x più veloci
Rispetto ai runner ospitati da GitHub, grazie a hardware più veloce, tempi di coda più brevi e caching. La chiamata serve proprio a capire se vedrà lo stesso risultato sui Suoi workflow.
SBOM registrate dalla build stessa
CRACI vede ciò che ogni job scarica mentre viene eseguito, quindi la SBOM descrive ciò che è stato distribuito, non ciò che un lockfile lascia supporre.
Policy di egress sul runner
Con una policy default-deny il runner consente solo le sorgenti di cui una build ha bisogno, così un pacchetto compromesso non può inviare i Suoi secret all'host di un attaccante.
SBOM dalla build distribuita
Esportazioni CycloneDX e SPDX con ogni dipendenza transitiva, registrate durante la build della release anziché ricostruite in seguito.
Un'esposizione che può dimostrare
Le build distribuite vengono ricontrollate man mano che compaiono nuove vulnerabilità, e lo storico delle build mostra quali build ne contenevano una e per quanto tempo.
Provenance tramite l'API
L'API restituisce SBOM, tracce di rete e provenance per ogni build, quindi le evidenze provengono dalla build stessa.
Finanziato da
