Outils de scan de vulnérabilités : acheter les licences ou externaliser en prestation de service ?

On a acheté une licence à 4.800 dollars il y a deux ans pour 60 endpoints. Au premier scan, l'outil nous a sorti 340 failles critiques et élevées. Deux de mes devs seniors ont passé trois semaines rien que pour comprendre les résultats, et plus de la moitié étaient des fausses alertes liées à la configuration. La licence coûtait 4.800 dollars, mais le temps dev nous est revenu à au moins 10.000 dollars.

Faites attention si vous externalisez. Beaucoup de cabinets de conseil font juste tourner ce même outil pro que vous envisagez d'acheter, collent leur logo sur le PDF généré et vous le revendent. Si vous prenez une prestation, blindez le contrat avec une clause de vérification manuelle et de tri des faux positifs, sinon vous jetez votre argent par les fenêtres.

Si vous achetez l'outil, vous allez devoir gérer la différence entre scan authentifié (credentialed) et scan réseau externe. Est-ce que vous allez déployer des agents ou scanner uniquement les IP publiques ? Sans expert en interne, la configuration et la gestion des droits de ces agents peuvent elles-mêmes créer de nouvelles failles de sécurité.

Pour trancher, regardez ces trois points : 1) Votre équipe a-t-elle le temps d'interpréter les scores CVSS et l'exploitabilité réelle des vulnérabilités ? 2) Vos clients exigent-ils la signature d'un auditeur tiers indépendant ? 3) Comptez-vous scanner seulement 4 fois par an ou l'intégrer à vos pipelines de déploiement continu ? Pour 4 scans par an, une licence en interne n'est absolument pas rentable.

on a eu le meme dilemme et on a acheté l'outil le premier mois on a scanné avec enthousiasme et après plus personne n'y a touché le dashboard est devenu tout roueg d'alertes. genre si vous avez pas les ressources en interne externaliser c'est clairement plus reposant pour l'esprit.

si on installe des scanners de vulnérabilités open source et gratuits sur notre propre serveur, est-ce que ça ne suffit pas pour atteindre le niveau de rapport d'entreprise exigé par les clients ? c'est quoi exactement la différence fondamentale ?

Pour répondre à la question de notre collègue débutant : les outils open source sont très bien pour la détection technique, mais les clients grands comptes recherchent généralement une conformité aux standards reconnus et une signature officielle en bas du rapport. En B2B, les auditeurs vérifient selon quelle méthodologie le rapport a été produit. Un rapport maison sans validation externe risque de vous bloquer en pleine phase de vente.

Demandez au prestataire si la prestation trimestrielle inclut une heure de réunion de remédiation (remediation call). Plutôt que de balancer bêtement le rapport brut aux développeurs, le fait qu'un consultant leur explique comment corriger les trois vulnérabilités prioritaires vous fera gagner un temps fou.

Je vais essayer.

La discussion part dans tous les sens, je recentre. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

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

Je suis du même avis. Si l'autorisation et le périmètre ne sont pas écrits, ne lancez pas ce test.

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

j'aimerais poser une question. ne comptez pas sur une seule messure de sécurité ; allez par couches.

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

Chez nous aussi.

Nous avons aussi bloqué au même endroit à une époque. Essayer de faire cela seul est la voie la plus coûteuse.

Je le note au cas où.

Nous avons vécu presque la même chose l'année dernière. franchement tous ceux qui se pressent sur outils de scan de vulnérabilités se heurtent au même obstacle.

Aucun processus sans suivi ne s'améliore car vous ne savez pas quoi corriger... Je le note au cas où.

Je n'ai aucune expérience en outils de scan de vulnérabilités, c'est pourquoi je pose la question. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Je le note au cas où.

Mes doutes sont levés, merci.

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