Bonnes pratiques

Lors de la mise en œuvre d'un nouveau DevSecOps mécanisme, il est essentiel de prendre en compte les différentes sources de paternité du code et la manière dont elles seront habilitées ou potentiellement bloquées. Souvent, les ingénieurs ne peuvent interagir qu'avec l'une de ces sources. Cependant, l'introduction d'un nouveau mécanisme peut mettre en avant de nouvelles sources de paternité ou mettre en évidence des problèmes liés à des sources qui n'avaient pas été prises en compte auparavant. Explorons chacun des aspects suivants plus en détail :

• Développeurs de l'équipe d'application : ce sont les développeurs responsables du code de base de l'application. Ils doivent être habilités à apporter des modifications et des mises à jour au code de l'application selon les besoins, mais leur travail doit également s'aligner sur le nouveau DevSecOps mécanisme.

• Développeurs d'infrastructures centrales — Cette équipe est responsable de l'infrastructure de base de l'organisation, telle que les ressources cloud, le réseau et la sécurité. Ils doivent participer à la définition de l'infrastructure en tant que code (IaC) et aux processus de déploiement afin de garantir une intégration fluide du nouveau mécanisme.

• Bases de code tierces et open source — L'utilisation de bibliothèques tierces et de composants open source est courante. Cependant, ces sources doivent être soigneusement gérées et sécurisées dans le cadre du nouveau DevSecOps mécanisme.

• Code et artefacts réutilisables — La promotion de la création et de l'utilisation de code et d'artefacts réutilisables peut améliorer l'efficacité et la cohérence, mais la propriété et la gouvernance de ces ressources partagées doivent être clairement définies.

• Référentiels et contributions partagés : permettre la création collaborative de code par le biais de référentiels partagés peut s'avérer bénéfique, mais cela nécessite une gestion minutieuse de l'accès, des politiques de fusion et des révisions du code pour garantir la qualité et la sécurité.

• Stratégies de branchement pour IaC — La méthodologie Git n'est pas directement compatible avec les modèles de conception d'infrastructure courants. Les stratégies de branchement traditionnelles devront peut-être être adaptées à l'IaC afin de relever les défis uniques liés à la gestion de l'infrastructure. Cela peut impliquer le développement de flux de travail spécialisés qui tiennent compte de la nature dynamique de l'infrastructure, du risque de dérive et d'une coordination minutieuse lors de la modification d'environnements réels.

• Gestion de l'État — La gestion de l'état de l'infrastructure est cruciale dans IaC. Une bonne gestion de l'état garantit que l'infrastructure réelle est alignée sur le code défini et empêche les conflits ou les modifications involontaires. La mise en œuvre de pratiques robustes de gestion des états, telles que l'utilisation de mécanismes de stockage à distance et de verrouillage d'état, est essentielle pour maintenir la cohérence et prévenir les conflits dans les environnements multi-utilisateurs.

• Sécurité - Dans le contexte de l'IaC DevSecOps, la sécurité doit être intégrée à chaque étape du cycle de vie de l'infrastructure. Cela inclut la sécurisation de la base de code IaC elle-même, la mise en œuvre de contrôles d'accès avec le moindre privilège, le chiffrement des données sensibles et l'analyse régulière des vulnérabilités du code de l'infrastructure et des ressources déployées qui en résultent. Les contrôles de sécurité automatisés et les validations de conformité doivent être intégrés au pipeline d'intégration continue et de livraison continue (CI/CD) afin de garantir que les meilleures pratiques de sécurité sont appliquées de manière cohérente.

Pour concevoir un DevSecOps mécanisme qui responsabilise et soutient efficacement des équipes disparates, vous devez identifier toutes les sources potentielles de création de code et comprendre leurs besoins et leurs défis. Cette approche permet de garantir une mise en œuvre et une adoption harmonieuses du nouveau mécanisme dans l'ensemble de l'organisation.

La conception de DevSecOps mécanismes va bien au-delà des aspects techniques. La conception et la mise en œuvre des DevSecOps mécanismes ont de profondes implications. L'équipe responsable doit examiner attentivement les facteurs culturels, organisationnels et humains. Cette considération permet de garantir que la solution répond non seulement aux exigences techniques, mais favorise également un environnement de travail positif, productif et engageant pour toutes les parties prenantes. Trouver le juste équilibre est essentiel à la réussite à long terme et à la satisfaction des employés.

Envisagez les scénarios suivants liés à la conception et au déploiement de DevSecOps mécanismes :

• Accroître la disparité entre les développeurs et les responsables — La mise en œuvre d'un système permettant aux développeurs avides de fournir rapidement des solutions peut par inadvertance mettre en évidence le manque de travail apparent des responsables. Les responsables sont des personnes titulaires du titre de développeur, mais leurs day-to-day responsabilités ont été transférées au support et à la stabilité des applications existantes. Le manque de nouvelles contributions des responsables a peut-être été moins visible par le passé. Cette situation pourrait amener l'organisation à sous-évaluer les connaissances et l'expertise essentielles de ces responsables, ce qui pourrait provoquer du ressentiment et une baisse du moral.

• Repousser les développeurs avec une solution trop gouvernée — La création d'une DevSecOps solution hautement gouvernée et peu pratique à utiliser pour les développeurs avides peut attirer les mainteneurs. Cependant, la solution risque de faire fuir les personnes dont l'organisation a besoin pour stimuler l'innovation. Forcer les développeurs à apprendre un mécanisme CI/CD propriétaire en plus de leurs applications et de leurs langages de programmation peut constituer un obstacle important à l'adoption. Une DevSecOps solution hautement gouvernée peut décourager les développeurs talentueux.

• Risque d'incompatibilité et de perturbation culturelles — La mise en œuvre d'un DevSecOps mécanisme culturellement incompatible avec les méthodes de travail existantes de l'organisation peut créer des frictions et des résistances importantes. Si l'approche du mécanisme (par exemple, prescriptive plutôt que consultative) ne correspond pas à la culture de l'organisation, il ne sera probablement pas adopté. Par conséquent, certaines parties prenantes peuvent être frustrées et penser que l'organisation s'oriente vers une bureaucratie inutile.