Module Conformité

Le module Conformité agrège les résultats d’ArchPilot, ArchScan et ArchSecurity en un score de conformité unique et un rapport prêt pour l’audit.

Fonctionnalités

• Score de conformité unique - les résultats des modules sont réduits à un score unique et comparable.
• Rapport prêt pour l’audit - un rapport partageable que vous pouvez remettre directement à un auditeur.
• Analyse des écarts - montre ligne par ligne quelles règles n’ont pas pu être satisfaites.
• Vos propres règles de politique - c’est vous qui définissez ce que signifie la conformité.
• Suivi dans le temps - suivez la progression du score au fil des versions.

Limites

Des limites mensuelles d’analyse sont appliquées selon votre forfait. 5 analyses/mois en Trial ; illimité dans les forfaits payants.

Images de conteneur et sources de paquets

Quatre règles lisent comment le service est construit et d’où viennent ses dépendances :

Règle	Respectée quand
BE_DOCKERFILE_NON_ROOT_USER	La dernière étape de l’image s’exécute avec un utilisateur autre que root : une ligne USER, un utilisateur hérité de l’étape depuis laquelle elle est construite par FROM, ou une image de base non root par conception (.NET chiseled, distroless nonroot). Aucun USER signifie root.
BE_DOCKERFILE_APP_OWNED_BY_NON_ROOT	Les fichiers de l’application sont confiés à cet utilisateur dans la dernière étape : COPY --chown= / ADD --chown= ou RUN chown. Un chown dans une étape de build n’atteint pas l’image.
BE_DOCKERFILE_BASE_IMAGE_ALLOWED	Chaque image que le Dockerfile récupère vient d’une source autorisée. Une image nommée par un argument de build (FROM ${BASE_IMAGE}) est résolue depuis le pipeline, les modèles qu’il inclut et les variables CI/CD du projet ; celle qui ne peut pas l’être est ignorée, jamais en échec.
DEP_NUGET_SOURCES_ALLOWED	.NET uniquement : chaque source de paquets du nuget.config racine est un flux autorisé. Sans <clear/>, le nuget.org de la machine s’applique toujours, ce qui est signalé avec la correction.

Les sources autorisées sont définies une fois pour l’installation (Administration → Paramètres → Politiques → Sources autorisées) et chaque espace de travail peut ajouter les siennes (Paramètres de l’espace de travail → Sources autorisées) ; une règle accepte une source présente dans l’une ou l’autre liste. Une entrée est un hôte ou chemin de registre (registry.example.com, tout ce qui est dessous) ou une URL de flux ; * représente n’importe quelle suite de caractères (registry.example.com/*, *.example.com/*, harbor.example.com/base/*:10.*) - ce n’est pas une expression régulière. Tant qu’aucune source d’un type n’est définie, sa règle est ignorée.

Dépôts privés

Sept règles s’adressent à des personnes extérieures à l’entreprise : DOC_LICENSE_EXISTS, DOC_LICENSE_SPDX_RECOGNIZED, DOC_CONTRIBUTING_EXISTS, DOC_CODE_OF_CONDUCT_EXISTS, SEC_POLICY_EXISTS, DOC_README_HAS_BADGES et REPO_HAS_TOPICS. Sur un dépôt privé (GitLab private ou internal), elles sont désactivées par défaut et apparaissent comme ignorées. Activées pour le projet, l’espace de travail ou l’installation, elles s’exécutent quand même.

D’autres règles lisent désormais le fichier là où il se trouve : un docker-compose local dans un sous-dossier (infra/docker/) compte, et .env.example n’est demandé qu’aux stacks configurés par fichiers .env (Node.js, Python, Ruby, PHP, Go), pas à .NET ni à Java.

ISO 27001

AppArch rattache l’annexe A d’ISO/IEC 27001:2022 aux preuves qu’il produit déjà : règles Compliance, règles Git Health et classes de faiblesses ArchSecurity (CWE), chacune marquée directe ou partielle.

• Analyser selon un référentiel - dans Règles → Règles Compliance et Règles Git Health, Uniquement les règles ISO 27001 limite le workspace aux règles rattachées ; Revenir aux règles par défaut l’annule. Les interrupteurs restent modifiables règle par règle et les réglages de projet sont conservés. Les administrateurs peuvent appliquer le même profil aux valeurs par défaut de l’installation (Administration → Paramètres → Règles).
• Preuves techniques ISO 27001 (Compliance → Preuves ISO 27001) - chaque mesure avec ce qu’en disent les dernières analyses : conforme, non conforme, pas encore de preuve ou non mesurable depuis le code. La plupart des mesures sont organisationnelles, humaines ou physiques et sont listées à part. Le rapport est une preuve technique, pas une certification.

Contrôles manuels

Certains contrôles échappent à toute analyse : une revue des accès, un test de restauration, des accords de confidentialité signés. Écrivez-les comme vos propres règles dans Règles → Contrôles manuels, ou importez la liste que vous tenez déjà au format CSV (un modèle est disponible sur la page d’import ; colonnes code, title, description, category, severity, recheck_days, iso_controls, enabled, séparées par une virgule ou un point-virgule). L’import associe les règles par code et enregistre tout ou rien.

• Activez une règle pour le workspace ou par projet, comme toute règle Compliance.
• Sur la page des contrôles manuels d’un projet, une personne enregistre réussi ou échoué, avec une note. Chaque décision conserve son auteur et sa date ; une correction est une nouvelle décision, jamais une modification.
• Avec des jours de revérification, une décision réussie devient revérification due à l’échéance.
• Indiquez des mesures ISO 27001 sur la règle : le rapport ISO 27001 compte alors les décisions comme preuves pour elles - c’est ainsi que les mesures humaines et physiques obtiennent des preuves.
• Les contrôles manuels ne modifient pas le score Compliance. Les décisions d’une règle sur tous les projets se téléchargent en CSV ; une règle supprimée qui a des décisions est archivée avec son historique.

Règles retirées

Ces règles ne s’exécutent plus. Les constats des analyses précédentes restent dans l’historique ; la règle qui répond désormais à la même question figure à côté de chacune.

Règle	Remplacée par	Pourquoi
SEC_BRANCH_PROTECTION	Git Health GIT_DEFAULT_BRANCH_PROTECTED	La protection de branche est un paramètre du fournisseur Git ; Git Health la lit, et ses règles de force push et de push direct s’appuient dessus.
SEC_NO_ENV_AT_ROOT	Git Health REPO_SECRET_FILE_COMMITTED	La règle Git Health cherche les fichiers .env, les clés privées et les paramètres de production dans tout le dépôt, pas seulement à la racine.
INT_ARCHPILOT_ENABLED, INT_ARCHSCAN_ENABLED	-	Les modules ne s’activent plus par projet, il n’y a plus rien à vérifier.