Changement à gauche avec ces 11 meilleures pratiques DevSecops

1. Actifs d’inventaire

Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir. Maintenir un inventaire complet et en temps réel de toutes les applications, services, dépendances et composants d’infrastructure à travers l’organisation, y compris les éléments suivants:

• Applications internes.
• Logiciel tiers.
• Apis.
• Bases de données.
• Ressources cloud.
• L’ombrer.

Catalogue des informations critiques, y compris les niveaux de sensibilité aux données, la criticité des entreprises, la propriété et les interconnexions entre les systèmes.

Utilisez des outils de découverte automatisés pour cartographier en continu la surface d’attaque et identifier les nouveaux actifs lorsqu’ils sont déployés. Utilisez des outils d’analyse de composition logicielle pour trouver des problèmes de licence dans les composants d’application et implémentez la numérisation des conteneurs pour identifier les vulnérabilités dans les images et le code.

Comprendre la succession numérique complète de l’organisation permet une hiérarchisation fondée sur les risques, ne fait rien à travers des fissures de sécurité et fournit un contexte essentiel pour la réponse aux incidents. Sans un inventaire précis des actifs, les efforts de sécurité deviennent dispersés et inefficaces, laissant des angles morts exploitables et rendant plus difficile la conformité.

2. Connaître les objectifs

Définissez des objectifs de sécurité spécifiques et mesurables avant de mettre en œuvre un programme – que l’entreprise soit profonde et étroitement axée sur les vulnérabilités critiques ou larges et peu profondes dans l’ensemble du portefeuille d’applications. Établir des échelles de temps claires, des indicateurs de performance clés et des critères de réussite qui s’alignent sur les objectifs commerciaux et la tolérance au risque. Décidez dès le départ pour hiérarchiser une couverture rapide dans de nombreuses applications ou une sécurité complète pour les systèmes critiques de mission.

Fixez des objectifs réalistes, tels que «réduire les vulnérabilités critiques de 80% en six mois» ou «réaliser une couverture de test de sécurité pour 100% des applications orientées client».

Les objectifs clairs empêchent le fluage de portée, permettent une allocation appropriée des ressources et fournissent des résultats mesurables qui démontrent la valeur du programme de sécurité. Sans objectifs bien définis, les initiatives de sécurité deviennent des efforts floues qui ont du mal à montrer un impact commercial concrète ou à justifier l’investissement continu.

3. Effectuer une surveillance des menaces

Effectuer une surveillance des menaces au début et tout au long du processus de développement pour aider à clarifier et à hiérarchiser les objectifs.

La modélisation des menaces implique l’utilisation d’outils et de services de surveillance de la sécurité en temps réel pour rechercher en permanence des menaces, telles que les jours zéro-jours, l’exposition secrète et les vulnérabilités de dépendance. Le processus est essentiel pour identifier de manière proactive les faiblesses au sein du développement et des applications.

La modélisation des menaces associée à des évaluations des risques aide à identifier et à hiérarchiser les vulnérabilités et à mettre en œuvre des correctifs avant qu’ils affectent le produit en direct.

4. Étudiez le pipeline de livraison de l’équipe et itérez soigneusement

Avant de mettre en œuvre des pratiques de sécurité, comprenez complètement comment l’équipe de développement fonctionne actuellement – ses outils, ses processus et ses points de douleur. Carte Les contrôles de sécurité aux flux de travail existants plutôt que de forcer les équipes à adopter des processus entièrement nouveaux.

Commencez par de petites changements progressifs qui fournissent une valeur immédiate sans perturber la productivité. Les déploiements de sécurité de grande envergure qui tentent de tout transformer à la fois échouent presque toujours en raison de la résistance et de la complexité. Au lieu de cela, intégrez progressivement la sécurité dans le pipeline, permettant aux équipes de s’adapter et de voir les avantages avant d’introduire des mesures supplémentaires. Cette approche renforce la confiance et facilite l’adoption durable.

5. Automatiser avec prudence

Bien que l’automatisation soit cruciale pour la sécurité évolutive, tous les outils de sécurité n’appartiennent pas au pipeline de construction principal. Les tests de sécurité des applications dynamiques lourds et les analyses complètes de configuration du cloud peuvent ralentir considérablement les cycles de développement s’ils sont placés directement dans le chemin critique.

Au lieu de cela, exécutez ces analyses à forte intensité de ressources dans des pipelines parallèles ou des workflows de sécurité dédiés. Concentrez-vous sur l’intégration d’outils légers et à rétroaction rapide, tels que l’analyse statique et les vérifications de dépendance, dans la construction principale, tout en planifiant des évaluations de sécurité plus approfondies pendant les heures d’ouverture ou dans le cadre des processus de libération. L’automatisation avec prudence maintient la vitesse de développement tout en garantissant une couverture de sécurité approfondie.

6. faire faire la bonne chose de la manière la plus simple

La sécurité devrait être le chemin de la moindre résistance pour les développeurs, pas un obstacle à surmonter. Mettez en œuvre des concepts tels que des zones d’atterrissage ou des plateformes communes qui fournissent des environnements préconfigurés et endurcis avec des outils de sécurité standard déjà intégrés.

Lorsque des modèles sécurisés sont intégrés dans les infrastructures et les flux de travail par défaut, les développeurs suivent naturellement les meilleures pratiques sans effort supplémentaire. Fournir des modèles sécurisés par défaut, l’approvisionnement automatisé de ressources conformes et les capacités de libre-service qui guident les équipes vers des configurations sécurisées.

Cette approche élimine le frottement entre les exigences de sécurité et la productivité des développeurs pour garantir que l’option sécurisée est également l’option la plus pratique.

7. ‘Break the Build’ en dernier recours

La mise en œuvre des portes de sécurité qui arrêtent le processus de construction ne devraient se produire qu’après avoir entièrement réglé des outils de sécurité pour minimiser les faux positifs. Commencez par exécuter des outils en mode d’observation pour le triage des alertes et comprendre les modèles de bruit, puis ajustez les seuils en conséquence.

Les taux élevés de faux positifs érodent la confiance des développeurs et conduisent à des contournements de sécurité ou aux alertes ignorées. Avant d’appliquer les portes de blocage, concentrez-vous sur la réalisation de faibles niveaux de bruit grâce à la configuration appropriée de l’outil, aux règles personnalisées et à l’établissement de référence.

Une fois que les outils identifient systématiquement de véritables problèmes de sécurité sans les équipes écrasantes avec des alertes non pertinentes, mettent en œuvre des mécanismes d’application. Cette approche mesurée garantit que les portes de sécurité ajoutent de la valeur plutôt que de devenir des goulots d’étranglement de la productivité auxquels les équipes contribuent.

8. Gardez les secrets secrètes

La gestion des secrets nécessite la même rigueur que tout composant d’infrastructure critique. Scannez les référentiels GIT pour découvrir une exposition accidentelle aux informations d’identification. Centraliser tous les secrets dans les services dédiés, tels que les coffres de coffre-fort Hashicorp ou les secrets natifs du cloud, et implémentez la rotation automatique pour minimiser les fenêtres d’exposition. Appliquer un contrôle d’accès strict basé sur les rôles avec des principes de moins privile pour garantir que les utilisateurs et les services n’accèdent que les secrets dont ils ont besoin.

Une couverture complète est essentielle:

• Secrets sécurisé dans les pipelines continues d’intégration / de livraison continue, de clusters Kubernetes, de référentiels de code et d’ordinateurs portables du développeur.
• Never HardCode des informations d’identification dans le code source ou les fichiers de configuration.
• Utilisez des jetons de courte durée dans la mesure du possible et implémentez la journalisation de l’audit appropriée pour tout accès secret.

La forte gestion des secrets élimine l’un des vecteurs d’attaque les plus courants tout en maintenant l’efficacité opérationnelle.

9. Utiliser des infrastructures natives et reproductibles dans le nuage

Pour aider à réduire la surface d’attaque, éliminez les infrastructures persistantes qui peuvent accumuler des vulnérabilités au fil du temps. Fournir une mise à l’échelle élastique pour les charges de travail de sécurité et une réponse simplifiée des incidents grâce à un remplacement rapide des infrastructures.

Embrassez les modèles natifs du nuage qui améliorent la sécurité grâce à l’immuabilité et à l’évolutivité. Exécutez des scanners de sécurité en tant que charges de travail éphémères dans AWS Fargate, Lambda Functions ou Kubernetes plutôt que de maintenir une infrastructure de numérisation persistante.

Utilisez des machines d’état, telles que les fonctions AWS Step ou Azure Logic Apps, pour orchestrer des workflows de sécurité complexes qui s’étendent sur plusieurs outils et environnements. Traitez l’infrastructure comme «bovins, pas animaux de compagnie» – des systèmes de conception à jetter et remplaçables plutôt que de longue durée et entretenus manuellement.

10. Fournir des architectures et motifs de référence standard

La création d’une collection organisée de modèles éprouvés réduit les risques de sécurité en donnant aux développeurs des points de départ sécurisés par défaut, élimine la nécessité de réinventer les contrôles de sécurité et de protéger la cohérence entre les projets. Les architectures de référence bien documentées accélèrent le développement tout en intégrant les meilleures pratiques de sécurité dans la base de chaque application.

Établir des référentiels centralisés de plans architecturaux approuvés, de modèles de codage sécurisés et de bibliothèques vérifiées que les équipes de développement peuvent facilement adopter. Créer des wikis, des référentiels de modèles et des bibliothèques de modèles qui présentent des implémentations de sécurité positives – des flux d’authentification sécurisés aux pratiques de traitement des données appropriées. Utilisez le Top 10 OWASP pour créer une base de sécurité que tout le monde doit suivre.

Fournissez des méthodes standard pour les fonctions de sécurité communes, telles que la validation des entrées, le chiffrement et la sécurité de l’API, que les équipes peuvent copier et personnaliser. Incluez les modèles d’infrastructure en tant que code pour les déploiements cloud sécurisés et les applications conteneurisées. Effectuer des vérifications de conformité pour déterminer si le code et les applications collectent des données et des informations personnellement identifiables en toute sécurité et dans les réglementations de l’industrie.

11. Suivre les progrès, célébrer les victoires

Les améliorations de la sécurité deviennent durables lorsque les équipes peuvent voir des progrès mesurables et se sentir reconnus pour leurs efforts. N’oubliez pas de suivre les progrès et de célébrer les victoires en cours de route.

Mettre en œuvre des métriques qui comptent, telles que les temps d’assainissement de la vulnérabilité, la couverture des tests de sécurité, la réduction des incidents et l’adoption des outils de sécurité des développeurs. Créez des tableaux de bord qui visualisent les améliorations de la posture de sécurité au fil du temps pour rendre les progrès visibles à la fois pour les équipes techniques et le leadership.

Célébrez des jalons tels que la réalisation de vulnérabilités critiques, des évaluations de sécurité réussies ou des taux d’adoption élevés des pratiques de codage sécurisées. La reconnaissance n’a pas toujours besoin d’être formelle – reconnaître les équipes qui adoptent les initiatives de sécurité, partagent des réussites à travers l’organisation et mettent en évidence les champions de sécurité.

Le renforcement positif prend de l’élan, encourage l’engagement continu avec les pratiques de sécurité et transforme la sécurité d’un fardeau de conformité en une source de fierté d’équipe et de résilience organisationnelle.

Colin Domoney est un consultant en sécurité des logiciels qui évangélise DevSecops et aide les développeurs à sécuriser leur logiciel. Il a auparavant travaillé pour Veracode et 42Crunch et a écrit un livre sur la sécurité de l’API. Il est actuellement CTO et co-fondateur, et un consultant en sécurité indépendant.