Explorer les points de validation clés

Effectué

La validation continue de la sécurité doit être ajoutée à chaque étape du développement jusqu’à la production pour garantir que l’application est toujours sécurisée.

Cette approche vise à faire passer la conversation avec l’équipe de sécurité de l’approbation de chaque mise en production au consentement du processus CI/CD, et à surveiller et auditer le processus à tout moment.

Le diagramme ci-dessous met en évidence les points de validation critiques dans le pipeline CI/CD lors de la création d’applications entièrement nouvelles.

Vous pouvez implémenter progressivement les outils en fonction de votre plateforme et du cycle de vie de votre application.

En particulier si votre produit est mature et que vous n’avez pas encore exécuté de validation de sécurité sur votre site ou votre application.

Screenshot of flowchart with IDE, and Pull, CI, Dev, and Test.

ID / demande de tirage

La validation dans CI/CD commence avant que le développeur ne commite son code.

Les outils d’analyse du code statique de l’IDE fournissent la première ligne de défense pour s’assurer que des failles de sécurité ne sont pas introduites dans le processus CI/CD.

Le processus de commit du code dans un dépôt central doit avoir des contrôles pour empêcher l’introduction de failles de sécurité.

L’utilisation du contrôle de code source Git dans Azure DevOps avec des stratégies de branche fournit une expérience de commit contrôlée qui peut fournir cette validation.

L’activation de stratégies de branche sur la branche partagée requiert une demande de tirage (pull request) pour démarrer le processus de fusion et garantir l’exécution de tous les contrôles définis.

La demande de tirage doit exiger une revue du code, seule vérification manuelle mais néanmoins importante pour identifier les nouveaux problèmes introduits dans votre code.

En même temps que cette vérification manuelle, les commits doivent être associés aux éléments de travail pour vérifier pourquoi la modification du code a été effectuée et exiger que le processus de build d’intégration continue (Ci) réussisse avant l’opération de poussée (push).