Accès aux paramètres des jeux de règles

1. Accédez à l'onglet Paramètres de votre référentiel sur GitHub.
2. Dans la barre latérale gauche, sous Règles, cliquez sur Jeux de règles pour accéder à la page de configuration des jeux de règles.
3. Cliquez sur le bouton vert Nouvel ensemble RuleSet de branche
4. Ajoutez les informations nécessaires pour définir le jeu de règles et cliquez sur Créer.

Ajout de règles de protection dans les ensembles de règles

En cliquant sur le bouton vert New Branch RuleSet, une page s'affiche pour compléter les détails de l'ensemble de règles.

1. Nommez votre RuleSet et activez/désactivez/évaluez l'ensemble de règles en sélectionnant dans le menu déroulant le statut de l'activation

2. Configurez les branches cibles en cliquant sur Ajouter une cible. Sélectionnez Inclure**, Exclure****, Défaut** ou Tous pour configurer les critères de ciblage de la branche. GitHub prend en charge la syntaxe fnmatch pour le ciblage basé sur des motifs.

3. Configurez les autorisations de contournement dans la liste des contournements en cliquant sur Ajouter un contournement. Vous pouvez ajouter les rôles requis qui peuvent contourner les contrôles. Vous pouvez laisser la liste vide (ce qui équivaut à activer l'option Ne pas autoriser le contournement de ces paramètres dans les paramètres traditionnels de protection de la branche).

4. Activez l'option Require a pull request before merging sous Branch rules.

5. Activez l'option Exiger des approbations et définissez l'option Nombre requis d'approbations avant la fusion sur au moins 1 ou le nombre d'approbations requises dans votre équipe.

6. Activez l'option Ignorer les approbations des demandes d'extraction périmées lorsque de nouvelles validations sont envoyées par commande push pour examiner toutes les modifications les plus récentes avant qu'elles ne puissent être fusionnées dans une autre branche.

Limitation

Actuellement, la liste des acteurs du contournement ne peut être récupérée qu'à partir des ensembles de règles au niveau du référentiel. Si un ensemble de règles est défini au niveau de l'organisation, ces informations ne peuvent pas être extraites de ces ensembles de règles, en vertu des autorisations standard.

Pour récupérer la liste des acteurs du contournement à partir des jeux de règles au niveau de l'organisation, veuillez examiner les accès requis et accorder au compte Functional ID/GitHub qui exécute le pipeline des privilèges élevés (accès de propriétaire à l'organisation ). Cela est dû au modèle d'autorisation GitHub's, qui restreint la visibilité des métadonnées des acteurs de contournement des règles au niveau de l'organisation sans autorisation appropriée pour empêcher la fuite d'informations sensibles.

Pour plus d'informations, consultez la documentation officielle de GitHub sur les jeux de règles d'organisation et les acteurs de contournement.

Configuration des contrôles d'état pour les jeux de règles

1. Activez l'option Require status checks to pass before merging.

Pour pouvoir les définir comme des vérifications de statut requises, vous devez d'abord déclencher un pipeline PR/CI au préalable (seules les vérifications de statut existantes sont répertoriées dans l'interface utilisateur).

Après avoir activé l'option Require status checks to pass before merging, vous devez configurer les vérifications de statut spécifiques qui doivent être effectuées avant de fusionner une demande d'extraction.

2. Dans la liste des vérifications de statut disponibles, activez les options suivantes pour les vérifications:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

Ces vérifications sont les vérifications par défaut de l'état des demandes d'extraction dans le pipeline.

Ajout de tous les jeux de règles par défaut (configuration complète)

Cette commande CURL définit à la fois les vérifications d'état requises par défaut et les paramètres de révision des demandes d'extraction.

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/rulesets" \
    -XPUT -d '{
  "name": "Branch Protection Equivalent Ruleset",
  "target": "branch",
  "enforcement": "active",
  "bypass_actors": [], // as the list is empty no one can bypass which is equivalent to enforce_admins: true with no restriction
  "conditions": {
    "ref_name": {
      "include": ["refs/heads/master"],
      "exclude": []
    }
  },
  "rules": [
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [
          {
            "context": "tekton/code-unit-tests"
          },
          {
            "context": "tekton/code-branch-protection"
          },
          {
            "context": "tekton/code-cis-check"
          },
          {
            "context": "tekton/code-vulnerability-scan"
          },
          {
            "context": "tekton/code-detect-secrets"
          }
        ]
      }
    },
    {
      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": false,
        "require_last_push_approval": false,
        "required_review_thread_resolution": false
      }
    }
  ]
}'

Accès aux paramètres de protection de branche

1. Accédez à l'onglet Paramètres de votre référentiel sur GitHub.
2. Dans la barre latérale de gauche, cliquez sur Branches pour accéder à la page des paramètres de la branche.
3. Faites défiler l'écran jusqu'à la section Règles de protection des branches.
4. Localisez la branche que vous souhaitez configurer (généralement la branche "main").
5. Sélectionnez le bouton Editer en regard du nom de la branche pour modifier ses règles de protection.

Ajout de règles de protection de branche

Si aucune règle existante n'est configurée, cliquez sur le bouton Ajouter une règle et entrez le nom de la branche correspondante dans la zone **Branch name pattern**. Procédez ensuite aux étapes suivantes :

1. Activez l'option Exiger une demande d'extraction avant la fusion.
2. Activez l'option Exiger des approbations et définissez l'option Nombre requis d'approbations avant la fusion sur au moins 1 ou le nombre d'approbations requises dans votre équipe.
3. Activez l'option Ignorer les approbations des demandes d'extraction périmées lorsque de nouvelles validations sont envoyées par commande push pour examiner toutes les modifications les plus récentes avant qu'elles ne puissent être fusionnées dans une autre branche.

4. Activez l'option Ne pas autoriser le contournement des paramètres pour empêcher les administrateurs et les rôles personnalisés disposant de l'autorisation de contourner les protections de branche de contourner les contrôles de protection de branche requis.

Actuellement, les avertissements sont affichés dans les journaux si la vérification de Do not allow bypassing these settings n'est pas activée. Il n'échouera pas au contrôle de la protection des branches tant que ce contrôle ne sera pas rendu obligatoire d'ici à la mi-mars. Veuillez activer le contrôle d'ici la mi-mars afin d'éviter toute défaillance du pipeline.

Les demandes d'extraction doivent être approuvées avant de les fusionner dans la branche maître. Cette règle garantit que les modifications sont examinées et examinées par les membres de l'équipe, favorise la collaboration, la qualité du code et le respect des normes du projet.

Configuration des vérifications de statut

Des contrôles de statut sont requis dansDevSecOps pour appliquer un ensemble complet de mesures de qualité et de sécurité sur le code. Ainsi, les changements de code sont sûrs et fiables avant d'être fusionnés dans une branche protégée. En exigeant que les vérifications de statut soient effectuées avant la fusion, vous pouvez empêcher le code endommagé ou non testé d'être déployé en production.

Lorsqu'une demande d'extraction est soumise, le pipeline PR/CI déclenche automatiquement une série de tests, de validations et d'autres vérifications pour vérifier les modifications proposées.

Ce n'est que lorsque toutes les vérifications de statut requises auront abouti que la demande d'extraction sera considérée comme éligible pour la fusion dans la branche protégée.

En tirant parti des contrôles de statut au seinDevSecOps, vous pouvez maintenir la qualité du code, adhérer aux normes de codage et garantir l'absence de vulnérabilités ou de défauts critiques avant d'incorporer des modifications dans la branche protégée de votre projet.

Pour plus d'informations sur la configuration des vérifications de statut, voir la section Configuration des vérifications de statut uniquement(Configuration des vérifications de statut) pour une implémentation de référence.

1. Activez l'option Require status checks to pass before merging.

Pour pouvoir les définir comme des vérifications de statut requises, vous devez d'abord déclencher un pipeline PR/CI au préalable (seules les vérifications de statut existantes sont répertoriées dans l'interface utilisateur).

Après avoir activé l'option Require status checks to pass before merging, vous devez configurer les vérifications de statut spécifiques qui doivent être effectuées avant de fusionner une demande d'extraction.

2. Dans la liste des vérifications de statut disponibles, activez les options suivantes pour les vérifications:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

Les vérifications de statut affichées doivent être effectuées avant la fusion d'une demande d'extraction.

Ces vérifications sont les vérifications par défaut de l'état des demandes d'extraction dans le pipeline.

[{
  "type": "branch-protection",
  "name": "code-review",
  "params": {
    "checks": [
      "tekton/code-branch-protection",
      "tekton/code-unit-tests",
      "tekton/code-cis-check",
      "tekton/code-vulnerability-scan",
      "tekton/code-detect-secrets"
    ]
  }
}]

Paramètres facultatifs

Outre les paramètres ci-dessus, vous avez la possibilité de configurer les paramètres supplémentaires suivants pour les règles de protection des branches. Veuillez noter que les contrôles de statut fournis parDevSecOps ne validera ni n’appliquera ces paramètres.

• Exiger des validations signées: ce paramètre requiert que toutes les validations de la branche protégée soient signées, ce qui permet d'éviter que des modifications malveillantes soient apportées au code.

• Exiger l'historique linéaire: ce paramètre requiert que toutes les validations de la branche protégée aient un historique linéaire. Cela signifie que toutes les demandes d'extraction fusionnées dans la branche protégée doivent utiliser une fusion de squash ou une fusion de resynchronisation. Un historique de validation strictement linéaire peut aider les équipes à inverser les changements plus facilement.

Ces paramètres supplémentaires sont facultatifs et peuvent être personnalisés en fonction de vos exigences et préférences spécifiques.

Ajout de toutes les règles de protection de branche (configuration complète)

Les règles de protection des branches peuvent également être définies par la commande curl suivante, après le remplacement des variables $GH_TOKEN, $OWNER, $APP_API_URL $REPO, $BRANCH.

curl -u ":$GH_TOKEN" $APP_API_URL/repos/$OWNER/$REPO/branches/$BRANCH/protection -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

Cette commande CURL configure à la fois les vérifications de statut requises et les paramètres de révision de demande d'extraction.

Une fois ces paramètres configurés, toute tentative de fusion d'une demande d'extraction vers $BRANCH sera rejetée sauf si la demande d'extraction a été approuvée par au moins un autre utilisateur.

Configuration des vérifications de statut uniquement (Configuration des vérifications de statut)

Si vous souhaitez uniquement configurer les vérifications de statut requises, vous pouvez utiliser la commande CURL suivante comme référence:

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/branches/master/protection" \
    -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

Dans notre implémentation de référence, nous avons déjà fourni un exemple de configuration pour le référentiel hello-compliance-app. Vous pouvez donc l'utiliser comme point de départ et le personnaliser en fonction de vos besoins.

Suivez l'exemple précédent pour garantir la qualité du code et le respect des mesures de sécurité pour votre référentiel. Pour que cela se produise, configurez les règles de protection de branche et les vérifications de statut nécessaires.