Les attaques contre la chaîne d’approvisionnement logicielle sont en augmentation et la nécessité de répondre à ce vecteur d’attaque est devenue cruciale. Mais où allez-vous commencer?
Si vous disposiez des plans de bataille de l'attaquant, vous pourriez prioriser vos efforts en conséquence. Nous n'avons pas de plans spécifiques pour un attaquant, mais nous disposons d'un schéma de plans de bataille typiques d'un attaquant : la matrice de menace CI\CD basée sur la Cadre d'attaque et de contrôle MITRE.
La lecture du tableau ci-dessous de gauche à droite nous guide à travers le cycle d'attaque : l'attaquant doit obtenir un accès initial, puis exécuter le code, atteindre la persistance, développer des capacités par élévation de privilèges, évasion de la défense et accès aux informations d'identification. De cette manière, les attaquants peuvent effectuer un mouvement latéral afin d'atteindre leur proie, puis attaquer, soit en s'exfiltrant, soit en provoquant d'autres impacts.
Chaque colonne du tableau répertorie les techniques que l'attaquant peut utiliser. Par exemple, la première colonne suggère que l'accès initial pourrait être obtenu soit par une compromission préalable du CI\CD, soit par des contrôles d'accès faibles (compte valide d'un service Git, compte valide d'un service CI\CD ou compte administrateur valide d'un serveur critique).
L'approche fondée sur des preuves de Scribe pour sécuriser la chaîne d'approvisionnement est essentiellement simple :
Ne faites confiance à un artefact que s'il est associé à des preuves à l'appui, des preuves signées qui sont définies comme des attestations numériques.
Pour mettre en œuvre cette approche, Scribe fournit les outils logiciels nécessaires pour collecter et gérer ces preuves et évaluer la fiabilité de l'artefact conformément aux politiques et aux attestations (preuves signées).
Obtenir une présentation de la solutionExemples de politiques prises en charge par Scribe :
Politiques de paramètres de sécurité
Assurez-vous que les paramètres de sécurité des services utilisés pendant le processus de génération répondent à une norme prédéfinie.
Politiques de modification source\fichier\module
Vérifiez que le code source, les configurations, les scripts de build et les fichiers IoC ont été modifiés conformément à une norme prédéfinie qui définit les identités, les processus, les étapes et les états.
Politiques d'intégrité source\fichier\module
Assurez-vous que le code source, les fichiers et les modules sont identiques aux versions autorisées prédéterminées.
Politiques de confiance de dépendance
Assurez-vous que les dépendances utilisées sont conformes à une norme prédéfinie (telle que la carte de score OSSF, l'âge de la version, la liste d'autorisation/interdiction).
Politiques de vulnérabilités
Assurez-vous que les dépendances et autres composants de source publique (fermés ou ouverts) ne présentent pas un risque de sécurité élevé.
Politiques relatives au cycle de vie du développement logiciel
Assurez-vous que le code a été examiné par les parties prenantes, que les commentaires ont été résolus et que les tests et les tests de sécurité ont été effectués avec succès.
Politiques de comportement du pipeline
Maintenir le comportement du pipeline conformément au plan. Par exemple, exigez qu'une image soit poussée comme sortie du pipeline et non par un autre processus.
Exemples de preuves que Scribe collecte en continu et de manière automatisée pour chaque build :
SBOM à grain fin provenant du SCM source ainsi que des artefacts finaux (conteneurs)
Instantanés de l'environnement de construction
Instantanés du dépôt source
Paramètre de sécurité de l'environnement de contrôle de code source et de build
Événements pertinents au niveau du système d'exploitation collectés à partir de la machine de build
