La commande de revue de sécurité de Claude présente des limites pour les systèmes de production.

Portée de la commande de revue de sécurité

Le développeur a utilisé la commande de revue de sécurité de Claude lors du développement de cloakbioguard.com, en l'exécutant après des morceaux de code avant les commits Git. Elle a aidé pour les tâches de validation de base : restreindre les téléchargements à des types d'images spécifiques, valider la structure, imposer des limites de taille et de dimensions, et rejeter les entrées manifestement mauvaises.

Vérification de la réalité en production

Après le lancement, la rencontre avec un utilisateur suspect avec un nom de style spammeur et une fausse carte de crédit a révélé le besoin d'une sécurité plus approfondie. Le développeur a réalisé que la validation de base n'était pas suffisante et a identifié des questions critiques qui ont émergé :

• Quel code analyse les octets non fiables ?
• Quels secrets résident dans le même runtime ?
• Que peut atteindre ce runtime sur le réseau ?
• Si l'analyse d'image est exploitée, quel est le rayon d'impact ?
• Un attaquant peut-il passer du traitement de fichiers à la facturation, à l'administration, au stockage ou aux systèmes internes ?

Solution architecturale

La réponse a été un sprint de deux semaines avec des changements architecturaux significatifs. Au lieu de faire gérer tout par l'API principale, le traitement des fichiers a été séparé dans un worker de téléchargement distinct avec des limites de confiance différentes.

Le nouveau flux :

• L'API principale accepte les requêtes et effectue uniquement une validation légère
• Les téléchargements bruts sont écrits dans des buckets d'ingestion à courte durée de vie
• L'API crée des jobs et les publie dans une file d'attente
• Un worker séparé traite les images de manière asynchrone
• Le worker lit les fichiers bruts, les scanne, les normalise, écrit les résultats dans des buckets de sortie et met à jour le statut du job
• Les clients reçoivent les résultats via des URLs signées à courte durée de vie

Avantages en matière de sécurité

Cette architecture offre plusieurs avantages de sécurité :

• L'analyse de fichiers non fiables ne se trouve plus à côté de la logique API sensible
• Le worker a des permissions strictement délimitées : peut lire les objets d'ingestion, écrire les objets de sortie et consommer des jobs
• Le worker ne possède pas les secrets Stripe, les clés d'administration ou un large accès interne
• S'exécute sous un compte de service dédié avec le principe du moindre privilège

Durcissement réseau

Le worker de téléchargement s'exécute via un connecteur VPC avec un égress restreint. Au lieu d'autoriser un trafic sortant arbitraire, l'accès est explicitement limité à :

• Les API Google requises
• DNS
• Seulement des destinations approuvées de manière étroite si nécessaire

Tout le reste est refusé par défaut. Cette restriction réduit la probabilité qu'un worker compromis puisse émettre des signaux, exfiltrer des données ou atteindre une infrastructure arbitraire.

Conclusion clé

La commande de revue de sécurité de Claude a aidé à sécuriser le point de terminaison mais n'a pas créé la conception système que le développeur considère plus proche de la norme industrielle. L'expérience souligne que les vérifications de sécurité automatisées sont utiles pour la validation de base mais insuffisantes pour une sécurité de production complète qui nécessite une réflexion architecturale sur les limites de confiance et le rayon d'impact.