Contexte et enjeux

Face à l’explosion des modèles d’IA capables de détecter des centaines de failles dans le code, les fournisseurs de bases de données voient leurs cycles de correctifs s’allonger et s’accélérer. Oracle a testé en mars le modèle Mythos, reçu en accès anticipé, qui a mis en évidence des vulnérabilités jugées « code red ». Cette première alerte a conduit l’entreprise à intégrer les découvertes dans son patch trimestriel, qui a corrigé plus de 1 400 vulnérabilités sur l’ensemble du portefeuille.

Approche Real Application Testing

Pour éviter que ces correctifs massifs n’introduisent de régressions, Oracle mise sur Real Application Testing (RAT). La solution capture le trafic réel d’une charge de travail – requêtes, transactions, procédures stockées – puis le rejoue contre une instance mise à jour. Ainsi, chaque modification du code ou du schéma est évaluée dans le même contexte que la production, ce qui permet de détecter les incompatibilités avant le déploiement. Le processus repose sur deux composantes : un enregistreur qui crée un jeu de données de référence et un moteur de replay qui compare les métriques de performance et d’intégrité post‑patch. Cette méthodologie réduit le risque de rupture dans des environnements critiques, comme les systèmes nationaux ou industriels cités par Oracle.

Deep Data Security et contrôle d’accès

Parallèlement, Oracle a lancé en avril Deep Data Security, une couche d’autorisation qui transmet l’identité de l’utilisateur sous forme de token chiffré jusqu’au moteur de base de données. Le token est généré par le système d’authentification en amont et reste inchangé, même lorsqu’il transite vers des bases distantes, des lacs de données ou des tables associées. Cette approche force les agents d’IA à opérer avec les mêmes droits que l’utilisateur humain, empêchant ainsi un contournement des règles de sécurité au niveau applicatif. Oracle étend également le modèle aux SQL Assertions, qui déclarent des contraintes métier (par ex. limites de crédit) directement dans le SGBD. Toute modification via SQL est alors validée contre ces assertions, garantissant que les règles restent inviolables quel que soit le point d’accès.

Analyse des limites et perspectives

Ces deux initiatives reposent sur des hypothèses fortes : la capacité du token à être correctement propagé dans tous les services, et la fidélité du replay RAT à reproduire les conditions de production. Le chiffrement du token introduit une surcharge cryptographique qui peut impacter la latence, surtout sur des workloads à haute fréquence. De plus, les SQL Assertions, bien que puissantes, exigent une définition exhaustive des règles ; toute omission crée une surface d’exposition. Enfin, la dépendance à un modèle IA externe (Mythos) implique un risque de « black‑box » : les vulnérabilités détectées ne sont pas toujours reproductibles ou priorisables sans analyse humaine. Malgré ces contraintes, l’intégration de l’IA dans le cycle de test et la migration du contrôle d’accès vers le niveau des données constituent une réponse technique cohérente aux défis posés par l’IA générative dans les environnements de bases de données.