Comment assurer la sécurité de vos applications malgré l’externalisation de leur développement ?

 

L’intégration de la sécurité dans les projets est un processus important pour les entreprises pour définir et intégrer les aspects sécurité au plus tôt dans les produits. Cela évite d’augmenter le coût des remédiations si celles-ci n’ont pas été prévues et sont implémentées en fin de projet.

Dans le cadre de développements, l’Agile Security et le DevSecOps définissent les processus et outils à mettre en place pour intégrer la sécurité au plus tôt, comme présenté dans notre article précédent donnant des exemples.

Ces méthodes sont souvent définies sur les développements internes. Cependant, il est fréquent que les entreprises fassent appel à des prestataires externes pour développer une application ou une fonctionnalité particulière. Dans ce cas, il est important de s’assurer que ces prestataires suivent des pratiques de sécurité rigoureuses et qu’ils intègrent la sécurité dans leurs processus de développement aux mêmes standards que le demandeur. Ce qui amène la question suivante :

 

Développements externes : comment maintenir la confiance dans le code développé de manière externalisée ?

Dans la suite de cet article, nous entendons par code externe l’ensemble des éléments de code qui n’ont pas été développés en passant par une chaîne CI/CD internalisée. Par exemple, un développeur freelance utilisant la chaîne CI / CD interne ou un poste de travail entreprise n’est pas considéré comme un code externe.

Par ailleurs, nous considèrerons deux modèles de livraison d’applicatif en fonction du modèle de développement utilisé par le prestataire :

• la livraison du code source lui-même
• la livraison de l’exécutable, c’est-à-dire le code déjà précompilé

Il est important de noter que ces deux modèles de livraison d’applicatif ont des implications différentes en termes de cybersécurité et de DevSecOps.

 

Livraison de code

Dans le cas d’une livraison de code, les prestataires externes remettent le code qu’ils ont écrit, généralement sous forme de fichiers sources (par exemple des fichiers .java pour du code Java), à l’entreprise. Cette dernière peut alors auditer, compiler et déployer le code sur ses propres serveurs.

La livraison de code présente plusieurs avantages. Le premier avantage repose sur la flexibilité : en livrant le code source, l’entreprise peut facilement effectuer des modifications et personnalisations sur le code. Elle peut également intégrer le code dans son environnement de développement et de déploiement (CI/CD) existant contenant l’ensemble des outils de sécurité préconfigurés.

L’entreprise n’a alors pas à placer sa confiance dans la sécurité de la chaîne CI du prestataire sur laquelle elle n’a aucun contrôle. De plus, l’entreprise ayant accès au code source peut également l’auditer et ainsi vérifier qu’il est sécurisé. Ces audits tendent à être plus exhaustifs puisque l’auditeur a accès à beaucoup plus de détails sur le fonctionnement du code et peut effectuer à la fois une analyse statique et dynamique du code.

En revanche, la livraison de code présente certains inconvénients. L’entreprise doit disposer de compétences pour adapter les étapes de compilation et déploiement au contexte de production. Si elle ne dispose pas de ces compétences en interne, cela peut entraîner des coûts supplémentaires.x

Voici donc quelques bonnes pratiques afin de maximiser la confiance dans le code livré :

• Partager au plus tôt (contrat, réunion de lancement) les exigences attendues sur la sécurité dans le développement, les versions des logiciels, l’outillage utilisé en interne pour le déploiement, la confidentialité du code source, etc. Certains clients demandent à ce que les développeurs externes aient un certain niveau de certification ou de formation (par exemple, un palier de formation sur Secure Code Warrior, dans un certain langage de programmation).
• Définir et contractualiser les engagements sur les processus de remédiation des vulnérabilités identifiées après livraison du code et le suivi associé (outillage pour le suivi, SLA, etc.)
• Implémenter un contrôle de type hash ou signature sur le code envoyé pour en assurer l’intégrité et définir les modalités de transfert sécurisé du code source avec le prestataire
• Intégrer le code reçu dans la chaîne CI/CD existante y compris les fichiers d’Infrastructure as Code (IaC)
• Réaliser les tests fonctionnels sécurité définis initialement lors du threat modeling : Evil User Stories et Security Stories

 

Certaines organisations peuvent être confrontées à une situation où la notion de développeurs externes correspond à des développeurs d’autres entités au sein d’un même groupe. Ces entités peuvent avoir leur propres chaînes CI mais dépendre de la chaîne CD ou CI/CD de l’équipe centrale de production.

Dans ces cas, une interconnexion des différentes chaînes CI sur la chaîne CI/CD centrale peut être envisagée. Cette solution permet aux différentes équipes de développer avec les outils leur convenant au mieux.

 

Le niveau de sécurité assuré par la chaîne CI/CD projet est idéalement équivalent à celui de la production mais ce n’est pas nécessairement le cas. La chaîne CI/CD de production contrôle le code à déployer.

Cependant, le contrôle de la sécurité est souvent effectué trop tard dans le processus de développement. Pour garantir une sécurité efficace dans les développements, il est crucial de s’assurer que la sécurité est intégrée dès le début du cycle de développement (shift-left). Pour remédier à cela, il est recommandé d’offrir des outils de sécurité en libre-service pour les équipes projet afin qu’elles puissent identifier les vulnérabilités dès le début de leur développement en utilisant les outils cibles appropriés.

Dans le cas contraire, les outils de sécurité de la chaîne CI/CD de production permettront d’assurer la conformité aux règles du groupe sans ralentir la mise en production si des contrôles sécurités automatisés ont été mis en place au sein de la chaîne projet.

Cette solution permet aussi à la production de s’assurer de l’utilisation des images (systèmes, docker, etc.) ou des artefacts (bibliothèques) validés par l’entreprise.

Ces interconnexions entre les différentes pipelines peuvent par exemple cloner la branche voulant être déployée par l’équipe produit afin de les pousser en entrée de la chaine CD. Les équipes de production doivent cependant posséder les droits appropriés. Techniquement, le modèle de gestion des droits accordés (idéalement temporairement) doit répondre à la fois au besoin de faciliter l’exécution et au besoin de provision des droits (manuelle vs. automatique), tout en limitant l’accès à l’ensemble des branches ou des projets afin de respecter le principe du moindre privilège.

La majorité des bonnes pratiques citées précédemment s’appliquent aussi afin de réduire le temps de mise en production.

Bien que les méthodes décrites ci-dessus apparaissent comme les plus efficaces pour avoir un contrôle sur des applications développés par des tiers, les entreprises se retrouvent parfois à recevoir des exécutables sans accès au code source. Ceci peut par exemple être le cas pour des raisons de restrictions liées aux licences. Dans ce cas, certaines bonnes pratiques énoncées plus haut ne s’appliquent pas, il est nécessaire de repenser la manière d’intégrer les changements à la production pour ne pas négliger certains aspects sécurité.

 

Livraison d’exécutable

Dans le cas d’une livraison d’exécutable, les prestataires externes remettent un fichier exécutable (par exemple, un fichier .exe pour des serveurs Windows) qui peut être directement exécuté par l’entreprise sans compilation. Cette méthode de livraison est souvent utilisée pour les logiciels commerciaux qui nécessitent tout de même quelques ajustements de configuration.

Dans ce cadre, l’intégration dans la chaîne de déploiement est beaucoup plus limitée et seules quelques étapes classiques d’une CD peuvent être effectuées sans que les étapes de sécurité de la chaîne CI puissent être vérifiée :

• Réaliser un scan des artefacts
• Réaliser un scan DAST pour détecter les vulnérabilités les plus classiques
• Réaliser des tests d’intrusion

Les rapports des outils de sécurité de la chaîne du prestataire effectuant le développement peuvent aussi être demandés. Ceci doit être inscrit en amont dans le contrat de prestation, avec les exigences sécurité sur le niveau de sécurité du code.

Enfin, une signature du code pour s’assurer de son intégrité est nécessaire lors de l’échange et de l’exécutable. Privilégiez pour cela les signatures via certificats plutôt que les empreintes hash puisque celles-ci permettent de vérifier l’origine (non-répudiation) en plus de l’intégrité de l’exécutable.

 

Pour conclure, il est important pour les entreprises de s’assurer de la qualité et de la sécurité du code livré par les prestataires externes, surtout lorsque ces derniers développent du code sur des chaînes CI externes. Il existe plusieurs moyens de se convaincre de la sécurité du code livré :

• Des clauses contractuelles claires et précises peuvent aider à définir les attentes et les responsabilités de chacune des parties en ce qui concerne la qualité et la sécurité du code.
• Le partage des spécifications et des attentes en matière de sécurité avec les prestataires externes peut également aider à s’assurer que le code livré répond aux exigences de l’entreprise.
• L’intégration avec les outils de la chaîne de développement interne peut faciliter la vérification de la qualité et de la sécurité du code, ainsi que la mise en place de tests automatisés. Ces intégrations soulèvent des défis à la fois techniques et de processus qu’il faut anticiper pour faciliter le déploiement des développements externes.

En implémentant ces différentes approches, les entreprises peuvent renforcer leur confiance dans le code livré par les prestataires externes et s’assurer de la sécurité de leurs applications.