En tant que Professionnel DevOps global pour Splunk, j’échange avec des clients très variés. En règle générale, nos conversations se concentrent sur la résolution des problèmes qui touchent leur processus de planification, leurs systèmes de build et leur framework de publication.
Mais récemment, j’ai pris les clients au dépourvu en leur demandant comment ils gèrent la sécurité dans leur processus SDLC et s’ils communiquent facilement et honnêtement avec leur équipe des opérations de sécurité.
Dans la plupart des cas, le client me regarde avec les yeux écarquillés et me demande comment implémenter la sécurité dans le pipeline DevOps sans une grande part d’intervention humaine. Voici les trois grandes pistes que je suggère aux clients qui souhaitent sécuriser leur processus SDLC.
Planification et révision du code :
C’
est la première source de données majeure, négligée par la plupart des clients alors qu’elle peut en fait révéler des anomalies significatives. De nombreux clients sont habitués aux processus ITIL traditionnels, où les modifications sont documentées dans un système d’enregistrement, afin que toutes les parties prenantes puissent avoir une visibilité sur les nouveaux travaux. Ils ne réalisent toutefois pas toujours que les équipes DevOps peuvent aussi utiliser un système d’enregistrement pour documenter les modifications et les tâches, et ainsi offrir une visibilité à toutes les équipes. En corrélant une tâche, un epic ou un ID d’impression avec une demande de validation ou de modification du dépôt, les équipes de sécurité peuvent déterminer si un nouveau développement fait partie d’une modification planifiée ou si un changement non autorisé est sur le point de se produire
Lorsque des développeurs sont sur le point de valider du code dans une branche principale, et avant que cela ne devienne une demande d’extraction, le processus de révision par les pairs est essentiel, et on peut facilement le documenter dans ce même processus. En corrélant les tickets avec les validations, puis en associant ces données au système de build, vous pouvez obtenir une visibilité exceptionnelle qui profite à l’équipe de sécurité et protège l’entreprise dans son ensemble.
Automatisation de la chaîne de développement :
En allant plus loin dans le pipeline, je recommande une deuxième couche de défense pour protéger ce qui est déployé en production. Les plans de build en plusieurs étapes permettent naturellement aux équipes de développement de bénéficier d’une meilleure organisation, mais aussi de tester chaque phase du processus global individuellement. Des fondamentaux tels que les tests unitaires et fonctionnels permettent aux équipes de repérer les erreurs simples. Les outils d’analyse automatique du code donnent davantage de visibilité sur la dette technique, le nombre de lignes et la complexité. Mais toute la différence réside dans l’utilisation d’outils qui analysent les modules et testent les vulnérabilités. Ces outils vérifient automatiquement les signatures et les mappages CVE pour déterminer si le code sur le point d’être publié va présenter un risque accru pour l’entreprise.
En corrélant les données de ces multiples outils, les équipes de sécurité peuvent documenter les indicateurs clés de sécurité (KSI) pour permettre aux équipes de publication de déterminer si un artefact donné est prêt à être mis en production. Grâce à la corrélation de ces données avec celles du processus de planification et du système de build, les équipes de sécurité ont plus de temps à consacrer aux tests de pénétration et à la conformité, tout en favorisant une culture DevOps fluide.
Publication et supervision :
La troisième couche principale de défense (et la dernière, espérons-le) est l’automatisation de votre environnement. En utilisant le même concept de corrélation des données de vos systèmes de planification, SCM, de build et de test, vous pouvez également assurer la cohérence de vos catalogues de configurations. En utilisant une approche axée sur les données pour gagner en visibilité sur votre environnement, vos équipes de publication peuvent pousser de nouvelles configurations et paramètres en toute confiance, sans se soucier de la sécurité et sans mauvaise surprise.
Par exemple, les frameworks d’automatisation comme Puppet peuvent non seulement vous aider à gérer vos applicatifs, mais aussi fournir une couche de conformité. Lorsqu’une configuration n’est plus conforme, en utilisant la puissance de Splunk avec l’automatisation Puppet , par exemple, et en exploitant la possibilité de générer des KSI pour toute votre équipe, vous pouvez désormais dormir sur vos deux oreilles. Cela permet à vos développeurs de se concentrer sur l’amélioration de votre produit, plutôt que d’avoir à multiplier les couches de protection qui risquent d’augmenter la latence ou de dégrader l’expérience client.
Faire du DevSecOps une réalité :
Pour résumer, lorsque vous examinez votre pipeline DevOps aujourd’hui, pouvez-vous affirmer que vous prenez les mesures appropriées pour protéger vos équipes et, surtout, vos clients ? Si ce n’est pas le cas, prenez le temps d’importer vos données dans Splunk et voyez ce que vous pouvez faire pour minimiser vos risques. Parfois, il suffit de 15 minutes de réflexion sur un tableau blanc en concertation avec votre équipe pour comprendre les difficultés. Travaillons ensemble pour changer le monde de l’IT traditionnelle et faire naître la prochaine génération de DevSecOps.
----------------------------------------------------
Merci !
Domnick Eger
*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.
