Le secteur tech et SaaS dans le viseur des attaquants
Les entreprises tech ne sont pas simplement des cibles parmi d’autres. Elles sont des multiplicateurs d’impact. Quand un attaquant compromet un cabinet comptable, il accède aux données de ses clients. Quand il compromet un éditeur SaaS, il peut potentiellement atteindre des milliers d’utilisateurs finaux via une mise à jour corrompue, un accès API détourné ou un environnement cloud infiltré.
C’est ce qui rend la position des startups, éditeurs logiciels, ESN et SSII si particulière : elles se situent au carrefour de la supply chain logicielle. Chaque ligne de code produite, chaque pipeline CI/CD, chaque accès cloud représente un vecteur potentiel de propagation vers les clients en aval.
L’affaire SolarWinds en 2020 a rendu ce risque visible au niveau mondial : un code malveillant injecté dans le processus de build a compromis 18 000 organisations clientes, dont des agences gouvernementales américaines. En 2021, l’attaque Kaseya a touché entre 800 et 1 500 entreprises via un seul éditeur de logiciel de gestion IT. En 2023, l’attaque contre 3CX — un éditeur de VoIP utilisé par 600 000 entreprises — a montré que même les supply chain attacks peuvent être elles-mêmes des supply chain attacks : les attaquants avaient d’abord compromis un logiciel de trading pour atteindre 3CX.
Le code source : le trésor que les attaquants recherchent
Pour un cybercriminel, le code source d’un produit SaaS est une mine d’or. Il contient les algorithmes propriétaires, mais aussi les secrets : clés API, tokens d’accès, mots de passe de bases de données, configurations d’infrastructure. Le rapport GitGuardian 2024 a détecté plus de 12,8 millions de secrets exposés dans des commits publics sur GitHub. Dans les dépôts privés, le problème est encore pire parce qu’il reste invisible.
Les attaques de phishing ciblant les développeurs visent directement ces accès. Un faux email d’alerte de sécurité GitHub, une fausse notification de pull request, un faux message Slack signalant un incident en production — chacun de ces prétextes vise à récupérer les identifiants qui donnent accès aux dépôts de code.
Les pipelines CI/CD comme surface d’attaque
Les pipelines d’intégration et de déploiement continus (CI/CD) exécutent du code automatiquement, avec des privilèges élevés. Un attaquant qui compromet un compte ayant accès au pipeline peut injecter du code malveillant dans le processus de build, et ce code sera distribué automatiquement à tous les clients du produit. Le rapport Aqua Security 2023 a documenté une augmentation de 300 % des attaques ciblant les pipelines CI/CD entre 2021 et 2023.
Le phishing OAuth : l’attaque que les développeurs ne voient pas
L’OAuth consent phishing est une attaque taillée pour les environnements tech. L’attaquant ne vole pas un mot de passe : il convainc la victime d’autoriser une application tierce malveillante à accéder à ses données. Un email imite une demande d’autorisation Google Workspace ou Microsoft 365 (« L’application DevSync demande accès à votre calendrier et vos fichiers »). Un clic sur « Autoriser » et l’attaquant obtient un accès persistant qui survit au changement de mot de passe et contourne le MFA. Microsoft a documenté cette technique comme un vecteur en forte progression.
Ce que disent les chiffres
Notre analyse : 4 955 entreprises tech passées au crible
Nous avons analysé les configurations de sécurité email (SPF, DKIM, DMARC) des domaines de 4 955 entreprises du secteur tech et SaaS en France. Le constat : 21 % obtiennent un score faible (D, E ou F). C’est un ratio meilleur que la finance ou la santé, ce qui reflète la maturité technique supérieure du secteur. Mais 21 %, cela représente tout de même plus de 1 000 entreprises tech dont les domaines présentent des failles dans leurs protections email, facilitant l’usurpation de leur identité par des attaquants.
Mais la protection du domaine ne couvre pas le phishing entrant. Un DMARC en mode « reject » empêche l’usurpation de votre identité, mais ne bloque pas les emails de phishing envoyés depuis d’autres domaines vers vos collaborateurs. Sécurité technique et sensibilisation humaine sont deux couches complémentaires.
Les statistiques du secteur
Le Verizon Data Breach Investigations Report (DBIR) 2024 confirme que le secteur tech reste parmi les plus ciblés : 68 % des violations de données impliquent un facteur humain (phishing, erreur de configuration, vol d’identifiants). Pour les entreprises tech, l’accès initial par phishing ou ingénierie sociale représente le premier vecteur d’attaque.
Le coût moyen d’une violation de données dans le secteur technologique atteint 5,45 millions de dollars selon le rapport IBM Cost of a Data Breach 2024. Pour une startup SaaS française, un incident majeur peut signifier la perte de clients stratégiques et la remise en cause de certifications ISO 27001 ou SOC 2 obtenues au prix de mois d’efforts.
L’ANSSI a confirmé dans son Panorama de la cybermenace 2023 une augmentation des attaques ciblant les prestataires de services numériques et les éditeurs de logiciels, les attaquants exploitant leur position dans la chaîne d’approvisionnement pour atteindre les clients finaux.
L’univers open source, sur lequel reposent la plupart des produits SaaS, est également sous pression. Sonatype estime dans son rapport State of the Software Supply Chain 2024 que les attaques ciblant les registres de paquets (npm, PyPI, Maven) ont augmenté de 245 % en un an.
Les attaques qui visent votre secteur
Chaque secteur a ses prétextes de phishing. Les attaquants qui ciblent les entreprises tech utilisent le vocabulaire et les outils du quotidien des développeurs et des équipes produit.
OAuth consent phishing et faux SSO
L’attaquant envoie un email imitant Google Workspace, Azure AD ou Okta. Le message demande d’autoriser une application (« Security Audit Tool ») ou signale une anomalie de connexion. Le lien mène vers une vraie page d’autorisation OAuth, mais pour une application malveillante. L’utilisateur qui clique sur « Autoriser » donne un accès persistant à ses emails, calendrier et fichiers, sans jamais saisir son mot de passe. Le MFA est contourné puisque l’autorisation passe par le fournisseur d’identité légitime.
Fausses notifications CI/CD
Un email imite une notification GitHub Actions, GitLab CI ou Jenkins : « Build failed on main », « Security vulnerability detected in dependency », « Pipeline blocked: approval required ». Le lien redirige vers une page de connexion contrefaite qui capture les identifiants du développeur. Ce scénario est redoutable parce que les développeurs reçoivent des dizaines de notifications CI/CD par jour et les traitent par réflexe.
Dependency confusion et faux registres npm/PyPI
L’attaquant se fait passer pour un mainteneur de package ou un service de sécurité (Snyk, Dependabot, Socket) signalant une vulnérabilité dans une dépendance utilisée par l’entreprise. Le correctif proposé redirige vers un paquet malveillant au nom similaire au paquet légitime — une combinaison de phishing et de typosquatting appliquée aux registres de paquets.
Faux emails d’investisseurs et de clients pour les startups
Les startups en levée de fonds sont des cibles de choix pour le BEC (Business Email Compromise). L’attaquant usurpe l’identité d’un fonds d’investissement ou d’un prospect et envoie un « term sheet » ou un « NDA » sous forme de document partagé. Le lien demande une connexion à un faux portail DocuSign ou Dropbox. Les fondateurs, pressés de conclure, cliquent sans vérifier.
Vol d’identifiants GitHub et GitLab
Le spear phishing ciblant les comptes GitHub et GitLab est en forte progression. L’attaquant envoie un email imitant une alerte de sécurité (« Suspicious login from new location ») ou une notification de collaboration (« You’ve been added to repository acme/backend-api »). La page de connexion contrefaite utilise du typosquatting sur le domaine (githuub.com, gitiab.com). Un compte compromis donne accès aux dépôts privés, aux secrets stockés dans les variables CI/CD et aux artefacts de build.
SIM swapping ciblant les CTO et les fondateurs
Le SIM swapping cible les dirigeants techniques des startups et scale-ups. L’attaquant obtient un duplicata de la carte SIM du CTO auprès de l’opérateur, puis intercepte les codes SMS utilisés comme second facteur d’authentification. Cette technique d’ingénierie sociale donne accès aux comptes cloud (AWS, GCP, Azure), aux consoles d’administration SaaS et aux outils de gestion financière. Les CTO dont le numéro est publiquement associé à des comptes GitHub ou LinkedIn sont les plus exposés.
ISO 27001, SOC 2 et vos obligations
Trois cadres réglementaires et normatifs impactent directement vos obligations de sensibilisation au phishing.
ISO 27001 : la clause 7.3 et l’annexe A.6.3
L’ISO 27001:2022 est le standard de facto pour les éditeurs SaaS qui veulent accéder aux marchés entreprise. Les clauses relatives à la sensibilisation sont explicites :
- Clause 7.3 : l’organisation doit s’assurer que les personnes effectuant un travail sous son contrôle sont sensibilisées à la politique de sécurité de l’information, à leur contribution à l’efficacité du SMSI, et aux conséquences de la non-conformité.
- Annexe A.6.3 : les collaborateurs doivent recevoir une sensibilisation, une éducation et une formation adaptées en matière de sécurité de l’information, ainsi que des mises à jour régulières des politiques et procédures pertinentes pour leur fonction.
En pratique, l’auditeur vérifie que vous disposez d’un programme de sensibilisation récurrent, que les résultats sont documentés et que le programme est adapté aux risques de votre activité. Les simulations de phishing avec micro-formation contextuelle répondent à ces trois exigences.
SOC 2 : les critères CC1.4 et CC2.2
Le cadre SOC 2 est exigé par les clients américains et de plus en plus par les grands comptes européens. Deux critères de confiance (Trust Services Criteria) concernent directement la sensibilisation :
- CC1.4 : l’organisation démontre son engagement envers les compétences de ses employés. Cela inclut la formation continue en matière de sécurité.
- CC2.2 : l’organisation communique en interne les informations nécessaires au fonctionnement du contrôle interne, y compris les objectifs et les responsabilités en matière de sécurité.
Les auditeurs SOC 2 demandent des preuves concrètes : fréquence des campagnes, taux de participation, métriques d’amélioration. Un programme de simulation avec reporting automatisé fournit ces preuves sans effort administratif.
NIS2 : les éditeurs SaaS au-dessus des seuils
La directive NIS2 classe les fournisseurs de services numériques parmi les entités soumises aux obligations de cybersécurité. Les éditeurs SaaS et les prestataires cloud dont le chiffre d’affaires dépasse 10 millions d’euros ou qui emploient plus de 50 personnes entrent dans le périmètre.
Les obligations NIS2 comprennent :
- La gestion des risques cyber, incluant la formation et la sensibilisation du personnel
- La notification des incidents significatifs aux autorités compétentes (l’ANSSI en France)
- La sécurité de la chaîne d’approvisionnement, qui inclut la gestion des risques liés aux prestataires et sous-traitants
Pour les ESN et SSII qui fournissent des services à des entités elles-mêmes soumises à NIS2, les obligations remontent en cascade : vos clients exigeront des preuves de votre propre conformité.
Pour un panorama complet de vos obligations et de la manière dont nos rapports y répondent, consultez notre page Conformité.
Des scénarios de simulation adaptés à la tech
Les simulations de phishing efficaces reproduisent les attaques réelles. Les scénarios génériques ne trompent pas les développeurs. Les attaquants utilisent des prétextes techniques. Vos simulations doivent faire de même.
Fausses alertes de sécurité GitHub/GitLab
Un email reproduisant une alerte GitHub (« Potential security vulnerability detected in your repository ») ou GitLab (« Access token expiring in 24 hours ») redirige vers une page de connexion contrefaite. Ce scénario mesure la capacité des développeurs à vérifier l’URL et l’expéditeur avant de saisir leurs identifiants.
Fausses notifications Slack ou Microsoft Teams
Un email imite une notification Slack (« New message from #incident-response ») ou Teams (« You missed a message from your CTO »). Le lien mène à une fausse page de connexion. Les collaborateurs qui utilisent ces outils au quotidien sont conditionnés à cliquer rapidement sur ces notifications pour ne rien manquer.
Fausses alertes de facturation AWS, GCP ou Azure
Un email imite une notification de dépassement de budget cloud (« Your AWS bill exceeded $10,000 this month ») ou une alerte de sécurité (« Unusual API activity detected in your GCP project »). L’urgence financière ou sécuritaire pousse le destinataire à cliquer sans vérifier. Ce scénario cible les DevOps, les SRE et les CTO.
Fausses notifications de fuite de données client
Un email interne prétend qu’une fuite de données client a été détectée et demande de se connecter à un portail de gestion d’incident. L’urgence du sujet (données clients en production) déclenche une réaction immédiate chez les équipes techniques.
Faux liens de pull request et de code review
Un email imite une notification de code review (« @thomas requested your review on PR #1247: Fix critical auth bypass ») avec un lien vers une page de connexion contrefaite. Les développeurs traitent ces notifications par réflexe.
Fausses invitations de réunion board ou investisseurs
Un email imite une invitation à une réunion stratégique (board, comité d’investissement, réunion client) via un lien Google Calendar ou Zoom contrefait. Ce scénario cible les fondateurs et les managers qui répondent à ces invitations sans délai.
Chaque simulation ratée déclenche une micro-formation de 3 à 5 minutes sur les signaux d’alerte spécifiques au scénario. Pas de module générique : un retour contextuel qui parle le langage des développeurs et des équipes tech.
Protéger votre entreprise tech
La protection contre le phishing dans une entreprise tech suit quatre étapes progressives.
Étape 1 : Auditer votre sécurité email
Avant de former les équipes, vérifiez que votre domaine n’est pas vulnérable à l’usurpation d’identité. Un domaine sans DMARC en mode « reject », sans DKIM correctement configuré ou avec un SPF trop permissif permet à n’importe qui d’envoyer des emails en votre nom — y compris à vos clients. Pour un éditeur SaaS, un email de phishing envoyé depuis votre propre domaine à vos utilisateurs est un scénario catastrophe pour la confiance client.
Testez gratuitement la sécurité email de votre domaine en 30 secondes. Le rapport détaille votre configuration SPF, DKIM, DMARC et MTA-STS, avec des recommandations de correction prioritaires.
Étape 2 : Lancer une simulation de référence
La première campagne de simulation établit votre taux de clic de référence (baseline). Nous utilisons des scénarios adaptés à l’environnement tech : fausses alertes GitHub, faux emails CI/CD, fausses notifications cloud. Les entreprises tech partent souvent avec un taux de clic plus bas que les autres secteurs (15 % à 25 % en moyenne), mais les attaques qui les ciblent sont aussi plus sophistiquées. L’objectif est de descendre sous les 5 % en six mois.
Étape 3 : Former par micro-learning contextuel
Chaque collaborateur qui échoue à une simulation reçoit immédiatement une micro-formation de 3 à 5 minutes adaptée au scénario. Les développeurs reçoivent des contenus orientés sécurité applicative (vérification d’URL, inspection des en-têtes email, gestion des secrets). Les équipes commerciales et RH reçoivent des contenus sur le BEC et l’ingénierie sociale. Les CTO et fondateurs reçoivent des scénarios de whaling et de SIM swapping.
Étape 4 : Générer les rapports de conformité
Chaque campagne produit automatiquement les métriques attendues par vos auditeurs ISO 27001 et SOC 2 : taux de participation, taux de signalement, évolution du taux de clic par équipe, couverture des collaborateurs formés. Ces rapports sont exportables en un clic. Pour les entreprises soumises à NIS2, les données de sensibilisation documentent votre conformité à l’obligation de formation du personnel.
Votre domaine email est-il protégé contre l’usurpation d’identité ? 21 % des entreprises tech que nous avons analysées présentent des failles. Testez le vôtre gratuitement — le diagnostic prend 30 secondes et le rapport est immédiat.
Questions fréquentes
Pourquoi les startups SaaS sont-elles ciblées par le phishing ?
Les startups SaaS concentrent plusieurs actifs à forte valeur : code source propriétaire, données clients hébergées, secrets d'API et accès à des environnements cloud. Un attaquant qui compromet un compte développeur peut injecter du code malveillant distribué ensuite à tous les clients du SaaS. C'est le principe de l'attaque supply chain, et il rend chaque éditeur logiciel attractif pour les cybercriminels.
L'ISO 27001 impose-t-elle de sensibiliser les collaborateurs au phishing ?
Oui. La clause 7.3 de l'ISO 27001 exige que tous les collaborateurs soient sensibilisés à la politique de sécurité de l'information et à leur rôle dans sa mise en oeuvre. L'annexe A.6.3 impose des programmes de sensibilisation, d'éducation et de formation adaptés aux fonctions exercées. Les simulations de phishing avec formation contextuelle répondent directement à ces exigences.
SOC 2 exige-t-il un programme de sensibilisation à la sécurité ?
Oui. Le critère CC1.4 de SOC 2 exige que l'organisation démontre un engagement envers les compétences de ses collaborateurs en matière de sécurité. Le critère CC2.2 impose la communication interne sur les responsabilités de sécurité. En pratique, les auditeurs SOC 2 vérifient l'existence de programmes de sensibilisation récurrents et demandent les preuves de participation et les métriques d'amélioration.
Quels scénarios de phishing ciblent les développeurs ?
Les développeurs sont ciblés par des scénarios spécifiques à leur environnement de travail : fausses alertes de sécurité GitHub ou GitLab, faux emails de révocation de token npm, fausses notifications de facturation AWS ou GCP, et faux liens de pull request contenant des pages de connexion contrefaites. Ces scénarios exploitent les réflexes des développeurs face aux alertes techniques.
NIS2 s'applique-t-elle aux éditeurs SaaS ?
NIS2 classe les fournisseurs de services numériques (cloud, SaaS, plateformes) parmi les entités soumises à des obligations renforcées de cybersécurité, selon leur taille et leur chiffre d'affaires. Les éditeurs SaaS dépassant 50 salariés ou 10 millions d'euros de chiffre d'affaires entrent dans le périmètre. Les obligations incluent la gestion des risques cyber, la notification des incidents significatifs et la formation du personnel.
Comment mesurer l'efficacité de la sensibilisation dans une équipe technique ?
Trois métriques comptent : le taux de clic sur les simulations de phishing (qui doit baisser campagne après campagne), le taux de signalement (qui doit augmenter), et le temps de signalement (qui doit se réduire). Pour les équipes techniques, nous recommandons de comparer les résultats entre équipes de développement, équipes commerciales et fonctions support pour identifier les populations les plus exposées.