Un équilibre frappant : redéfinir la sécurité logicielle avec « Shift Left » et les garde-corps SDLC

Tous Les Articles

TL; DR

Ces dernières années, l’industrie technologique a défendu avec ferveur le concept de « virage à gauche » dans le développement de logiciels, en plaidant pour une intégration précoce des pratiques de sécurité dans le cycle de vie du développement. Ce mouvement vise à donner aux développeurs la responsabilité d'assurer la sécurité de leur code dès le début du projet. Cependant, même si les intentions derrière cette approche sont nobles, la réalité dresse un tableau plus nuancé, où la notion simpliste de compter uniquement sur les développeurs pour faire respecter sécurité de la chaîne logistique logicielle s'avère insuffisante. Dans cet article, je présenterai une approche d'équilibrage complémentaire : les garde-fous SDLC dirigés par le RSSI – des mesures de contrôle automatiques qui régissent ou appliquent la politique de sécurité du SDLC.

Qui a quitté mon fromage ?

Le paradigme du changement de gauche vise essentiellement à répondre aux problèmes de sécurité dès les premières étapes du développement, en attendant que les développeurs intègrent de manière proactive des mesures de sécurité dans leur code. Il s'agit d'une idéologie attrayante dans laquelle les développeurs sont chargés d'identifier les vulnérabilités et de mettre en œuvre des contrôles de sécurité lorsqu'ils écrivent et déploient leur code.

Cependant, cette approche idéaliste se heurte à des défis importants dans sa mise en œuvre pratique. Bien qu’ils maîtrisent le codage, les développeurs peuvent manquer d’expertise complète en matière de techniques de sécurité et de bonnes pratiques. Leur objectif principal est de répondre aux exigences fonctionnelles, et il est irréaliste de s’attendre à ce qu’ils possèdent une compréhension exhaustive du paysage en constante évolution de la cybersécurité.

De plus, les contraintes de temps et les pressions liées aux projets entraînent souvent des compromis entre la sécurité et le respect des délais. Dans la hâte de fournir des fonctionnalités rapidement, les développeurs peuvent par inadvertance négliger d'éventuelles failles de sécurité ou employer des pratiques de codage moins sécurisées, laissant les vulnérabilités non corrigées jusqu'à des étapes ultérieures. En fin de compte, leurs KPI sont axés sur la rapidité et la sécurité passera toujours au second plan pour la majorité d’entre eux.

Entrez dans les garde-corps CI/CD

C’est là que la nécessité de mettre en œuvre des « garde-corps » de sécurité dans le pipeline d’intégration continue/déploiement continu (CI/CD) devient évidente. Les garde-corps agissent comme des points de contrôle automatisés intégrés au pipeline de développement, garantissant que les mesures de sécurité ne dépendent pas uniquement d'interventions manuelles ou de l'expertise ou de la motivation individuelle des développeurs.

Les garde-fous servent de gardiens proactifs, surveillant et appliquant en permanence les normes, politiques et règles de sécurité tout au long du cycle de vie du développement logiciel (SDLC). Ces contrôles automatisés peuvent englober divers aspects de sécurité, y compris, mais sans s'y limiter, la mise sur liste noire des packages défectueux, l'arrêt du code contenant des vulnérabilités critiques, qui échoue aux tests d'analyse de code statique ou qui présente des dépendances problématiques, ainsi que le respect des normes de conformité ou la sécurisation des politiques SDLC (par exemple, le code examen pour chaque commit).

En utilisant les concepts de politique en tant que code, on peut créer presque toutes les règles qu'on peut imaginer et mettre en œuvre comme garde-fou. Voici quelques exemples de règles de garde-corps conformes à NIST800-204D:

Exemple de garde-corps

Règles exemplaires de garde-corps :

  1. Poste de travail du développeur
    • Vérifier la suite de sécurité des points finaux du poste de travail du développeur
  2. SMC
    • Vérifier les règles de protection des branches : appliquer plusieurs révisions spécifiques
    • Vérifiez que les fichiers CI sont modifiés uniquement par le personnel autorisé
    •  Vérifiez que l'analyse des secrets est en place et que les secrets ne sont pas détectés.
  3. CI
    • Vérifiez que la numérisation du code est en place.
    • Vérifiez que les résultats de l'analyse du code se trouvent sous une barre prédéfinie
  4. Dépendances
    • Vérifiez la licence open source.
    • Vérifier que les vulnérabilités open source sont conformes à la politique de l'organisation
  5. Artefacts
    • Vérifiez que les bons signes d'identité sont des artefacts.
    • Vérifiez les vulnérabilités finales des artefacts.

Des garde-corps, pas des mains courantes

En intégrant des garde-corps dans le pipeline CI/CD, les organisations peuvent appliquer systématiquement des protocoles de sécurité et aboutir à un produit sécurisé sans compter uniquement sur les développeurs pour garantir des mesures de sécurité complètes. En tenant compte du fait que les développeurs peuvent contourner les mesures de sécurité au nom du rythme de développement, l'approche des garde-fous rend ces décisions impossibles ou du moins visibles, afin qu'elles puissent être prises en compte – à la fois au niveau de la construction unique (par exemple, décider de la fiabilité des artefacts ) et au niveau organisationnel (comprendre ce que l'on peut et ne peut pas attendre des développeurs de l'organisation). Les outils automatisés peuvent signaler, voire bloquer, des vulnérabilités potentielles ou des problèmes de non-conformité avant que la nouvelle version ne soit mise en production ou livrée au client. Après tout, traiter un problème de sécurité pendant la phase de développement plutôt qu’après la livraison est en effet beaucoup plus simple, plus rapide et moins coûteux.

Il est impératif de reconnaître que si le virage à gauche encourage l'implication des développeurs dans les pratiques de sécurité, il ne devrait pas exonérer les autres parties prenantes (professionnels de la sécurité, ingénieurs DevOps et équipes d'assurance qualité) de leur rôle. Si vous êtes un responsable de la sécurité des produits, AppSec, DevSecOps ou RSSI, vous savez déjà que « déplacer vers la gauche » la responsabilité envers les développeurs ne vous enlève pas la responsabilité. Étant donné que la plupart des RSSI et leurs équipes ne sont pas issus de la R&D, les environnements de développement logiciel étaient historiquement hors de leur vue. Ils se concentrent traditionnellement sur la sécurité opérationnelle, la sécurité des réseaux et la connectivité inter-organisations. L’approche des garde-fous est un moyen d’amener « délicatement » les RSSI dans le Far West des environnements de développement, en reprenant le contrôle de ce dont ils sont responsables.. Par « délicatement », j’entends « de manière collaborative ». Étant donné que la sécurité des produits est un effort conjoint des équipes de sécurité et de développement, la collaboration entre ces entités est essentielle pour concevoir et mettre en œuvre des garde-fous robustes qui renforcent le pipeline CI/CD contre les menaces de sécurité potentielles sans entraver la vitesse de développement.

L’intégration des principes du virage à gauche avec la mise en place de garde-fous dans le pipeline CI/CD constitue un bon équilibre. Les développeurs restent responsables de l'écriture du code sécurisé et de la compréhension des principes de sécurité de base, tandis que l'équipe de sécurité décide des normes auxquelles le produit doit répondre pour être publié. Ensuite, les garde-corps sont automatisés en conséquence en outils et processus pour agir comme un filet de sécurité, surveillant et renforçant en permanence les normes de sécurité et la politique SDLC. Les garde-corps constituent une étape essentielle vers des produits sécurisés dès leur conception et par défaut.

Récapitulation

En conclusion, bien que bien intentionné, le concept de virage à gauche ne parvient pas à garantir une sécurité logicielle complète uniquement grâce à la participation des développeurs. Pour renforcer l'intégrité et la fiabilité de l'artefact logiciel final, les organisations doivent adopter la mise en œuvre de garde-fous au sein du pipeline CI/CD. Cette approche combinée améliore non seulement la sécurité des logiciels, mais favorise également un environnement collaboratif dans lequel les développeurs, les professionnels de la sécurité et les outils d'automatisation travaillent en synergie vers un objectif commun : créer des logiciels sécurisés.

Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.