La prochaine brèche dans votre entreprise ne démarrera probablement pas par un zero‑day. Elle commencera par un entretien. Un récent rapport sur une offre d’emploi piégée envoyée via LinkedIn rappelle que les attaquants vont là où vos contrôles sont les plus faibles. En ce moment, c’est votre pipeline de recrutement : CV, projets à la maison, liens GitHub, invitations Calendly et messages WhatsApp aux recruteurs.
Si vous dirigez l’ingénierie dans une startup ou une scale‑up, traitez le pipeline d’embauche pour ce qu’il est : une chaîne d’approvisionnement logicielle tierce avec des chemins directs vers les laptops des développeurs, le CI et les identifiants de production. Vous n’avez pas besoin d’un budget sécurité de Fortune 500 pour corriger ça. Il vous faut un cadre de décision, quelques patterns d’architecture, et la discipline pour maintenir une forte vélocité d’embauche sans ouvrir grand la porte aux malwares.
Ce qui a changé : les contenus de recrutement sont des contenus exécutables
Nous avons normalisé des comportements risqués au nom de la vitesse. Considérez la boucle standard :
- Les recruteurs ouvrent des CV DOCX/PDF provenant d’expéditeurs inconnus sur des appareils d’entreprise.
- Les ingénieurs clonent des dépôts de candidats et exécutent des scripts de build pour revoir des solutions.
- Les hiring managers cliquent sur des liens de prise de rendez‑vous et des URL de « portfolios » dans des DMs.
- Les exercices à la maison demandent aux candidats de faire des npm install, pip install ou cargo build de paquets tiers.
C’est du contenu exécutable. Même « juste un PDF » peut lancer calc.exe si le viewer n’est pas à jour. Un package.json avec un prepare ou postinstall malveillant s’exécutera sur la machine du relecteur. Un Makefile peut exfiltrer des clés SSH. Un hook de pre‑commit dans un dépôt candidat peut discrètement aspirer des variables d’environnement. Et un message LinkedIn bien ficelé peut vous rediriger vers une page de connexion lookalike qui vole votre session IdP.
Quand on audite les rapports d’incident, deux ingrédients reviennent sans cesse : l’ingénierie sociale et un employé de confiance qui exécute du code non fiable. Le pipeline d’embauche offre les deux aux attaquants, sous le vernis du « c’est normal ».
Un cadre de décision pour CTO : trois plans de contrôle
Votre objectif est de convertir des interactions risquées et ad hoc en flux prévisibles et inspectables, sans tuer l’expérience candidat ni le débit des recruteurs. Les contrôles se répartissent sur trois plans :
- Politique d’entrée et UX — canaliser tout via un chemin durci. Pas de pièces jointes sauvages. Pas de liens surprises. Pas de partage de fichiers device‑to‑device.
- Isolation et inspection du contenu — faire exploser et désarmer documents et liens avant que des humains ne les ouvrent. Traiter le code comme des binaires non fiables.
- Isolation d’exécution pour le code candidat — faire tourner leur code dans votre bac à sable, pas sur les laptops de vos ingénieurs.
1) Politique d’entrée et UX : un pare‑feu pour les talents
Une politique sans UX, c’est du théâtre. Offrez aux recruteurs et aux candidats un chemin plus fluide que « envoyez‑moi votre CV par email ». Concrètement :
- Faites transiter tous les fichiers candidats par votre ATS (ou un simple portail d’upload) sur un sous‑domaine dédié, p. ex. apply.example.com. Désactivez les dépôts de fichiers non sollicités par email/DM. Répondez automatiquement aux pièces jointes avec un lien vers le portail.
- Interdisez DOC/DOCX et ZIP par défaut. N’acceptez que PDF et texte brut. Si vous recrutez à l’international (Brazil, LatAm) où DOCX est courant, convertissez automatiquement côté serveur et ne présentez au staff qu’un PDF assaini.
- Rendez la politique visible sur les annonces et les signatures des recruteurs : « Pour votre sécurité et la nôtre, nous n’ouvrons pas les pièces jointes envoyées par email ou LinkedIn. Merci d’utiliser notre portail. » Une friction polie vaut mieux qu’un compromis silencieux.
- Exigez une planification vérifiée par domaine. N’acceptez des liens d’entretien que depuis votre domaine (p. ex. calendar.example.com) ou un prestataire validé avec vérification de domaine. Bloquez les liens raccourcis aléatoires dans les DMs.
- Garde‑fous WhatsApp et SMS pour le nearshore : pas de fichiers, pas de liens. Uniquement des redirections vers le portail.
2) Isolation et inspection du contenu : désarmer avant l’humain
Créez un pipeline simple et fiable pour ingérer, scanner et présenter le contenu en sécurité :
- Passerelle de pièces jointes : placez devant l’endpoint d’upload de l’ATS un petit service qui stocke les originaux dans un bucket de quarantaine et les envoie dans une file de scan. Ne présentez au staff que des copies assainies.
- AV multi‑moteurs + YARA : utilisez au moins deux moteurs de signatures (ClamAV plus un moteur commercial, ou un service type VirusTotal API dans les limites de quota). Ajoutez des règles YARA pour les droppers de documents fréquents et du JavaScript ofusqué dans les PDFs.
- Assainissement des documents : faites tourner LibreOffice en mode headless dans un conteneur (gVisor/Firecracker) pour convertir DOCX en PDF/A. Pour les PDFs, rendez en images puis reconstruisez un PDF propre (perte de qualité, mais sûr). Proposez « l’original sur demande » derrière une porte d’approbation JIT.
- Détonation de liens : réécrivez les liens inconnus vers un service d’isolation de navigateur à distance (RBI) ou votre propre Chrome éphémère dans une VM sandbox. Enregistrez les beacons réseau et l’activité script. Ne montrez au viewer qu’un flux vidéo.
- Extraction de texte pour la recherche de CV : faites de l’OCR ou extrayez le texte à partir des documents assainis pour les workflows recruteurs, jamais depuis l’original.
Rien d’exotique ici. Deux fonctions sur Cloud Run ou Lambda suffisent pour quelques dollars à un seul chiffre par mille fichiers. L’isolation de navigateur peut être fournisseur (Cloudflare, Island) ou auto‑hébergée dans un petit pool de VM sans GPU avec Chrome headless. L’objectif n’est pas la détection parfaite — c’est d’empêcher le code attaquant d’atteindre directement les endpoints de vos employés.
3) Isolation d’exécution : traitez le code candidat comme une clé USB
Quand un ingénieur révise un exercice ou un repo de portfolio, partez du principe qu’il est hostile. Des contrôles qui maintiennent la vélocité :
- Bacs à sable de dev éphémères : faites tourner le code candidat dans un environnement jetable (Codespaces, Gitpod, VM Firecracker interne) sans accès au réseau corporate, sans tokens SSO, et avec l’egress limité à un miroir privé de paquets.
- Pas d’identifiants locaux : ne clonez pas de dépôts candidats sur les laptops locaux. Utilisez des IDE web ou SSH vers des sandboxes avec des clés éphémères liées à la session.
- Miroirs de paquets uniquement : bloquez l’accès direct à npm/pip/cargo. Miroitez le top 1 000 des paquets attendus et auditez les fetchs ad hoc. Beaucoup de scripts postinstall malveillants meurent au niveau du miroir.
- Secrets en lecture seule : si le challenge nécessite des API keys, fournissez des identifiants à portée unique et projet unique avec des TTL serrés (p. ex. 24 h) via le sandbox, jamais en clair.
- Vérifications statiques pré‑exécution : exécutez des scans légers avant le boot : grep des scripts suspects (postinstall, prepare), .git/hooks, curl/wget dans des Makefiles, et charges exécutables dans des dossiers non binaires.
Résultat : vos relecteurs n’exécutent jamais du code contrôlé par le candidat sur des appareils corporate ni avec des identifiants corporate. Vous préservez la vitesse car le « click‑to‑sandbox » est plus rapide que la configuration locale d’un environnement.
Schémas d’attaque à considérer d’emblée
- Macros et injection de templates dans des flux DOCX, PDF/JS ou objets OLE intégrés. Même si les macros sont désactivées, les outils d’aperçu et pilotes d’impression ont déjà eu des RCE.
- Dépôts piégés : hooks Husky de pre‑commit malveillants ; scripts postinstall dans package.json ; alias shell dans un rcfile fourni ; .editorconfig empoisonné ou extensions VS Code incitant à l’installation.
- Confusion de dépendances/typosquatting déclenchée pendant le build. Un challenge qui référence des paquets à consonance interne peut être armé si la machine du relecteur tente de les résoudre publiquement.
- Phishing via liens de prise de rendez‑vous : domaines lookalike ou pages de consentement OAuth qui siphonnent des sessions Google/Microsoft.
- « Portfolio ZIP » dropper reçu par email/DM, souvent protégé par mot de passe pour déjouer les scanners.
Mise en œuvre en 30/60/90 jours
Jours 0–30 : stopper l’hémorragie évidente
- Déclarez la règle : « Nous n’ouvrons pas de fichiers candidats envoyés par email/DM. Utilisez notre portail. » Ajoutez‑la aux annonces et aux signatures des recruteurs.
- Bloquez les types dangereux dans l’ATS : n’autorisez que PDF et TXT. Répondez automatiquement avec le lien du portail aux pièces jointes envoyées à recruiting@.
- Activez ce que vous payez déjà : Microsoft Safe Links/Safe Attachments ou Google Workspace Advanced Protection pour les groupes recrutement et hiring managers. Imposez les politiques « macros désactivées » dans Office et un comportement « aperçu uniquement » pour les PDF.
- Supprimez les droits d’admin local sur les appareils des recruteurs et des hiring managers. Ils ne doivent pas installer de viewers ou d’extensions au hasard.
- Mettez en place un sandbox basique : un template Gitpod/Codespaces partagé ou une image Ubuntu interne que les relecteurs peuvent lancer en moins de 60 secondes.
Jours 31–60 : construire le pipeline « boring »
- Passerelle de pièces jointes : derrière l’endpoint d’upload de votre ATS, ajoutez un service qui met les originaux en quarantaine, exécute ClamAV + un moteur secondaire, convertit DOCX en PDF/A, et reconstruit les PDFs à partir d’images. Stockez les copies assainies et n’exposez que celles‑ci au staff.
- Isolation des liens : réécrivez les liens inconnus vers un fournisseur RBI ou une ferme Chrome headless. Journalisez les appels réseau ; bloquez les téléchargements de fichiers par défaut.
- Contrôles pré‑exécution du code : ajoutez un job de pré‑vol repo qui signale les scripts postinstall/prepare, .git/hooks et Makefiles avec curl/wget. Échouez en fermé : seuls les relecteurs peuvent déroger.
- Miroir privé de paquets : déployez un simple proxy npm/pip (p. ex. Verdaccio, Nexus, Artifactory). Forcez les sandboxes à s’y approvisionner.
- Identifiants éphémères : distribuez des API keys par challenge via votre sandbox avec TTL 24 h et scopes par sandbox.
Jours 61–90 : rendre le tout indolore et difficile à contourner
- UX « un clic » pour les relecteurs : intégrez ATS‑>sandbox. Un relecteur clique sur « Open in Sandbox », ce qui clone le repo candidat dans une VM fraîche avec la bonne image et la bonne politique réseau.
- RBI par défaut pour les OUs recrutement et hiring managers. Les DMs s’ouvrent automatiquement en isolation ; seules les domaines en allowlist y échappent.
- Automatisez le workflow VIA (Verify, Isolate, Approve) : les originaux ne sont accessibles qu’après qu’un manager a accordé un accès JIT avec justification métier.
- Instrumentez des métriques : temps‑vers‑sandbox < 60 s ; pourcentage de CV assainis ; nombre de scripts risqués bloqués ; taux d’ouverture ATS‑>sandbox ; temps moyen entre tentatives de contournement.
- Faites un tabletop : menez un exercice de 90 minutes : « Un recruteur a ouvert un CV malveillant ; qu’est‑ce qui s’est allumé, qui a été pagé, qu’est‑ce qui a été bloqué et où avons‑nous échoué ? »
Coûts, arbitrages, et comment ne pas tuer la vélocité de recrutement
Soyons clairs : de la sécurité de façade qui ralentit l’embauche sera contournée. Vos contrôles doivent être plus rapides que la mauvaise habitude qu’ils remplacent.
- Performance : la conversion de documents doit se terminer en 1–3 secondes par fichier pour des CV typiques. Si cela prend 10+, le staff demandera les originaux. Traitez en batch et pré‑convertissez la nuit pour le backlog.
- Latence du sandbox : le SLA de votre sandbox relecteur doit être < 60 secondes du clic à un shell prêt. Pré‑chauffez les images et mettez en cache les dépendances dans votre miroir.
- Coûts de compute : attendez‑vous à ce que le scan et la conversion de pièces jointes restent dans l’épaisseur du trait de votre facture cloud pour des volumes typiques (centaines à quelques milliers de fichiers/mois). L’isolation de navigateur est la ligne la plus coûteuse ; commencez par la restreindre aux OUs recrutement/hiring.
- Faux positifs : les conversions déformeront parfois la mise en page d’un CV. Conservez les originaux mais cachez‑les derrière VIA. Formez les recruteurs à ne demander l’original que si la copie assainie est illisible.
- Expérience candidat : certains repousseront l’idée du portail et du code dans un sandbox. Expliquez la politique en amont. Pour les profils seniors, offrez le choix : environnement sandboxé (le plus rapide) ou revue de code en lecture seule de leur travail public (le moins frictionnel).
Brazil et réalités nearshore : WhatsApp, DOCX et PC d’internet café
Si vous recrutez en Brazil et en LatAm, adaptez le playbook aux normes locales sans baisser la garde :
- Réalité WhatsApp‑first : candidats et recruteurs tenteront de partager des fichiers via WhatsApp. Ne luttez pas contre le comportement humain ; co‑optez‑le. Créez un bot qui répond avec un message court et amical et un lien vers le portail. Aucun fichier n’est accepté en chat — jamais.
- Prévalence de DOCX : beaucoup de candidats utilisent des templates figés en DOCX. Convertissez automatiquement côté serveur et acceptez une légère perte de mise en page. Faites du PDF assaini l’artefact officiel.
- Risque d’appareils partagés : certains candidats réalisent les exercices sur des machines partagées ou anciennes. Votre sandbox les aide aussi — pas de setup local fragile, moins de temps perdu. C’est aussi un petit gain d’équité.
- Alignement des fuseaux : avec 6–8 heures de recouvrement, vous pouvez assurer des resets de sandbox et des sessions de revue dans la journée sans latence overnight.
Une architecture de référence « pare‑feu ATS »
Voici un pattern concret, indépendant des fournisseurs, que vous pouvez mettre en place en semaines, pas en trimestres :
- Ingress : le candidat charge son CV ou des liens sur apply.example.com. Les originaux atterrissent dans s3://recruiting-quarantine/... avec object lock activé.
- Scan : un événement déclenche un worker en file (Cloud Run/Lambda) qui exécute ClamAV + un moteur secondaire, des règles YARA basiques et une validation MIME.
- Assainir : le worker convertit DOCX en PDF/A via LibreOffice headless dans un conteneur gVisor ; les PDFs sont rendus en images puis reconstruits. Le texte est extrait à partir des artefacts assainis, jamais des originaux.
- Présenter : les liens dans l’ATS pointent les recruteurs uniquement vers les fichiers assainis, servis depuis un bucket à URL signée. Les originaux exigent un flux d’approbation JIT journalisé dans votre SIEM.
- Liens : les liens sortants inconnus sont réécrits vers le RBI ; la allowlist de domaines couvre votre propre site, Calendly (vérifié par domaine) et les principaux job boards.
- Code : le « Open in Sandbox » de l’ATS appelle un service de provisioning qui lance une VM Firecracker ou un Codespace avec :
- Clé SSH éphémère ; aucun token SSO corporate
- Egress vers un proxy npm/pip privé uniquement
- Pré‑vol qui scanne postinstall/prepare/.git/hooks/appels réseau dans Makefile
- TTL de 24 h et auto‑destruction
Gardez l’observabilité « boring » : écrivez les logs vers votre stack existante. Alertez uniquement sur les événements à fort signal (malware détecté, beaconing lors de la détonation d’un lien, violation d’egress du sandbox), pas à chaque upload de CV.
Runbooks et formation : une heure évite un incident
Offrez à chaque recruteur et hiring manager un briefing de 45 minutes et un runbook de deux pages. Couvrez :
- Red flags dans les DMs : pression pour cliquer sur des liens non‑domaine, ZIPs protégés par mot de passe, « ouvre ce doc pour voir l’offre ».
- Vérification d’offre pour vos propres collaborateurs ciblés par de faux recruteurs : exigez un appel vidéo en direct planifié depuis un domaine vérifié de l’entreprise, jamais un fichier reçu à froid.
- Comment escalader : un bouton « report » en un clic dans les outils email/DM, avec collecte automatique des en‑têtes et du contexte de conversation.
- Quand déroger aux règles : presque jamais ; mais si un candidat ne peut pas accéder au portail, les recruteurs peuvent utiliser une session d’admission supervisée où le fichier est uploadé depuis la machine du recruteur vers le portail sans l’ouvrir.
Ce n’est pas de la « compliance » optionnelle. C’est de l’hygiène opérationnelle.
L’histoire de la backdoor LinkedIn ne devrait pas vous surprendre. En 2026, le chemin le plus rapide vers votre code et vos identifiants cloud passe par des workflows humains — ceux que nous avons exemptés de durcissement parce que « l’embauche est urgente ». Vous pouvez livrer un pipeline de recrutement durci en moins de 90 jours avec des briques standard, sans ralentir l’équipe ni effrayer les candidats.
Quand vous regardez la roadmap du prochain trimestre, demandez‑vous : préférez‑vous consacrer une semaine‑ingénieur pour rendre cela ennuyeux, ou un trimestre‑ingénieur à nettoyer un incident « comment un CV a‑t‑il phishé notre SSO ? » ? Le pipeline fait désormais partie de votre système de production. Ingénieriez‑le en conséquence.
À retenir
- Traitez le recrutement comme une supply chain logicielle : CV, liens et code sont des contenus exécutables.
- Mettez en place trois plans de contrôle : politique/UX d’entrée, isolation/inspection du contenu et isolation d’exécution.
- Interdisez les pièces jointes ad hoc ; faites transiter tous les fichiers candidats par un pare‑feu ATS qui scanne et assainit.
- Utilisez l’isolation de navigateur pour les liens inconnus et faites tourner le code candidat uniquement dans des sandboxes éphémères avec miroirs privés.
- Visez des SLAs qui battent les mauvaises habitudes : moins de 3 s pour assainir un doc et moins de 60 s pour lancer un sandbox.
- Déployez en 90 jours : la politique maintenant, le pipeline ensuite, l’automatisation en dernier ; mesurez l’adoption et les événements bloqués.
- Adaptez‑vous aux réalités LatAm (WhatsApp, DOCX) sans baisser la sécurité ; automatisez le chemin sûr.