Sécurité → Paramètres contient le Par défaut organisationnel et s'applique à chaque projet. Chaque projet suit cette configuration par défaut jusqu'à ce qu'un utilisateur lui attribue sa propre configuration ; Utiliser la valeur par défaut permet de revenir à cette configuration. Les propriétaires et administrateurs modifient les paramètres ; les membres les voient en lecture seule.
Observation et application
Chaque protection possède deux états distincts :
- Observation: détecter, enregistrer et afficher. Les constatations apparaissent dans la section Sécurité, et
Coroid Securityla vérification des demandes d'intégration les signale sans faire échouer celle-ci. - Application: faire échouer une vérification. Une modification qui génère une constatation d'une gravité égale ou supérieure à celle définie fait échouer la vérification, et les tâches de Coroid n'ouvrent pas de demande d'intégration au-delà de ce seuil.
L'application propose trois options par périmètre :
| Option | Signification |
|---|---|
| Hériter (par défaut) | Appliquer la protection dès que la plateforme a franchi l'étape de préparation requise. |
| Appliquer | La même option, choisie explicitement pour ce périmètre. |
| Observation uniquement | Jamais faire échouer une vérification, quel que soit l'état de la plateforme. |
Chaque protection démarre en mode observation. Coroid n'active l'application pour chaque protection qu'après que celle-ci ait franchi son étape de préparation : pour les dépendances, les tests de couverture et une période d'observation sans blocage erroné ; pour les règles relatives aux secrets et au code, l'étalonnage décrit ci-dessous et la même période d'observation. Jusqu'alors, une protection réglée sur Hériter ou Appliquer reste en observation, et le paramètre l'indique. Une fois l'étape franchie, toutes les configurations passées de Hériter passent à l'application ; celles ayant choisi Observation uniquement continuent d'observer.
L'application ne signifie pas "GitHub empêche la fusion". GitHub bloque une fusion
uniquement si le dépôt exige la vérification Coroid Security voir
Les autorisations GitHub et la vérification de Sécurité Coroid.
Règles étalonnées
Les règles relatives aux secrets fuites et à l'analyse de code ne s'appliquent qu'avec des versions de détecteur ayant passé l'étalonnage : précision et rappel mesurés sur un ensemble étiqueté de codes réels et de secrets synthétiques, taux de blocage erroné évalué via la reproduction de modifications déjà fusionnées, chaque erreur signalée conservée comme cas devant continuer à être validé, et 14 jours d'observation sans blocage incorrect.
Une nouvelle version de détecteur ne prend jamais le relais de l'application d'elle-même. La dernière version approuvée continue d'appliquer la règle pendant que la nouvelle version observe en parallèle, et elle ne prend le contrôle qu'après avoir elle-même passé l'étalonnage. Si aucune version approuvée ne peut fonctionner, une protection appliquée signale son indisponibilité et fait échouer sa vérification, plutôt que de laisser passer sans contrôle.
Les paramètres
| Protection | Commuter | Ajuster |
|---|---|---|
| Dépendances vulnérables | Observation | Application ; "Appliquer à partir d'une gravité donnée" (par défaut élevée) |
| Corriger les dépendances vulnérables | Activer ou désactiver | "Ouvrir les tâches de correction à partir d'une gravité donnée" (par défaut élevée) ; limite d'ouverture de correction par projet pour pull request (par défaut 5, jusqu'à 50) ; budget horaire d'agent, selon le paramètre par défaut de l'organisation |
| Secrets fuites | Observation | Application. Uniquement selon le paramètre par défaut de l'organisation : bloquer les nouveaux secrets et la plus grande modification analysée |
| Analyse de code | Observation | Application ; votre propre commande d'analyse ; la liste des règles |
| Révision de Sécurité sur les demandes d'intégration | Observation | Application ; "Appliquer à partir d'une gravité donnée" (par défaut élevée) |
| Alertes de sécurité GitHub | Observation | Aucune |
| Audit de sécurité | Activer ou désactiver | Fréquence : quotidienne, hebdomadaire (par défaut) ou mensuelle |
Certaines protections dépendent d'autres éléments :
- Révision de Sécurité sur les demandes d'intégration nécessite que Coroid Révision soit activé pour le projet dans Contrôle qualité. Si Coroid Révision est désactivé, la ligne l'indique et la protection n'agit pas.
- Corriger les dépendances vulnérables selon le paramètre par défaut de l'organisation active également l'obligation intégrée de corrections de Sécurité. Voir Corriger les demandes d'intégration.
- Audit de sécurité suit votre plan sauf si vous le modifiez : activé pour les abonnements payants, désactivé pour l'offre Gratuite. Voir Audit de sécurité.
Sécurité fonctionne indépendamment des paramètres de Contrôle qualité
Les protections de la fonctionnalité Sécurité ne dépendent pas des contrôles du Contrôle qualité. Désactiver l'option anti-slop dans le Contrôle qualité désactive uniquement ses règles de qualité, et non les règles de code de la fonctionnalité Sécurité. Pour les demandes d'intégration, Coroid Security publie sa propre vérification, que le projet dispose ou non d'un graphe de livraison publié.
La configuration du scanneur provient de Coroid
Les scanneurs s'exécutent avec la configuration Coroid générée à partir de ces paramètres et des exceptions acceptées dans la fonctionnalité Sécurité, jamais à partir des fichiers de la modification en cours de test. Une modification qui ajoute ou modifie la configuration du scanneur (osv-scanner.toml,
.gitleaks.toml, .gitleaksignore, .github/secret_scanning.yml,
.secrets.baseline et similaires) est vérifiée selon la configuration du commit de base et génère une security.policy-changed occurrence. Un fichier du dépôt peut proposer une exception ; celle-ci n'est appliquée qu'une fois qu'un propriétaire ou un administrateur l'a acceptée dans la fonctionnalité Sécurité. La même règle s'applique aux tâches de correction propres à Coroid : un agent ne peut pas faire passer sa propre vérification en modifiant ce qui est exclu.
Les Paramètres accompagnent l'organisation.
Les security paramètres font partie du lot de paramètres de l'organisation, aux côtés des autres politiques de qualité, tout comme le dernier modèle de menace de chaque projet. Les exceptions, occurrences et preuves sont des résultats, non des paramètres, et ne sont pas transmis. Consultez Portabilité des paramètres.