Planification d’un essai de GitHub Advanced Security

Un essai en libre-service vous convient-il ?

Cet article s’adresse aux organisations qui souhaitent commencer un essai de GitHub Advanced Security de manière indépendante, sans l’aide d’un expert ou d’un partenaire. En règle générale, cela signifie que vous êtes une petite ou moyenne organisation.

Cet article vous aide à planifier un essai en libre-service de GitHub Advanced Security. Un essai en libre-service vous convient si les deux conditions suivantes sont remplies :

• Vous souhaitez réaliser votre essai de manière indépendante, sans l’aide d’un expert ou d’un partenaire. En règle générale, cela fonctionne mieux pour les petites ou moyennes organisations.
• Vous êtes déjà client de GitHub Enterprise Cloud et vous payez par carte de crédit ou PayPal.

Sinon, contactez-nous pour obtenir de l’aide concernant votre essai.

• Si vous souhaitez bénéficier de l’aide d’un expert : Contactez notre équipe.
• Si vous payez par facture : contactez votre représentant commercial.

1. Définir les objectifs de l'entreprise

Avant de commencer un essai, vous devez définir l’objectif de l’essai et identifier les questions clés auxquelles vous devez répondre. En vous concentrant sur ces objectifs, vous pourrez planifier un procès qui maximisera la découverte et vous permettra de disposer des informations nécessaires pour décider d'un éventuel reclassement.

Si votre entreprise utilise déjà GitHub, réfléchissez aux besoins non satisfaits auxquels Secret Protection or Code Security pourrait répondre. Vous devez également tenir compte de votre position actuelle en matière de sécurité des applications et de vos objectifs à long terme. Pour vous inspirer, consultez les principes de conception de la sécurité des applications dans la documentation GitHub bien architecturée.

Si votre entreprise n'utilise pas encore GitHub, vous aurez probablement des questions supplémentaires, notamment sur la manière dont la plateforme gère la résidence des données, la gestion sécurisée des comptes et la migration des référentiels. Pour plus d’informations, consultez « Bien démarrer avec GitHub Enterprise Cloud ».

2. Identifiez les membres de votre équipe de jugement

GitHub Advanced Security vous permet d'intégrer des mesures de sécurité tout au long du cycle de développement du logiciel, il est donc important de s'assurer que vous incluez des représentants de tous les domaines de votre cycle de développement. Sinon, vous risquez de prendre une décision sans disposer de toutes les données nécessaires. Un essai comprend 50 licences, ce qui permet à un large éventail de personnes d’être représentées.

Vous pouvez également trouver utile d’identifier un champion pour chaque entreprise dont vous souhaitez enquêter.

3. Déterminez si des recherches préliminaires sont nécessaires

Avant de commencer votre essai, déterminez si votre équipe pourrait bénéficier d’une expérience pratique avec nos fonctionnalités de sécurité gratuites. Tester l’analyse de code et l’analyse de secrets sur des référentiels publics peut aider les nouveaux utilisateurs à se familiariser avec les fonctionnalités principales de GitHub Advanced Security. Cela vous permettra de concentrer votre période d’essai sur les référentiels privés et les fonctionnalités et contrôles avancés disponibles dans Secret Protection and Code Security.

Pour plus d’informations, consultez l’article suivant :

• Activation de l’analyse des secrets pour votre référentiel
• Définition de la configuration par défaut pour l’analyse du code
• Configuration du graphe de dépendances

Les organisations utilisant GitHub Team et GitHub Enterprise peuvent générer un rapport gratuit pour analyser leur code à la recherche d’analyses de secrets. Cela vous aide à évaluer l’exposition actuelle de vos référentiels aux fuites de secrets et vous montre combien de fuites existantes auraient pu être évitées par Secret Protection. Consultez À propos de l’évaluation des risques liés aux secrets.

4. Décider quelles organisations et quels référentiels tester

Il est généralement préférable de commencer votre essai avec une organisation existante. Cela vous permet de découvrir les fonctionnalités dans des référentiels que vous connaissez bien et dans un environnement de codage familier.

Si vous le souhaitez, vous pouvez ajouter des organisations ou du code de test ultérieurement. Cependant, sachez que les applications délibérément non sécurisées, telles que WebGoat, ne sont pas les meilleures pour effectuer des tests. Elles peuvent contenir des modèles de codage qui semblent non sécurisés, mais que code scanning détermine comme ne pouvant être exploités. Par conséquent, code scanning peut signaler moins de problèmes dans ces codebases artificiels que d’autres analyseurs de sécurité.

5. Définir les critères d'évaluation de l'essai

Pour chaque besoin ou objectif de l’entreprise que vous définissez pour l’essai, décidez comment vous allez mesurer le succès. Par exemple, si vous souhaitez imposer l’utilisation de fonctionnalités de sécurité, créez des cas de test pour les configurations et les politiques de sécurité afin de confirmer qu’elles fonctionnent comme prévu.

6. Commencer votre essai

Si vous utilisez déjà GitHub Enterprise Cloud (en tant que client payant ou dans le cadre d’un essai gratuit), consultez Configuration d’un essai de GitHub Advanced Security.

Sinon, vous pouvez essayer GitHub Advanced Security dans le cadre d’un essai de GitHub Enterprise Cloud. Consultez Configuration d’un essai de GitHub Enterprise Cloud dans la documentation GitHub Enterprise Cloud.