Deux façons de confronter CRACI à votre build
Choisissez ce qui vous est utile maintenant, et nous construirons l'appel autour de ce sujet.
Artūrs Vavilovs
Account Executive, CRACI · Helsinki
CRACI est une équipe de 14 personnes à Helsinki, soutenue par Lifeline Ventures. Nous accompagnons personnellement chaque équipe dans sa prise en main avant la disponibilité générale, et nous ne vous demanderons pas de tout démonter pour savoir si cela vous est utile.
Ce que nous allons passer en revue
- Faire pointer un workflow représentatif vers CRACI (runs-on: craci) et comparer côte à côte le temps de build et le coût
- Parcourir la SBOM enregistrée par le build, y compris les dépendances cachées que les outils basés sur les lockfiles ne voient pas
- Voir comment la politique de trafic sortant bloque les connexions dont un build n'a pas besoin, avant qu'elles ne quittent le runner
Le temps de build est-il un sujet de plainte dans votre équipe, ou tout le monde s'y est-il résigné en silence ?
- Comment les SBOM et les enregistrements de vulnérabilités du build s'inscrivent dans les cadres auxquels vous êtes soumis : le CRA, NIS2, ISO 27001, SOC 2 et PCI DSS
- Voir comment chaque build livré est surveillé face aux nouvelles vulnérabilités, et comment l'historique des builds montre lesquels en contenaient une et pendant combien de temps
- Si le CRA s'applique à vous, comment CRACI soumet les notifications de vulnérabilités aux autorités en votre nom
Quand une vulnérabilité touche une dépendance, combien de temps vous faut-il pour savoir lesquelles de vos releases la contiennent ?
Choisissez un créneau
Choisissez un créneau, indiquez votre nom et votre e-mail, et l'invitation part aussitôt.
Ce que vous pouvez vérifier pendant l'appel
Des builds environ 2 fois plus rapides
Par rapport aux runners hébergés par GitHub, grâce à un matériel plus rapide, à des files d'attente plus courtes et au cache. L'appel sert justement à vérifier si vous obtenez le même résultat sur vos workflows.
Des SBOM enregistrées pendant le build
CRACI voit ce que chaque job récupère pendant son exécution : la SBOM décrit donc ce qui a été livré, et non ce que suggère un lockfile.
Politique de trafic sortant sur le runner
Avec une politique en refus par défaut, le runner n'autorise que les sources dont un build a besoin : un paquet compromis ne peut donc pas envoyer vos secrets vers l'hôte d'un attaquant.
Des SBOM issues du build livré
Des exports CycloneDX et SPDX avec chaque dépendance transitive, enregistrés pendant le build de la release plutôt que reconstitués après coup.
Une exposition que vous pouvez démontrer
Les builds livrés sont revérifiés à mesure que de nouvelles vulnérabilités apparaissent, et l'historique des builds montre lesquels en contenaient une et pendant combien de temps.
La provenance via l'API
L'API renvoie les SBOM, les traces réseau et la provenance de chaque build : les preuves proviennent donc du build lui-même.
Soutenu par