allstar
v4.2
Allstar est une application GitHub qui surveille en permanence les organisations ou les référentiels GitHub pour vérifier le respect des meilleures pratiques de sécurité. Si Allstar détecte une violation de la politique de sécurité, il crée un problème pour alerter le propriétaire du référentiel ou de l'organisation. Pour certaines politiques de sécurité, Allstar peut également modifier automatiquement le paramètre du projet à l'origine de la violation, le ramenant à l'état attendu.
L'objectif d'Allstar est de vous donner un contrôle précis sur les fichiers et les paramètres qui affectent la sécurité de vos projets. Vous pouvez choisir les stratégies de sécurité à surveiller au niveau de l'organisation et du référentiel, ainsi que la manière de gérer les violations de stratégie. Vous pouvez également développer ou contribuer à de nouvelles politiques.
Allstar est développé dans le cadre du projet OpenSSF Scorecard.
Si vous rencontrez des problèmes indésirables créés par Allstar, suivez ces instructions pour vous désinscrire.
Allstar est hautement configurable. Il existe trois principaux niveaux de contrôle :
Ces configurations sont effectuées dans le référentiel .allstar de l'organisation.
Niveau du référentiel : les responsables du référentiel dans une organisation qui utilise Allstar peuvent choisir d'inclure ou non leur référentiel dans les applications au niveau de l'organisation. Remarque : ces contrôles au niveau du dépôt ne sont fonctionnels que lorsque le « remplacement du dépôt » est autorisé dans les paramètres au niveau de l'organisation. Ces configurations se font dans le répertoire .allstar du référentiel.
Niveau de politique : les administrateurs ou les responsables peuvent choisir quelles politiques sont activées sur des dépôts spécifiques et quelles actions Allstar entreprend lorsqu'une politique est violée. Ces configurations sont effectuées dans un fichier yaml de stratégie dans le référentiel .allstar de l'organisation (administrateurs) ou dans le répertoire .allstar du référentiel (mainteneurs).
Avant d'installer Allstar au niveau de l'organisation, vous devez décider approximativement sur combien de référentiels vous souhaitez qu'Allstar s'exécute. Cela vous aidera à choisir entre les stratégies Opt-In et Opt-Out.
La stratégie Opt In vous permet d'ajouter manuellement les référentiels sur lesquels vous souhaitez qu'Allstar s'exécute. Si vous ne spécifiez aucun référentiel, Allstar ne fonctionnera pas malgré son installation. Choisissez la stratégie Opt In si vous souhaitez appliquer des politiques sur un petit nombre seulement de vos référentiels totaux, ou si vous souhaitez essayer Allstar sur un seul référentiel avant de l'activer sur davantage. Depuis la version v4.3, les globs sont pris en charge pour ajouter facilement plusieurs référentiels portant un nom similaire.
La stratégie de désinscription (recommandée) active Allstar sur tous les référentiels et vous permet de sélectionner manuellement les référentiels pour lesquels vous souhaitez vous désinscrire des applications Allstar. Vous pouvez également choisir de désactiver tous les dépôts publics ou tous les dépôts privés. Choisissez cette option si vous souhaitez exécuter Allstar sur tous les référentiels d'une organisation, ou si vous souhaitez désactiver uniquement un petit nombre de référentiels ou un type spécifique (c'est-à-dire public ou privé) de référentiel. Depuis la version v4.3, les globs sont pris en charge pour ajouter facilement plusieurs référentiels portant un nom similaire.
| Se désinscrire (recommandé) optOutStrategy = vrai | S'inscrire optOutStrategy = faux | |
|---|---|---|
| Comportement par défaut | Tous les dépôts sont activés | Aucun dépôt n'est activé |
| Ajout manuel de référentiels | L'ajout manuel de dépôts désactive Allstar sur ces dépôts | L'ajout manuel de dépôts active Allstar sur ces dépôts |
| Configurations supplémentaires | optOutRepos : Allstar sera désactivé sur les dépôts répertoriés optOutPrivateRepos : si vrai, Allstar sera désactivé sur tous les dépôts privés optOutPublicRepos : si vrai, Allstar sera désactivé sur tous les dépôts publics (optInRepos : ce paramètre sera ignoré) | optInRepos : Allstar sera activé sur les dépôts répertoriés (optOutRepos : ce paramètre sera ignoré) |
| Remplacement du dépôt | Si c'est vrai : les dépôts peuvent se désinscrire des applications Allstar de leur organisation en utilisant les paramètres de leur propre fichier de dépôt. Les paramètres d'adhésion au niveau de l'organisation qui s'appliquent à ce référentiel sont ignorés. Si faux : les dépôts ne peuvent pas se désinscrire des applications Allstar telles que configurées au niveau de l'organisation. | Si c'est vrai : les dépôts peuvent adhérer aux applications Allstar de leur organisation même s'ils ne sont pas configurés pour le dépôt au niveau de l'organisation. Les paramètres de désinscription au niveau de l’organisation qui s’appliquent à ce référentiel sont ignorés. Si faux : les dépôts ne peuvent pas adhérer aux applications Allstar si elles ne sont pas configurées au niveau de l'organisation. |
Les options de démarrage rapide et d'installation manuelle impliquent l'installation de l'application Allstar. Vous pouvez consulter les autorisations demandées. L'application demande un accès en lecture à la plupart des paramètres et du contenu des fichiers pour détecter la conformité en matière de sécurité. Il demande un accès en écriture aux problèmes et vérifie afin de pouvoir créer des problèmes et autoriser l'action block .
Cette option d'installation permettra à Allstar d'utiliser la stratégie de désinscription sur tous les référentiels de votre organisation. Toutes les politiques actuelles seront activées et Allstar vous alertera des violations des politiques en déposant un problème. Il s'agit du moyen le plus rapide et le plus simple de commencer à utiliser Allstar, et vous pourrez toujours modifier les configurations ultérieurement.
Effort : très facile
Mesures:
.allstarC'est ça! Toutes les politiques Allstar actuelles sont désormais activées sur tous vos référentiels. Allstar créera un problème si une politique est violée.
Pour modifier des configurations, consultez les instructions d'installation manuelle.
Cette option d'installation vous guidera dans la création de fichiers de configuration selon la stratégie Opt In ou Opt Out. Cette option offre un contrôle plus granulaire sur les configurations dès le départ.
Effort : modéré
Mesures:
Chaque politique peut être configurée avec une action qu'Allstar entreprendra lorsqu'il détectera qu'un référentiel n'est pas conforme.
log : Il s'agit de l'action par défaut et a réellement lieu pour toutes les actions. Tous les résultats et détails de l’exécution de la stratégie sont enregistrés. Les journaux ne sont actuellement visibles que par l'opérateur de l'application, des projets de les exposer sont en discussion.issue : cette action crée un problème GitHub. Un seul problème est créé par stratégie et le texte décrit les détails de la violation de la stratégie. Si le problème est déjà ouvert, il reçoit un commentaire toutes les 24 heures sans mises à jour (actuellement non configurable par l'utilisateur). Si le résultat de la politique change, un nouveau commentaire sera laissé sur le problème et lié dans le corps du problème. Une fois la violation résolue, le problème sera automatiquement résolu par Allstar dans un délai de 5 à 10 minutes.fix : cette action est spécifique à la stratégie. La stratégie apportera les modifications aux paramètres GitHub pour corriger la violation de la stratégie. Toutes les politiques ne seront pas en mesure de prendre en charge cela (voir ci-dessous).Actions proposées, mais pas encore mises en œuvre. Des définitions seront ajoutées ultérieurement.
block : Allstar peut définir une vérification de l'état de GitHub et empêcher la fusion de tout PR du référentiel si la vérification échoue.email : Allstar enverrait un e-mail au(x) administrateur(s) du référentiel.rpc : Allstar enverrait un rpc à un système spécifique à l'organisation.Deux paramètres sont disponibles pour configurer l'action de problème :
issueLabel est disponible au niveau de l’organisation et du référentiel. Sa configuration remplacera l'étiquette allstar par défaut utilisée par Allstar pour identifier ses problèmes.
issueRepo est disponible au niveau de l’organisation. Le définir forcera tous les problèmes créés dans l’organisation à être créés dans le référentiel spécifié.
Semblable à la configuration d'activation de l'application Allstar, toutes les stratégies sont activées et configurées avec un fichier yaml dans le référentiel .allstar de l'organisation ou dans le répertoire .allstar du référentiel. Comme pour l'application, les politiques sont facultatives par défaut et l'action log par défaut ne produira pas de résultats visibles. Un moyen simple d'activer toutes les stratégies consiste à créer un fichier yaml pour chaque stratégie avec le contenu :
optConfig:
optOutStrategy: true
action: issue
Les détails du fonctionnement de l’action fix pour chaque stratégie sont détaillés ci-dessous. Si elle est omise ci-dessous, l'action fix n'est pas applicable.
Le fichier de configuration de cette stratégie est nommé branch_protection.yaml et les définitions de configuration se trouvent ici.
La stratégie de protection des branches vérifie que les paramètres de protection des branches de GitHub sont correctement configurés selon la configuration spécifiée. Le texte du problème décrira quel paramètre est incorrect. Consultez la documentation de GitHub pour corriger les paramètres.
L'action fix modifiera les paramètres de protection des branches pour les rendre conformes à la configuration de stratégie spécifiée.
Le fichier de configuration de cette stratégie est nommé binary_artifacts.yaml et les définitions de configuration se trouvent ici.
Cette politique intègre la vérification de la carte de pointage. Supprimez l'artefact binaire du référentiel pour assurer la conformité. Comme les résultats du scorecard peuvent être détaillés, vous devrez peut-être exécuter le scorecard lui-même pour voir toutes les informations détaillées.
Le fichier de configuration de cette stratégie est nommé codeowners.yaml et les définitions de configuration se trouvent ici.
Cette politique vérifie la présence d'un fichier CODEOWNERS sur vos référentiels.
Le fichier de configuration de cette stratégie est nommé outside.yaml et les définitions de configuration se trouvent ici.
Cette stratégie vérifie si des collaborateurs externes disposent d'un accès administrateur (par défaut) ou push (facultatif) au référentiel. Seuls les membres de l'organisation doivent avoir cet accès, car autrement, des membres non fiables peuvent modifier les paramètres de niveau administrateur et commettre du code malveillant.
Le fichier de configuration de cette stratégie est nommé security.yaml et les définitions de configuration se trouvent ici.
Cette politique vérifie que le référentiel dispose d'un fichier de politique de sécurité dans SECURITY.md et qu'il n'est pas vide. Le problème créé aura un lien vers l'onglet GitHub qui vous aide à valider une politique de sécurité dans votre référentiel.
Le fichier de configuration de cette stratégie est nommé dangerous_workflow.yaml et les définitions de configuration se trouvent ici.
Cette stratégie vérifie les fichiers de configuration du workflow GitHub Actions ( .github/workflows ) pour détecter tout modèle correspondant à un comportement dangereux connu. Consultez la documentation OpenSSF Scorecard pour plus d'informations sur cette vérification.
Le fichier de configuration de cette stratégie est nommé scorecard.yaml et les définitions de configuration se trouvent ici.
Cette stratégie exécute n’importe quelle vérification de carte de score répertoriée dans la configuration checks . Tous les contrôles effectués doivent avoir un score égal ou supérieur au threshold défini. Veuillez consulter la documentation OpenSSF Scorecard pour plus d'informations sur chaque vérification.
Le fichier de configuration de cette stratégie est nommé actions.yaml et les définitions de configuration se trouvent ici.
Cette stratégie vérifie les fichiers de configuration du workflow GitHub Actions ( .github/workflows ) (et le workflow s'exécute dans certains cas) dans chaque dépôt pour garantir qu'ils sont conformes aux règles (par exemple exiger, refuser) définies dans la configuration au niveau de l'organisation pour le politique.
Le fichier de configuration de cette stratégie est nommé admin.yaml et les définitions de configuration se trouvent ici.
Cette stratégie vérifie que par défaut tous les référentiels doivent avoir un utilisateur ou un groupe affecté en tant qu'administrateur. Il vous permet éventuellement de configurer si les utilisateurs sont autorisés à être administrateurs (par opposition aux équipes).
Voir ce dépôt comme exemple de configuration Allstar utilisée. En tant qu'administrateur de l'organisation, envisagez un fichier README.md contenant des informations sur la manière dont Allstar est utilisé dans votre organisation.
Par défaut, les fichiers de configuration au niveau de l'organisation, tels que le fichier allstar.yaml ci-dessus, devraient se trouver dans un référentiel .allstar . Si ce référentiel n'existe pas, le répertoire allstar du référentiel .github est utilisé comme emplacement secondaire. Pour clarifier, pour allstar.yaml :
| Priorité | Dépôt | Chemin |
|---|---|---|
| Primaire | .allstar | allstar.yaml |
| Secondaire | .github | allstar/allstar.yaml |
Cela s'applique également aux fichiers de configuration au niveau de l'organisation pour les stratégies individuelles, comme décrit ci-dessous.
Allstar recherchera également les configurations de politique au niveau du dépôt dans le référentiel .allstar de l'organisation, sous le répertoire portant le même nom que le référentiel. Cette configuration est utilisée même si le "repo override" est désactivé.
Par exemple, Allstar recherchera la configuration de la politique pour un dépôt myapp donné dans l'ordre suivant :
| Dépôt | Chemin | Condition |
|---|---|---|
myapp | .allstar/branch_protection.yaml | Lorsque le "repo override" est autorisé. |
.allstar | myapp/branch_protection.yaml | À tout moment. |
.allstar | branch_protection.yaml | À tout moment. |
.github | allstar/myapp/branch_protection.yaml | Si le dépôt .allstar n’existe pas. |
.github | allstar/branch_protection.yaml | Si le dépôt .allstar n’existe pas. |
Pour les fichiers de configuration Allstar et de stratégie au niveau de l'organisation, vous pouvez spécifier le champ baseConfig pour spécifier un autre référentiel contenant la configuration de base Allstar. Ceci est mieux expliqué avec un exemple.
Supposons que vous ayez plusieurs organisations GitHub, mais que vous souhaitiez conserver une seule configuration Allstar. Votre organisation principale est "acme", et le référentiel acme/.allstar contient allstar.yaml :
optConfig :
optOutStrategy : true
issueLabel : allstar-acme
issueFooter : Issue created by Acme security team. Vous disposez également d’une organisation GitHub satellite nommée « acme-sat ». Vous souhaitez réutiliser la configuration principale, mais appliquer quelques modifications par dessus en désactivant Allstar sur certains référentiels. Le référentiel acme-sat/.allstar contient allstar.yaml :
baseConfig : acme/.allstar
optConfig :
optOutRepos :
- acmesat-one
- acmesat-two Cela utilisera toute la configuration d' acme/.allstar comme configuration de base, mais appliquera ensuite toutes les modifications apportées au fichier actuel au-dessus de la configuration de base. La méthode appliquée est décrite comme un correctif de fusion JSON. Le baseConfig doit être un GitHub <org>/<repository> .
Voir CONTRIBUTION.md
