legitify

Legit Security est une solution de gestion de la posture de sécurité des applications (ASPM) et de sécurité de la chaîne d'approvisionnement logicielle.
Pour plus d'informations, consultez le tableau comparatif

https://user-images.githubusercontent.com/107790206/210602039-2d022692-87ea-4005-b9c6-f091158de3ce.mov

Installation

L'installation est possible de plusieurs manières :

• Pour macOS (ou Linux) via homebrew :

• Vous pouvez télécharger la dernière version de legitify depuis https://github.com/Legit-Labs/legitify/releases, chaque archive contient :

  • Le binaire legitify pour la plateforme souhaitée
  • Politiques intégrées fournies par Legit Security

• Depuis les sources avec les étapes suivantes :

• En tant qu'extension GitHub CLI (consultez https://github.com/Legit-Labs/gh-legitify pour plus d'informations)

CI - Action GitHub personnalisée Legitify

Vous pouvez exécuter legitify dans le cadre d'un processus CI avec les actions GitHub personnalisées de legitify :

Consultez le fichier d'action pour les paramètres et la configuration supplémentaires.

Provenance

Pour renforcer la sécurité de la chaîne d'approvisionnement logicielle des utilisateurs de legitify, à partir de la version v0.1.6, chaque version de legitify contient un document de Provenance SLSA Niveau 3.
Le document de provenance fait référence à tous les artefacts de la version, ainsi qu'à l'image Docker générée.
Vous pouvez utiliser le vérificateur officiel du framework SLSA pour vérifier la provenance.
Exemple d'utilisation pour l'architecture darwin_arm64 pour la version v0.1.6 :

Commandes

analyzer

Par défaut, legitify vérifiera les politiques par rapport à toutes vos ressources (organisations, dépôts, membres, actions). Les dépôts archivés sont ignorés.

Vous pouvez contrôler les ressources qui seront analysées avec les indicateurs en ligne de commande namespace et org :

• --namespace (-n) : analysera les politiques relatives aux ressources spécifiées
• --org : limitera l'analyse aux organisations GitHub ou au groupe GitLab spécifiés, en excluant les dépôts archivés
• --repo : limitera l'analyse aux dépôts GitHub ou aux projets GitLab spécifiés
• --scm : spécifier la plateforme de gestion de code source. Les valeurs possibles sont : github ou gitlab. Par défaut : github. Veuillez noter : lors de l'exécution sur GitLab, --scm gitlab est requis.
• --enterprise : spécifier les entreprises qui doivent être analysées. Veuillez noter : pour analyser une entreprise, un slug d'entreprise doit être fourni.

La commande ci-dessus testera les politiques d'organisation et de membre pour org1 et org2.

analyse-gpt

Analyse basée sur GPT-3 de la posture de sécurité du dépôt ou de l'organisation fournis.

REMARQUE : Les métadonnées du dépôt/de l'organisation sont envoyées aux serveurs d'OpenAI.

Indicateurs :

• --org : limitera l'analyse aux organisations GitHub ou au groupe GitLab spécifiés
• --repo : limitera l'analyse aux dépôts GitHub ou aux projets GitLab spécifiés
• --scm : spécifier la plateforme de gestion de code source. Les valeurs possibles sont : github ou gitlab. Par défaut : github.
• --token : jeton pour le SCM (ou définir la variable d'environnement SCM_TOKEN)
• --openai-token : jeton pour l'API OpenAI (ou définir la variable d'environnement OPENAI_TOKEN)

Vous devez fournir soit --org, soit --repo, ou les deux.

Génération du jeton OpenAI :

1. Allez sur https://beta.openai.com/signup et créez un compte OpenAI
2. Sous https://platform.openai.com/account/api-keys, appuyez sur "Create new secret key"

Utilisation de l'action GitHub

Vous pouvez également exécuter legitify en tant qu'action GitHub dans vos workflows, consultez le répertoire action_examples pour des exemples concrets.

Prérequis

GitHub (Cloud et Enterprise Server)

1. Pour tirer le meilleur parti de legitify, vous devez être propriétaire d'au moins une organisation GitHub. Sinon, vous pouvez toujours utiliser l'outil si vous êtes administrateur d'au moins un dépôt au sein d'une organisation, auquel cas vous ne pourrez voir que les résultats des politiques liées au dépôt.
2. legitify nécessite un jeton d'accès personnel GitHub (PAT) pour analyser vos ressources avec succès, qui peut être fourni soit comme argument (-t) soit comme variable d'environnement (SCM_TOKEN). Le PAT nécessite les portées suivantes pour une analyse complète :

Voir Création d'un jeton d'accès personnel pour plus d'informations.
Les jetons d'accès personnels à granularité fine ne sont actuellement pas pris en charge.

GitHub Enterprise Server

Vous pouvez exécuter legitify contre une instance GitHub Enterprise Server si vous définissez l'URL du point de terminaison dans la variable d'environnement SERVER_URL :

GitLab Cloud/Server

1. Comme mentionné dans la section précédente, vous devez être propriétaire d'au moins un groupe GitLab. Sinon, vous pouvez toujours utiliser l'outil si vous êtes administrateur d'au moins un projet au sein d'un groupe, auquel cas vous ne pourrez voir que les résultats des politiques liées au projet.
2. legitify nécessite un jeton d'accès personnel GitLab (PAT) pour analyser vos ressources avec succès, qui peut être fourni soit comme argument (-t) soit comme variable d'environnement (SCM_TOKEN). Le PAT nécessite les portées suivantes pour une analyse complète : read_api, read_user, read_repository, read_registry Voir Création d'un jeton d'accès personnel pour plus d'informations.
   Pour exécuter legitify contre GitLab Cloud, définissez l'indicateur scm sur gitlab --scm gitlab, pour exécuter contre GitLab Server, vous devez également fournir une SERVER_URL :

NOTE 1 : Pour ignorer un certificat serveur invalide, veuillez passer l'indicateur ignore-invalid-certificate

NOTE 2 : Pour les comptes GitLab non premium, certaines politiques (telles que les politiques de protection de branche) seront ignorées

Espaces de noms

Les espaces de noms dans legitify sont des ressources qui sont collectées et évaluées par rapport aux politiques. Actuellement, les espaces de noms suivants sont pris en charge :

1. organization - Politiques au niveau de l'organisation GitHub (ou du groupe GitLab) (par exemple, "L'authentification à deux facteurs n'est pas appliquée à l'organisation")
2. actions - Politiques GitHub Actions de l'organisation (par exemple, "Les exécutions GitHub Actions ne sont pas limitées aux actions vérifiées")
3. member - Politiques au niveau du contributeur (par exemple, "Administrateur inactif trouvé")
4. repository - Politiques au niveau du dépôt GitHub (ou du projet GitLab) (par exemple, "La revue de code par au moins deux relecteurs n'est pas appliquée"). Remarque : Les dépôts archivés sont ignorés sauf s'ils sont spécifiés directement via l'argument --repo.
5. runner_group - Politiques de groupe de runners (par exemple, "le runner peut être utilisé par des dépôts publics")

Par défaut, legitify analysera tous les espaces de noms. Vous pouvez limiter l'analyse à certains seulement avec l'indicateur --namespace, suivi d'une liste séparée par des virgules des espaces de noms sélectionnés.

Options de sortie

Par défaut, legitify affiche les résultats dans un format lisible par un humain. Cela inclut la liste des violations de politique classées par sévérité, ainsi qu'un tableau récapitulatif trié par espace de noms.

Formats de sortie

En utilisant l'indicateur --output-format (-f), legitify prend en charge l'affichage des résultats dans les formats suivants :

1. human-readable - Texte lisible par un humain (par défaut).
2. json - JSON standard.
3. sarif - Format SARIF (info).

Schémas de sortie

En utilisant l'indicateur --output-scheme, legitify prend en charge l'affichage des résultats selon différents schémas de regroupement. Remarque : --output-format=json doit être spécifié pour afficher des schémas non par défaut.

1. flattened - Aucun regroupement ; une liste plate des politiques, chacune avec ses violations (par défaut).
2. group-by-namespace - Regroupe les politiques par leur espace de noms.
3. group-by-resource - Regroupe les politiques par leur ressource, par exemple organisation/dépôt spécifique.
4. group-by-severity - Regroupe les politiques par leur sévérité.

Destinations de sortie

• --output-file - chemin complet du fichier de sortie (par défaut : pas de fichier de sortie, affiche sur stdout).
• --error-file - chemin complet des journaux d'erreur (par défaut : ./error.log).

Coloration

Lors de l'affichage dans un format lisible par un humain, legitify prend en charge l'indicateur conventionnel --color[=when], qui a les options suivantes :

• auto - sortie colorée si stdout est un terminal, non colorée sinon (par défaut).
• always - sortie colorée quelle que soit la destination de sortie.
• none - sortie non colorée quelle que soit la destination de sortie.

Divers

• Utilisez l'indicateur --failed-only pour filtrer les vérifications réussies/ignorées du résultat.
• Utilisez --ignore-policies-path $CHEMIN et fournissez un fichier avec les politiques que vous souhaitez ignorer pour ignorer des politiques spécifiques. Une politique par ligne, par exemple : no_conversation_resolution requires_status_checks

Support Scorecard - Uniquement pour les dépôts GitHub serveur/cloud

Scorecard est un projet open-source de l'OSSF :

Scorecards est un outil automatisé qui évalue un certain nombre d'heuristiques importantes ("vérifications") associées à la sécurité logicielle et attribue à chaque vérification un score de 0 à 10. Vous pouvez utiliser ces scores pour comprendre les domaines spécifiques à améliorer afin de renforcer la posture de sécurité de votre projet. Vous pouvez également évaluer les risques que les dépendances introduisent et prendre des décisions éclairées quant à l'acceptation de ces risques, à l'évaluation de solutions alternatives ou à la collaboration avec les mainteneurs pour apporter des améliorations.

legitify prend en charge l'exécution de Scorecard pour tous les dépôts de l'organisation, en appliquant des politiques de score et en affichant les résultats à l'aide de l'indicateur --scorecard :

• no - n'exécute pas Scorecard (par défaut).
• yes - exécute Scorecard et utilise une politique qui alerte sur chaque score de dépôt inférieur à 7,0.
• verbose - exécute Scorecard, utilise une politique qui alerte sur chaque score de dépôt inférieur à 7,0, et intègre sa sortie à celle de legitify.

legitify exécute les vérifications Scorecard suivantes :

Politiques

legitify est livré avec un ensemble de politiques pour chaque SCM dans le répertoire policies/. Ces politiques sont documentées ici.

Contribution

Merci d'envisager de contribuer à Legitify ! Nous encourageons et apprécions tout type de contribution. Voici quelques ressources pour vous aider à démarrer :

• Guide de contribution
• Code de conduite
• Ouvrir un problème
• Ouvrir une demande de tirage

Support

Si vous avez des questions sur legitify ou si vous avez besoin d'aide pour son fonctionnement, n'hésitez pas à nous contacter. Notre équipe s'engage à fournir une assistance et à garantir une expérience fluide.

Legitify vs la plateforme Legit Security

Si vous avez aimé Legitify, vous allez adorer la plateforme Legit Security !

• Elle automatise les vérifications de Legitify pour l'ensemble des environnements, découvre plus de systèmes et affiche tous les résultats dans une application web simple à gérer à grande échelle.
• Legit Security est une solution complète de sécurité CI/CD ainsi qu'une solution de gestion de la posture de sécurité des applications (ASPM) qui couvre la sécurité des applications de bout en bout.
• Il s'agit d'une plateforme SaaS, conçue pour les équipes d'ingénierie, DevOps et sécurité, et approuvée par de nombreuses organisations leaders dans le monde.

Voici un tableau comparatif entre Legitify et Legit :

Pour découvrir Legit, visitez notre site web ou réservez une démo directement.