On a récupéré le code livré par l'agence — comment mener une revue de code sécurisée et par quoi commencer ?

Votre première urgence absolue : purger l'historique Git. Même si vous supprimez le mot de passe du fichier et faites un nouveau commit, ces identifiants restent visibles à jamais dans l'historique des commits. Utilisez un outil de scan de secrets open source pour fouiller tout l'historique, réécrivez-le pour purger les clés, et changez ces mots de passe sur vos serveurs sans attendre.

Demandez à votre développeur de lancer la commande d'audit de sécurité native de votre gestionnaire de paquets dès demain. Des bibliothèques vieilles de deux ans comportent très probablement des dizaines de failles de sécurité critiques déjà publiées. Le simple fait de mettre à jour ces paquets vers des versions stables et récentes éliminera déjà la moitié de vos risques.

L'année dernière, on a nous aussi lancé une analyse statique sur un projet de 30 000 lignes qu'on venait de récupérer. L'outil a remonté 142 alertes potentielles ; après vérification par notre dev, 8 d'entre elles étaient de vraies failles qui permettaient d'extraire la base de données. Corriger ces 8 failles ne nous a pris que trois jours.

Ne vous fiez pas trop aux outils d'analyse automatique, vous risquez de vous noyer sous des centaines de faux positifs dans un rapport de milliers de lignes. Les plus grosses fuites de données ne viennent pas des failles de bibliothèques, mais des simples erreurs de contrôle de session que le dev de l'agence a zappées en se disant 'de toute façon personne va essayer'. Mettez le paquet sur les tests manuels de logique métier.

une agence qui hardcode des mdp a surement meme pas verifie l'upload de fichiers. testez durgence si le client peut upload un script php executable a la place de ses docs cest la porte dentree la plus dangereuse.

Veuillez consigner l'ensemble des vulnérabilités identifiées dans une matrice des risques de sécurité d'entreprise. Classez les failles selon leur niveau de gravité : critique, élevé et moyen. Laisser le système en production et accessible aux clients sans avoir corrigé au préalable les failles critiques menaçant directement la base de données et la confidentialité des clients peut engager lourdement votre responsabilité juridique.

Épluchez à nouveau le contrat signé avec l'agence. La plupart des contrats contiennent une clause de garantie, explicite ou tacite, stipulant que le code doit être livré conformément aux standards du secteur et aux bonnes pratiques de sécurité. Intégrer des mots de passe en dur dans le code constitue un vice manifeste de prestation ; vous pourriez tout à fait être en droit de leur adresser une mise en demeure formelle pour exiger les corrections.

comment les outils d'analyse statique de code font-ils pour analyser le code sans l'exécuter ? comment ces outils peuvent-ils savoir avec certitude qu'une fonction contient une vulnérabilité sans déploiement sur un serveur de prod ni connexion à une base de données ?

Je n'ai aucune expérience en revue de code sécurisée, c'est pourquoi je pose la question. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup. Si vous avez des questions, écrivez-moi, je répondrai au mieux.

je me pose ausssi la question.

Cette approche a un coût, dont on ne parle pas. Si la double authentification est activée un mot de passe volé seul ne suffit pas.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

J'y pensais aussi. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

À votre place, j'irais par cette voie.

J'ai vécu la même chose. Quand on décide sans mesurer, on revient toujours au même point.

Voilà, désolé si je me suis étendu.

J'y pensais aussi. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard. Je le note au cas où.

trois poitns à vérifier lors de cette opération. les gens défendent l'habitude pas le processus.. mais la résistance vient de là.

Je suis dans la même situation c'est pourquoi je pose la question. bref si l'autorisation et le périmètre ne sont pas écrits ne lancez pas ce test.

Aucun processus sans suivi ne s'améliore car vous ne savez pas quoi corriger. C'est mon avis, je ne l'écris pas comme une vérité absolue.

Chez moi, c'est l'inverse qui s'est passé, c'est pourquoi j'écris. L'erreur commise du côté de revue de code sécurisée est généralement réversible, mais coûteuse.

Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Mes doutes sont levés merci. Le temps que vous mettez à détecter un problème détermine directement son coût.

Si vous avez des questions écrivez-moi je répondrai au mieux.