DevSecOps pour IBM i

La transformation numérique et l’adoption du cloud à grande échelle ont vu les logiciels devenir la première cause de risque commercial et opérationnel. Les architectures applicatives complexes impliquant des interactions entre plusieurs couches technologiques ont augmenté la surface d’attaque de nombreux systèmes logiciels. Les nouveaux paradigmes informatiques, tels que l’informatique sans serveur, l’API-first et les microservices, ont évolué rapidement et ne sont pas toujours conçus en tenant en compte en priorité la sécurité.
Au même moment, l’industrie du logiciel a vu les techniques DevOps introduire de nouvelles efficacités dans la livraison des logiciels. Pourtant, ces cycles de développement accélérés ne permettent souvent pas de détecter les failles de sécurité en temps voulu, ce qui contribue à un risque global de sécurité. Des failles imprévues dorment dans le code développé à la hâte et dans les bibliothèques sur lesquelles il est construit.

DevOps a également changé la façon dont la sécurité est gérée. Traditionnellement, la vérification de la sécurité était une phase distincte effectuée vers la fin du cycle de vie du développement logiciel par une équipe dédiée. Cependant, dans les implémentations DevOps modernes, cette approche cloisonnée peut être une source de conflit. Pour éviter un goulot d’étranglement dans la livraison, la sécurité doit devenir une préoccupation permanente, une responsabilité partagée entre tous les acteurs impliqués, à travers les équipes de développement, d’assurance qualité, d’exploitation et de sécurité de l’information.
Face aux nouveaux risques liés à la transformation numérique et aux environnements cloud « toujours actifs », la sécurité doit être intégrée à la création de logiciels – la sécurité dès la conception, et non après coup. En intégrant la sécurité dans le cycle DevOps, nous obtenons DevSecOps.

Derrière toute mise en œuvre réussie de DevSecOps se cache l’automatisation. Aujourd’hui, la plupart des failles de sécurité sont dues à l’erreur humaine. Les examens manuels par les pairs risquent de laisser des failles de codage non détectées. Les tests manuels et sporadiques permettent aux failles de se propager dans les environnements de production. Le déploiement et les correctifs ad hoc ne permettent pas de détecter les logiciels non sécurisés au moment le plus critique du cycle.

Pour minimiser les risques, chaque phase successive du cycle DevSecOps doit être automatisée et continue. En automatisant une série de points de contrôle de qualité sécurisés, « shift security left » évite les retouches coûteuses.

L’IBM i est l’une des plateformes les plus sûres jamais créées pour les entreprises. Il possède cinq niveaux de sécurité progressivement impénétrables intégrés au système d’exploitation.

Alors pourquoi IBM i aurait-il besoin du DevSecOps ? Au fur et à mesure que les applications IBM i sont mises à jour et intégrées à des applications et des dispositifs externes, le code traditionnel est exposé en tant que services Web, ce qui crée une toute nouvelle série de risques tels que l’injection SQL et les API non sécurisées. Pour identifier ces nouvelles menaces, les équipes DevSecOps s’appuient sur des techniques d’analyse statique du code qui appliquent des règles de contrôle de qualité telles que celles recommandées par la communauté OWASP.

N’oublions pas non plus que les menaces internes représentent entre 60 et 75 % des violations de données. Même le système d’entreprise le plus sûr s’appuie sur des techniques automatisées d’anonymisation des données pour atténuer les risques et empêcher l’accès non autorisé aux données sensibles.

De nombreuses mises en œuvre DevOps ont été construites en regroupant des outils « ponctuels » non intégrés et faiblement reliés. Il est donc beaucoup plus difficile de mesurer les niveaux de qualité et de sécurité et de gérer les risques. Le dicton « ce qui ne se mesure pas ne se gère pas » s’applique aussi bien à la sécurité qu’à tout autre aspect du développement logiciel.

Pour assurer la conformité dans les environnements hybrides d’aujourd’hui, les équipes DevSecOps ont besoin d’une vision globale de la sécurité, de l’analyse des applications au déploiement, en passant par de multiples technologies et plateformes. Cela n’est possible qu’avec un ensemble d’outils intégrés, un référentiel partagé et un point unique de reporting et de contrôle.