L’IA change qui décide quel logiciel entre dans votre organisation

L’IA est devenue une partie intégrante du développement de logiciels. Des générateurs d’API et de tests à la création de applications entières, les assistants de codage aident les équipes d’ingénieurs à résoudre des problèmes et à livrer des logiciels plus rapidement que jamais. Les gains de productivité sont indéniables, et les organisations adoptent rapidement l’IA à travers tout le cycle de vie du développement de logiciels.

La plupart des conversations ont porté sur le code généré par l’IA. Les développeurs peuvent-ils faire confiance au code généré par l’IA ? Introduit-il des vulnérabilités ? Comment les équipes de sécurité doivent-elles l’examiner ? Ces questions sont importantes, mais elles ne constituent pas le plus grand changement que l’IA apporte au développement de logiciels. L’IA est allée au-delà de la simple génération de code et influence de plus en plus les premières décisions de sélection de logiciels qui façonnent les logiciels qui entrent dans une organisation.

Les assistants de codage IA construisent rarement des applications à partir de zéro et composent des solutions à l’aide de frameworks existants, de bibliothèques open source, de SDK, d’images de conteneurs et d’écosystèmes de packages. Chaque recommandation façonne les fondations logicielles sur lesquelles une application est construite, souvent avant qu’un développeur n’examine la première ligne de code généré.

Pendant des décennies, la première décision de confiance dans le développement de logiciels appartenait presque entièrement aux développeurs, mais cette hypothèse commence à changer. De plus en plus, l’IA fait la première recommandation, tandis que les développeurs valident le résultat par la suite. Ce changement subtil a des implications importantes pour la sécurité de la chaîne d’approvisionnement logicielle, car chaque recommandation comporte une décision de confiance implicite.

Les organisations ont passé des années à réglementer la façon dont les logiciels sont construits, testés et déployés. Le prochain défi est de réglementer la façon dont les logiciels sont sélectionnés dans un environnement de développement natif IA.

La première décision de confiance

Chaque application dépend de logiciels créés par des milliers de contributeurs à travers des projets open source innombrables. Avant d’introduire une nouvelle dépendance, les développeurs évaluaient généralement la documentation, comparaient les frameworks, examinaient l’adoption de la communauté, examinaient la cadence de publication et considéraient si un projet était suffisamment mature pour la production. Les développeurs ne faisaient pas toujours le bon choix, mais chaque dépendance était introduite délibérément.

Aujourd’hui, un développeur peut simplement demander à un assistant IA de “construire une API REST sécurisée avec authentification et prise en charge de PostgreSQL.” En quelques secondes, l’IA génère un projet fonctionnel. Au passage, elle recommande un runtime, sélectionne un framework, référence une image de conteneur de base, importe des bibliothèques d’authentification, choisit des SDK, et génère des manifestes de dépendances tels que package.json, requirements.txt ou pom.xml. Les gestionnaires de packages résolvent ensuite ces dépendances et leurs dépendances transitives pendant le processus de construction.

La plupart des développeurs examinent l’application que l’IA produit, mais seuls quelques-uns s’arrêtent pour examiner chaque décision logicielle que l’IA prend en cours de route. L’IA a compressé la sélection de logiciels qui prenait autrefois des heures de recherche en quelques secondes et fait de plus en plus la première recommandation au nom des développeurs.

Chaque recommandation est une décision de confiance

Chaque artefact logiciel porte sa propre chaîne de confiance. Une bibliothèque a des maintainers, des contributeurs, des processus de publication, des pratiques de signature, des dépendances et une provenance. Une image de conteneur hérite de logiciels de distributions en amont, et un SDK introduit des packages supplémentaires, chacun prolongeant cette chaîne de confiance.

Une recommandation IA peut rapidement s’étendre à des centaines d’artefacts logiciels qui deviennent partie intégrante d’une application. L’open source a toujours fonctionné de cette manière. Ce qui change, c’est qui prend ces décisions de confiance en premier. Historiquement, les développeurs évaluaient et sélectionnaient les composants qu’ils faisaient confiance. De plus en plus, les systèmes IA font les recommandations initiales, tandis que les développeurs valident le résultat par la suite.

Cela peut sembler un petit changement, mais cela modifie fondamentalement la façon dont les organisations devraient penser à la sécurité de la chaîne d’approvisionnement logicielle.

L’IA optimise pour les logiciels fonctionnels, pas pour la confiance organisationnelle

Cela ne signifie pas que l’IA fait de mauvaises recommandations. Au contraire.

Les assistants de codage IA sont bons pour recommander des logiciels car ils ont appris à partir de millions d’exemples de la façon dont les développeurs résolvent des problèmes similaires. En conséquence, les frameworks populaires, les bibliothèques bien prises en charge et les modèles de mise en œuvre familiers apparaissent naturellement dans leurs suggestions, et c’est précisément ce qui rend ces outils si précieux.

Mais ces objectifs d’optimisation sont fondamentalement différents des questions que les équipes de sécurité d’entreprise doivent résoudre. L’IA n’évalue pas si un package correspond aux politiques logicielles d’une organisation, si une image de conteneur a été reconstruite à partir de la source, si la provenance logicielle a été vérifiée ou si une dépendance provient d’une source logicielle approuvée.

La fonctionnalité, la popularité et la probabilité sont des signaux utiles pour générer du code, mais ils ne devraient jamais être utilisés comme substituts à la vérification.

Pourquoi nous devons intégrer à gauche

Pendant des années, la sécurité de la chaîne d’approvisionnement logicielle s’est concentrée sur l’identification des risques après que le logiciel soit entré dans le processus de développement. Les analyseurs de vulnérabilités, l’analyse de composition de logiciels et les SBOM ont considérablement amélioré la visibilité des logiciels que les applications contiennent.

Ces outils restent essentiels, mais ils s’adressent à une autre partie du problème.

L’IA déplace la sélection de logiciels beaucoup plus tôt dans le cycle de vie du développement, donc lorsque les contrôles de sécurité traditionnels commencent leur analyse, le projet généré peut déjà référencer des dizaines de dépendances qui nécessitent une évaluation, une correction ou un remplacement. Les organisations réagissent encore aux choix de logiciels qui sont déjà entrés dans le flux de travail de développement.

C’est pourquoi je crois que les organisations ont besoin d’intégrer à gauche.

L’idée derrière l’intégration à gauche est simple : la confiance doit être établie avant que le logiciel ne fasse partie d’une application, et non après. Alors que l’IA devient un participant actif dans le développement de logiciels, ce principe devient encore plus important. La gouvernance doit se déplacer au point où le logiciel est sélectionné, et non où il est finalement analysé.

Les organisations doivent définir des sources logicielles de confiance, établir quels artefacts logiciels l’IA est autorisée à recommander et vérifier ces artefacts avant qu’ils ne deviennent partie du flux de travail de développement. L’objectif est de garantir que l’IA accélère la livraison de logiciels dans des limites qui reflètent les normes de sécurité, de conformité et d’ingénierie de l’organisation.

Réglementer la sélection de logiciels à l’ère de l’IA

Les organisations définissent déjà où les logiciels peuvent s’exécuter, comment ils sont déployés et qui est autorisé à les publier. De plus en plus, elles devront également définir quels logiciels l’IA est autorisée à recommander.

C’est là que la posture de la chaîne d’approvisionnement logicielle devient de plus en plus importante. Les organisations ont besoin de confiance non seulement dans les logiciels qu’elles construisent, mais également dans les logiciels que l’IA recommande en leur nom. Cette confiance vient de la vérification, des sources logicielles de confiance et de la gouvernance qui commence avant que le logiciel n’entre dans le pipeline de développement.

L’IA continuera à transformer le développement de logiciels, et à juste titre. Les gains de productivité sont trop importants pour être ignorés, mais alors que les organisations adoptent le développement natif IA, elles doivent reconnaître que la sélection de logiciels devient de plus en plus automatisée.

Les organisations qui réussiront seront celles qui établiront des sources logicielles de confiance, vérifieront les artefacts logiciels que l’IA recommande et intégreront la gouvernance dans la sélection de logiciels dès le début.

L’IA change la façon dont les logiciels sont écrits, mais maintenant, plus important encore, elle change la façon dont les logiciels sont choisis. Parce que dans l’ère de l’IA, les logiciels auxquels vous faites confiance dépendent de plus en plus des logiciels que votre IA choisit en premier.