Checklist de sécurité avant de livrer une application développée en vibe coding

Avant de livrer une application développée en vibe coding, identifiez le commit exact de la release, scannez-le, puis testez ses frontières d’accès, sa gestion des secrets et ses scénarios de panne dans un environnement maîtrisé. Utilisez les résultats de vetkit comme des éléments à examiner aux côtés de vos tests et de votre configuration de déploiement. Un scan réussi ne prouve pas que l’application en production est sûre ni prête à être publiée.

Cette checklist porte sur la décision de mise en production, après la revue de code. Pour relire ligne par ligne les modifications d’un assistant, commencez par la checklist de revue du code généré par IA. Conservez les éléments ci-dessous avec la release, afin qu’une autre personne puisse savoir ce qui a été vérifié.

1. Rattacher les preuves à la release

• Notez le SHA du commit et l’artefact de build que vous comptez déployer.
• Vérifiez que le rapport d’audit mentionne bien ce même commit. Un rapport portant sur une ancienne tête de branche ne couvre pas les correctifs ultérieurs ni les fichiers générés.
• Buildez le projet et exécutez ses tests à partir de cette version, avec une configuration maîtrisée et des données synthétiques. Conservez les résultats réels des commandes, y compris les échecs et les tests ignorés.

2. Vérifier ce qui a réellement tourné

Le Security Quick Scan comprend la posture, la détection de secrets avec gitleaks et les contrôles de dépendances avec OSV. Des audits plus larges peuvent inclure des contrôles supplémentaires lorsque votre compte et le périmètre choisi le permettent. Le modèle « release » de vetkit sélectionne des contrôles dans des domaines comme l’analyse statique de sécurité, l’infrastructure, les workflows et l’exploitabilité, mais il ne comprend pas tous les analyseurs disponibles. Par exemple, secrets-history et llm-app ne font pas partie de la sélection de ce modèle.

Un rapport partiel signifie qu’un ou plusieurs analyseurs ne sont pas allés au bout et que les catégories concernées peuvent être sous-représentées. Comblez les lacunes de couverture pertinentes ou documentez la vérification alternative avant de vous fier au résultat.

3. Éprouver les frontières d’accès

Dans un environnement de test, créez deux comptes ordinaires et un compte disposant de privilèges élevés. Essayez de lire et de modifier les enregistrements d’un compte en étant connecté avec l’autre, et appelez des endpoints protégés sans être connecté. Vérifiez que le serveur rejette les opérations non autorisées même lorsque l’interface du navigateur masque le bouton. Incluez les téléchargements de fichiers, les exports et les traitements en arrière-plan qui utilisent les mêmes données.

Pour une application adossée à Supabase, examinez les politiques de row-level security et de stockage déployées à l’aide d’enregistrements synthétiques. Les règles vibe-stack de vetkit peuvent signaler des schémas de code pris en charge, comme des politiques de row-level security absentes ou trop permissives et des buckets de stockage publics. L’inspection du code source ne permet pas d’établir la configuration actuelle de votre base de données hébergée ni de prouver l’isolation entre tenants.

4. Vérifier les secrets et les ressources du navigateur

Examinez les résultats concernant les secrets, les préfixes publics des variables d’environnement et les ressources générées pour le navigateur. Gardez les identifiants des fournisseurs et les clés service role côté serveur. Un audit de dépôt ne peut pas voir un secret de déploiement absent des fichiers scannés, et il n’inspecte pas automatiquement le bundle déployé côté navigateur. Si un identifiant a été exposé, révoquez-le ou renouvelez-le ; supprimer la ligne du code source ne suffit pas. Le guide sur les secrets divulgués explique les contrôles distincts du dépôt, de l’historique et du navigateur.

5. Examiner les dépendances et les fonctionnalités IA

Utilisez le lockfile prévu pour la release et examinez les résultats concernant les dépendances. Une recherche de vulnérabilités connues ne permet pas d’établir qu’un paquet inconnu est digne de confiance. Vérifiez les noms des paquets nouvellement introduits et leur provenance ; voir le guide sur les paquets hallucinés.

Si votre application appelle un LLM, testez ce qui se passe avec une entrée surdimensionnée, des erreurs du fournisseur et une sortie qui demande une opération privilégiée. Fixez des limites d’usage côté serveur et exigez une autorisation autour des outils qui modifient des données. Les règles llm-app de vetkit identifient des schémas pris en charge, comme une sortie de modèle exécutée en tant que commande ou SQL et des appels déclenchés par l’utilisateur sans limite de tokens en sortie. Elles ne démontrent pas que chaque tentative d’injection de prompt échouera et ne mesurent pas vos contrôles de dépenses en production.

6. Tester les scénarios de panne et la reprise

• Simulez le timeout d’une dépendance et une écriture qui échoue. Vérifiez que l’utilisateur obtient un état d’erreur utile et qu’une nouvelle tentative ne duplique pas l’opération en silence.
• Vérifiez la commande de démarrage en production, le reporting de santé et le reporting d’erreurs. Utilisez des pannes synthétiques pour confirmer que l’opérateur prévu peut repérer une release défectueuse sans que des identifiants soient journalisés.
• Répétez la procédure de rollback ou de reprise dans un environnement de test. Si la release modifie des données stockées, vérifiez séparément le chemin de reprise ; revenir à l’ancien code applicatif peut ne pas restaurer ces données.

vetkit comprend des règles statiques pour des schémas comme les appels sortants sans timeout, les serveurs de développement dans les commandes de démarrage en production et une synchronisation de schéma potentiellement destructrice. Ces résultats peuvent orienter votre revue, mais l’audit n’exécute pas cette répétition de panne et ne restaure pas de sauvegarde à votre place.

7. Consigner la décision de mise en production

Conservez ensemble le commit, l’identifiant du build, le périmètre de l’audit, les résultats des tests et les vérifications du déploiement. Traitez les identifiants exposés et les accès non autorisés avérés avant de livrer. Pour les résultats restants, consignez les éléments de preuve, l’impact, le responsable de la décision et la date de suivi. Si un analyseur pertinent a échoué ou si un comportement critique n’a jamais été testé, rendez cette lacune explicite au lieu de considérer le silence comme une approbation.

Sources et limites

Vérifié le 1er novembre 2026 par rapport à la configuration du Quick Scan de vetkit, à ses modèles d’audit, à son formateur de rapports et à ses règles vibe-stack, llm-app, resilience, data-access et operability. Le catalogue public de contrôles décrit les règles maison et les langages qu’elles prennent en charge ; la documentation décrit la configuration des audits. La disponibilité des analyseurs, les schémas pris en charge, les limites de scan et le périmètre choisi influent sur la couverture.

Les vérifications manuelles décrites ici sont le travail de votre équipe ; elles ne signifient pas que vetkit réalise des tests d’intrusion en conditions réelles, exécute la suite de tests de votre application ou certifie une release. Un audit du code source ne peut pas vérifier chaque permission de production, chaque réglage de déploiement ni chaque exigence métier. Gardez ces vérifications dans votre processus de release, même quand le rapport ne contient aucun résultat.