aquasecurity/chain-benchAudit la conformité de la sécurité de la chaîne d'approvisionnement logicielle par rapport au benchmark CIS, en analysant les paramètres SCM, les protections de branches, les dépendances et les pipelines CI/CD pour détecter les risques.
Chain-bench est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle en matière de conformité de sécurité, basé sur un nouveau benchmark CIS Software Supply Chain. L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler les risques depuis le moment du code jusqu'au déploiement. Pour gagner la course contre les hackers et protéger vos données sensibles et la confiance de vos clients, vous devez vous assurer que votre code est conforme aux politiques de votre organisation.
Lisez-en plus dans la Documentation Chain-bench
Chain-bench est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle en matière de conformité de sécurité, basé sur un nouveau benchmark CIS Software Supply Chain. L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler les risques depuis le moment du code jusqu'au déploiement.
La principale façon d'exécuter chain-bench est en tant qu'interface en ligne de commande autonome. Il nécessite un jeton d'accès pour votre compte ainsi que l'URL du dépôt afin d'accéder à votre SCM.
Obtenez Chain-bench via votre méthode d'installation préférée. Voir la section installation dans la documentation pour plus de détails. Par exemple :
brew install chain-benchnix-env --install -A nixpkgs.chain-benchdocker run aquasec/chain-benchchain-bench scan --repository-url <URL_DU_DÉPÔT> --access-token <JETON> -o <CHEMIN_DE_SORTIE>
chain-bench scan --repository-url <URL_DU_DÉPÔT> --scm-platform <PLATEFORME_SCM> --access-token <JETON> -o <CHEMIN_DE_SORTIE>
Les options supportées pour scm-platform sont "github" et "gitlab" (bêta)
docker run aquasec/chain-bench scan --repository-url <URL_DU_DÉPÔT> --access-token <JETON>
Voir le dépôt sur https://github.com/aquasecurity/chain-bench-action
2022-06-13 15:22:18 INF 🚩 Début de la récupération
2022-06-13 15:22:19 INF 🏢 Récupération des paramètres de l'organisation terminée
2022-06-13 15:22:29 INF 🛢️ Récupération des paramètres du dépôt terminée
2022-06-13 15:22:29 INF 🌱 Récupération des paramètres de protection de branche terminée
2022-06-13 15:22:29 INF 👫 Récupération des membres terminée
2022-06-13 15:22:31 INF 🔧 Récupération des pipelines terminée
2022-06-13 15:22:31 INF 🏁 Récupération réussie
ID Nom Résultat Raison
-------- ----------------------------------------------------------------------------------------------- -------- ---------------------------------------
1.1.3 S'assurer que toute modification du code reçoit l'approbation de deux utilisateurs fortement authentifiés Réussi
1.1.4 S'assurer que les approbations précédentes sont annulées lorsque des mises à jour sont introduites dans une proposition de modification de code Échoué
1.1.5 S'assurer qu'il existe des restrictions sur qui peut annuler les révisions de modifications de code Échoué
1.1.6 S'assurer que les propriétaires de code sont définis pour les codes ou configurations particulièrement sensibles Échoué
1.1.8 S'assurer que les branches inactives sont révisées et supprimées périodiquement Échoué 20 branches inactives
1.1.9 S'assurer que toutes les vérifications ont réussi avant la fusion du nouveau code Réussi
1.1.10 S'assurer que les branches Git ouvertes sont à jour avant de pouvoir être fusionnées dans la base de code Réussi
1.1.11 S'assurer que tous les commentaires ouverts sont résolus avant d'autoriser la fusion des modifications de code Réussi
1.1.12 S'assurer de la vérification des commits signés des nouvelles modifications avant la fusion Échoué
1.1.13 S'assurer qu'un historique linéaire est requis Réussi
1.1.14 S'assurer que les règles de protection des branches sont appliquées aux administrateurs Échoué
1.1.15 S'assurer que l'ajout de nouveau code est limité à des personnes ou équipes spécifiques Réussi
1.1.16 S'assurer que les pushes forcés de code vers les branches sont refusés Échoué
1.1.17 S'assurer que les suppressions de branches sont refusées Échoué
1.2.1 S'assurer que tous les dépôts publics contiennent un fichier SECURITY.md Échoué
1.2.2 S'assurer que la création de dépôts est limitée à des membres spécifiques Échoué
1.2.3 S'assurer que la suppression de dépôts est limitée à des membres spécifiques Réussi
1.2.4 S'assurer que la suppression de problèmes est limitée à des membres spécifiques Réussi
1.3.1 S'assurer que les utilisateurs inactifs sont révisés et supprimés périodiquement Échoué 22 utilisateurs inactifs
1.3.3 S'assurer qu'un nombre minimum d'administrateurs est défini pour l'organisation Réussi
1.3.5 S'assurer que l'organisation exige des membres qu'ils utilisent l'MFA Réussi
1.3.7 S'assurer que 2 administrateurs sont définis pour chaque dépôt Échoué
1.3.8 S'assurer que des permissions de base strictes sont définies pour les dépôts Réussi
1.3.9 S'assurer que l'identité de l'organisation est confirmée avec un badge vérifié Échoué
2.3.1 S'assurer que toutes les étapes de construction sont définies comme du code Échoué Aucun job de construction trouvé dans les pipelines
2.3.5 S'assurer que l'accès au déclenchement du processus de construction est minimisé Réussi
2.3.7 S'assurer que les pipelines sont automatiquement analysés pour les vulnérabilités Réussi
2.3.8 S'assurer que des analyseurs sont en place pour identifier et empêcher les données sensibles dans les fichiers de pipeline Échoué Le dépôt n'est pas analysé pour les secrets
2.4.2 S'assurer que toutes les dépendances externes utilisées dans le processus de construction sont verrouillées Échoué 16 tâche(s) ne sont pas épinglées
2.4.6 S'assurer que les étapes du pipeline produisent un SBOM Réussi
3.1.7 S'assurer que les dépendances sont épinglées à une version spécifique et vérifiée Échoué 16 dépendances ne sont pas épinglées
3.2.2 S'assurer que les packages sont automatiquement analysés pour les vulnérabilités connues Réussi
3.2.3 S'assurer que les packages sont automatiquement analysés pour les implications de licence Réussi
4.2.3 S'assurer que l'accès de l'utilisateur au registre de packages utilise l'MFA Réussi
4.2.5 S'assurer que l'accès anonyme aux artefacts est révoqué Réussi
4.3.4 S'assurer que les webhooks du registre de packages sont sécurisés Réussi
-------- ----------------------------------------------------------------------------------------------- -------- ---------------------------------------
Total des règles réussies : 19 sur 36
2022-06-13 15:22:31 INF Analyse terminée : 13.108s
Vous pouvez intégrer les résultats de chain-bench dans le Rapport de vulnérabilité Gitlab en ajoutant une nouvelle étape dans votre définition CI :
chain-bench-scanning:
stage: test
image:
name: docker.io/aquasec/chain-bench
entrypoint: [""]
script:
- chain-bench scan --repository-url $CI_PROJECT_URL --access-token $CHAIN_BENCH_TOKEN --scm-platform gitlab -o results.json --template @/templates/gitlab_security_scanner.tpl
artifacts:
reports:
container_scanning: results.json
Maintainer qui a les autorisations read_api et read_repository et l'utiliser comme variable d'environnement (par ex. $CHAIN_BENCH_TOKEN)Il est nécessaire de fournir un jeton d'accès avec les autorisations pour ces domaines : repo(tous), read:repo_hook, admin:org_hook, read:org
Nous supportons actuellement les SCM Github et Gitlab, avec une authentification PAT.
Chain-bench implémente le benchmark CIS Software Supply Chain aussi fidèlement que possible. Vous pouvez trouver les contrôles actuellement implémentés sous AVD - Software Supply Chain CIS - 1.0 qui se mettent à jour chaque nuit en fonction des fichiers metadata.json de chain-bench. Veuillez signaler les problèmes ici si chain-bench n'implémente pas correctement le test tel que décrit dans le benchmark. Pour signaler des problèmes dans le benchmark lui-même (par exemple, des tests que vous estimez inappropriés), veuillez rejoindre la communauté CIS.
Merci de lire Contribuer avant de contribuer. Nous accueillons favorablement les PR et les rapports de problèmes.
À l'avenir, nous prévoyons de publier des mises à jour de chain-bench pour augmenter la couverture du benchmark avec plus de contrôles et supporter plus de plateformes. Chain-bench est un projet open source d'Aqua Security faisant partie de la famille Trivy.