Gestion de Monorepository¶

Les structures de monorepository (monorepo) permettent aux équipes d'organiser plusieurs projets au sein d'un seul dépôt. Pour tirer parti de cette configuration dans votre programme AppSec, définissez vos structures de monorepo sur la page de Gestion des Actifs. Boost vous permet d’identifier les dépôts en tant que monorepos et de cartographier leur disposition et leurs emplacements de sous-dépôts. Vous pouvez configurer cela directement via l'interface utilisateur ou utiliser un téléchargement CSV en masse basé sur ce format simple.

Une fois définis, ces sous-dépôts se comporteront au sein de Boost comme tout autre dépôt, vous permettant d'attribuer des politiques spécifiques, de fournir une couverture spécifique et de visualiser les résultats concernant ces sous-dépôts. Voir Comment se comportent les sous-dépôts.

Comment créer des Monorepositories¶

Suivez ces étapes pour créer des monorepositories et définir leurs sous-dépôts soit manuellement, soit par téléchargement CSV en masse.

Accédez à la page de Couverture du Scanner et assurez-vous que le dépôt n'a aucun scan activé et aucun résultat de scan en supprimant tous les scans en utilisant le mode Avancé.
Accédez à la page de Gestion des Actifs. Assurez-vous que les actifs sont regroupés par Organisation et que le Type d'Actif est défini sur Dépôts.
Sélectionnez l'ellipse verticale (trois points) à droite de n'importe quel dépôt et choisissez Créer un Monorepo.
Dans l'interface de création de Monorepo, commencez à définir les sous-dépôts au sein de la structure de Monorepo.
Entrez le chemin et le nom de chaque sous-dépôt, puis cliquez sur Ajouter pour inclure le sous-dépôt dans la liste des sous-dépôts configurés pour ce monorepo. Le chemin et le nom doivent respecter les règles de chemin et de nom.

Warning

Le nom est l'identité du sous-dépôt : le renommer plus tard, même seulement sa casse, crée un nouvel actif et rend orphelin le précédent ainsi que ses résultats. Voir Modification, Renommage et Suppression des sous-dépôts.
Si vous avez besoin de créer de nombreux sous-dépôts, utilisez un téléchargement de fichier .CSV avec le format pour définir toute la structure de sous-dépôts en une seule action.

Veuillez noter que tout téléchargement de fichier CSV écrasera toutes les configurations existantes pour ce monorepo.

Tout sous-dépôt absent du fichier est supprimé, avec ses résultats. Voir Modification, Renommage et Suppression des sous-dépôts.

Cette approche est plus efficace que d'ajouter les sous-dépôts un par un manuellement.

Comment se comportent les sous-dépôts¶

Chaque sous-dépôt est un actif distinct, avec ses propres scanners, résultats, politiques, étiquettes et vérifications de pull request ou de merge request.

Les paramètres appliqués au dépôt parent ne se propagent pas à ses sous-dépôts. Les étiquettes, politiques, groupes d'actifs et scanners sur le parent s'appliquent uniquement au parent.
Sélectionner le dépôt parent ne sélectionne pas ses sous-dépôts. Pour agir sur un sous-dépôt, par exemple pour provisionner un scanner ou attribuer une étiquette, sélectionnez le sous-dépôt lui-même.
Un nouveau sous-dépôt commence sans scanner, et le dépôt parent cesse d'analyser son chemin. Provisionnez des scanners sur celui-ci depuis la page de Couverture du Scanner. Voir Analyse du dépôt parent.
Un sous-dépôt peut avoir son propre fichier .boostignore à la racine de son chemin. Ce fichier remplace, pour le sous-dépôt, à la fois le Boostignore Global défini sur la page Boostignore et le fichier .boostignore à la racine du dépôt parent. Lorsque le sous-dépôt n'en a pas, le Boostignore Global s'applique.

Règles de chemin et de nom¶

Chaque sous-dépôt a un chemin et un nom :

Chemin : un répertoire relatif à la racine du dépôt, par exemple services/api. Le chemin n'a pas de ./ ou / en tête ni de / en fin.
Nom : le nom sous lequel le sous-dépôt apparaît dans Boost Security.

Les noms doivent être uniques au sein du monorepo, et les chemins aussi. Le chemin ne doit pas être vide ni . : la racine du dépôt est le dépôt parent, jamais un sous-dépôt.

Chemin	Valide	Raison
`services/api`	Oui	Répertoire relatif à la racine du dépôt
`frontend`	Oui	Répertoire relatif à la racine du dépôt
`./services/api`	Non	`./` en tête
`/services/api`	Non	`/` en tête
`services/api/`	Non	`/` en fin
`.`	Non	La racine est le dépôt parent
(vide)	Non	La racine est le dépôt parent

Warning

L'interface utilisateur accepte un chemin vide sans erreur. Entrez toujours le répertoire du sous-dépôt.

Boost Security ne vérifie pas que le chemin existe sur la branche analysée. Les analyses d'un sous-dépôt dont le chemin n'existe pas échouent.

Un dépôt peut avoir soit des sous-dépôts, soit des branches supplémentaires surveillées, mais pas les deux.

Modification, Renommage et Suppression des sous-dépôts¶

Le nom d'un sous-dépôt est son identité dans Boost Security :

Modifier uniquement le chemin conserve le même actif.
Renommer un sous-dépôt, même lorsque seule la casse de son nom change, crée un nouvel actif sous le nouveau nom. L'actif sous le nom précédent devient un actif orphelin et conserve les résultats existants avec leur état de triage, tels que les suppressions et les tickets. Les nouvelles analyses rapportent leurs résultats, non triés, sur le nouvel actif.
Supprimer un sous-dépôt supprime ses résultats. L'ajouter à nouveau plus tard crée un nouvel actif.

Warning

Un téléchargement CSV remplace toute la liste des sous-dépôts du monorepo. Tout sous-dépôt absent du fichier est supprimé, avec ses résultats.

Comment les analyses sont déclenchées dans un Monorepo¶

Lorsqu'un commit ou une pull request modifie des fichiers dans un monorepo, Boost Security exécute les scanners en fonction des chemins des fichiers modifiés :

Les modifications sous le chemin d'un sous-dépôt exécutent uniquement les scanners provisionnés sur les sous-dépôts dont le chemin les contient.
Les modifications en dehors de tous les chemins de sous-dépôts exécutent les scanners provisionnés sur le dépôt parent. Voir Analyse du dépôt parent.
Les modifications sous des chemins imbriqués, comme services et services/api, exécutent les scanners de chaque sous-dépôt dont le chemin les contient : le contenu d'un sous-dépôt imbriqué n'est pas exclu du sous-dépôt qui le contient. Évitez d'imbriquer les sous-dépôts.

Une pull request qui touche plusieurs zones démarre une analyse par zone pour chaque scanner provisionné sur cette zone. Le dépôt parent compte comme une zone lorsque des fichiers en dehors de tous les chemins de sous-dépôts changent. Par exemple, une pull request qui modifie des fichiers dans le dépôt parent et dans deux sous-dépôts, avec deux scanners chacun, démarre jusqu'à six analyses. Planifiez votre capacité d'exécuteur en conséquence.

Note

Les vérifications du même scanner dans différents sous-dépôts peuvent porter des noms identiques. Par conséquent, vous ne pouvez pas rendre la vérification d'un sous-dépôt spécifique une vérification requise dans vos règles de protection de branche.

Analyse du dépôt parent¶

Les analyses du dépôt parent excluent les chemins de tous ses sous-dépôts, pour chaque scanner. Un fichier sous le chemin d'un sous-dépôt est analysé uniquement par les scanners des sous-dépôts dont le chemin le contient. Un fichier en dehors de tous les chemins de sous-dépôts est analysé uniquement par les scanners du dépôt parent.

Vous pouvez donc provisionner les mêmes scanners sur le dépôt parent et sur ses sous-dépôts sans obtenir de résultats en double entre le parent et ses sous-dépôts. Les scanners sur le dépôt parent couvrent également les fichiers en dehors des sous-dépôts déclarés, par exemple un nouveau répertoire de projet pas encore déclaré comme sous-dépôt.

Note

Déclarer un sous-dépôt retire son chemin des analyses du dépôt parent. Provisionnez des scanners sur le nouveau sous-dépôt, sinon ses fichiers ne seront plus analysés.

Les résultats du dépôt parent sont rapportés avec des chemins relatifs à la racine du dépôt.