Le 10 septembre 2026, Sysdig a ajouté une fonction qui change la donne pour les équipes serverless : le scan sans agent des fonctions AWS Lambda packagées en ZIP. Jusque-là, la sécurité des fonctions Lambda restait un angle mort pour beaucoup d’équipes DevSecOps, coincées entre des scanners pensés pour les conteneurs et des fonctions qui n’en sont pas. Ce tutoriel vous montre comment construire, de A à Z, une chaîne de scan de vulnérabilités pour vos fonctions Lambda, sans agent à déployer et sans modifier votre runtime de production.

Vous repartirez avec un pipeline reproductible, un exemple de fonction Lambda volontairement vulnérable pour tester la détection, et une checklist de durcissement calée sur les référentiels OWASP Serverless et les recommandations de l’ANSSI. Comptez environ 90 minutes pour suivre l’ensemble des étapes, y compris la configuration CI/CD.

Pourquoi la sécurité des fonctions Lambda mérite un traitement à part

Une fonction AWS Lambda n’a pas de système d’exploitation à patcher au sens classique, pas de démon à surveiller en continu, et pas de conteneur qui tourne 24 heures sur 24. Résultat : beaucoup d’équipes ont fini par croire que la sécurité serverless se limitait à la configuration IAM. C’est faux, et c’est même dangereux comme raccourci. Une fonction Lambda embarque un code applicatif, des dépendances tierces (souvent des centaines de paquets npm ou pip), et parfois des bibliothèques natives compilées. Chacun de ces éléments peut porter une vulnérabilité connue, exploitable dès l’invocation.

Le problème classique du scan de vulnérabilités serverless, c’est l’instrumentation. Poser un agent dans un environnement d’exécution éphémère qui vit parfois moins d’une seconde ne fonctionne pas. C’est exactement ce que corrige l’approche agentless : le scanner inspecte l’archive ZIP ou l’image de conteneur Lambda directement dans le registre ou au moment du déploiement, sans jamais toucher au runtime en production. Microsoft a suivi une logique proche avec Defender for Cloud, qui a atteint la disponibilité générale pour la découverte et l’évaluation de posture des workloads de conteneurs serverless le 1er juillet 2026, un signal clair que les grands fournisseurs cloud considèrent désormais le serverless comme une surface d’attaque à part entière et non plus comme un sous-produit des conteneurs.

Pour une entreprise française ou européenne, l’enjeu de conformité s’ajoute à l’enjeu technique. La directive NIS2 et le Cyber Resilience Act imposent une traçabilité des composants logiciels et un délai de signalement des vulnérabilités critiques, une exigence que l’ANSSI rappelle régulièrement aux opérateurs français dans ses publications. Une fonction Lambda qui embarque une dépendance vulnérable sans que personne ne le sache n’est plus seulement un risque technique, c’est une non-conformité potentielle.

Ce que dit le référentiel OWASP Serverless Top 10 sur Lambda

Le projet OWASP consacré aux architectures serverless liste des catégories de risque qui recoupent partiellement l’injection classique et l’exposition de données, mais avec des nuances propres au modèle d’exécution événementiel. Une fonction Lambda reçoit un événement (une requête HTTP via API Gateway, un objet déposé dans un bucket S3, un message dans une file SQS) et ce déclencheur devient une surface d’entrée à part entière. Beaucoup d’équipes valident les entrées HTTP classiques mais oublient de valider un nom de fichier S3 ou un attribut d’un message SQS, alors que ces champs peuvent tout autant être manipulés par un attaquant.

Le scan de vulnérabilités décrit dans ce tutoriel couvre la dimension dépendances logicielles connues, mais il ne couvre pas cette dimension de validation des événements déclencheurs. Les deux sont complémentaires : un pipeline mature associe un scan de vulnérabilités automatisé à une revue de code ciblée sur la gestion des entrées, en particulier pour les fonctions exposées à des sources externes non authentifiées.

Prérequis et versions utilisées dans ce tutoriel

Avant de commencer, vérifiez que votre environnement dispose des éléments suivants. Les versions indiquées sont celles disponibles au 27 septembre 2026 ; utilisez toujours la dernière version stable publiée par chaque éditeur au moment où vous suivez ce guide.

Outil ou serviceVersion utilisée dans ce tutorielRôle dans le pipeline
AWS CLIv2 (dernière version stable)Déploiement et gestion des fonctions Lambda
Node.js (runtime Lambda)Node.js 22.x (runtime managé AWS)Exécution de la fonction Lambda de démonstration
Sysdig CLI Scannerv1.30.1 (23 septembre 2026)Scan d’image, d’archive et de fonction Lambda
Sysdig Registry Scannerv0.12.3 (15 septembre 2026)Scan continu du registre d’images
Sysdig Runtime Scannerv1.8.11Détection à l’exécution, corrélation des findings
Dockerdernière version stableConstruction d’images de fonctions Lambda conteneurisées
GitHub Actions ou GitLab CIrunners hébergés à jourIntégration du scan dans le pipeline CI/CD

Consultez au passage le guide officiel AWS sur le modèle de sécurité Lambda si vous découvrez ce service, il détaille la frontière de responsabilité entre AWS et vous. Vous aurez aussi besoin d’un compte AWS avec les droits IAM suffisants pour créer des fonctions Lambda, des rôles IAM et des dépôts dans Amazon ECR si vous testez la variante conteneurisée. Un compte Sysdig Secure (ou un essai) est nécessaire pour obtenir un jeton d’API valide.

Étape 1 : cartographier votre inventaire de fonctions Lambda

Avant de scanner quoi que ce soit, il faut savoir ce que vous avez. Beaucoup d’organisations découvrent, au moment de leur premier audit, qu’elles ont des dizaines de fonctions Lambda oubliées, déployées par un ancien stagiaire ou un prototype devenu production sans jamais avoir été révisé. Listez l’ensemble de vos fonctions avec la commande suivante.

aws lambda list-functions \
  --query 'Functions[].{Name:FunctionName,Runtime:Runtime,LastModified:LastModified,CodeSize:CodeSize}' \
  --output table \
  --region eu-west-3

Portez une attention particulière aux runtimes obsolètes (Node.js 14 ou 16, Python 3.7 ou 3.8) : ce sont des candidats prioritaires, car un runtime en fin de vie ne reçoit plus de correctifs de sécurité de la part d’AWS, indépendamment de ce que vous faites dans votre propre code. Exportez cette liste dans un fichier CSV, elle servira de base à votre plan de remédiation.

Étape 2 : préparer une fonction Lambda de démonstration volontairement vulnérable

Pour tester votre chaîne de scan sans agent avant de la brancher sur vos vraies fonctions, créez un petit projet Node.js avec une dépendance datée. Cela vous permet de vérifier que le scanner détecte bien un problème connu avant de faire confiance au pipeline.

mkdir lambda-demo-scan && cd lambda-demo-scan
npm init -y
npm install [email protected] --save
cat > index.js << 'EOF'
const _ = require('lodash');

exports.handler = async (event) => {
  const payload = JSON.parse(event.body || '{}');
  const merged = _.merge({}, payload);
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'ok', data: merged }),
  };
};
EOF
zip -r function.zip index.js node_modules package.json

La version 4.17.15 de lodash contient une vulnérabilité de pollution de prototype connue et documentée. C’est volontaire : elle sert de témoin pour valider que la détection fonctionne. Ne déployez jamais ce code tel quel en production.

Étape 3 : installer et authentifier le Sysdig CLI Scanner

Téléchargez le binaire du CLI Scanner et configurez votre jeton d’API Sysdig Secure. Le jeton se récupère dans les paramètres de votre organisation Sysdig, sous la section intégrations.

curl -sLO https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/latest/linux/amd64/sysdig-cli-scanner
chmod +x sysdig-cli-scanner

export SECURE_API_TOKEN="votre_jeton_sysdig_secure"

./sysdig-cli-scanner --version

Vérifiez que la version affichée correspond bien à 1.30.1 ou plus récente en consultant les notes de version officielles de Sysdig Secure. Les versions antérieures au 10 septembre 2026 ne disposent pas encore du mode d’analyse agentless pour les archives ZIP Lambda.

Étape 4 : lancer le premier scan agentless sur l’archive ZIP

C’est le cœur du tutoriel. Contrairement à un scan d’image de conteneur classique, le scan de fonction Lambda cible directement l’archive de déploiement, sans passer par un registre intermédiaire.

./sysdig-cli-scanner \
  --apiurl https://secure.sysdig.com \
  scan-lambda \
  --zip-path ./function.zip \
  --runtime nodejs22.x \
  --output json > scan-result.json

cat scan-result.json | jq '.vulnerabilities[] | {package: .package, severity: .severity, cve: .cve_id}'

Le résultat devrait faire apparaître la vulnérabilité de pollution de prototype dans lodash 4.17.15, avec une sévérité classée haute ou critique selon le référentiel CVSS utilisé par Sysdig. Si le scan ne trouve rien, vérifiez que le chemin vers l’archive est correct et que le runtime déclaré correspond bien à celui de votre fonction.

Exemple de sortie attendue, résumée :

{
  "package": "lodash",
  "version": "4.17.15",
  "severity": "High",
  "cve": "CVE-2019-10744",
  "fixed_in": "4.17.19",
  "exploitability": "network, low complexity"
}

Étape 5 : corriger la vulnérabilité et rescanner

Une fois la vulnérabilité identifiée, la correction est souvent triviale : monter la dépendance à une version corrigée.

npm install lodash@latest --save
rm function.zip
zip -r function.zip index.js node_modules package.json

./sysdig-cli-scanner scan-lambda \
  --zip-path ./function.zip \
  --runtime nodejs22.x \
  --output json | jq '.vulnerabilities | length'

Le résultat doit maintenant afficher 0 vulnérabilité connue pour ce paquet précis. Gardez à l’esprit qu’un scan à zéro vulnérabilité connue ne signifie pas zéro risque : cela signifie simplement qu’aucune CVE publique référencée dans la base de données du scanner ne correspond aux versions présentes dans votre archive.

Étape 5 bis : sécuriser les secrets et variables d’environnement de la fonction

Une vulnérabilité de dépendance corrigée ne sert à rien si votre fonction stocke une clé d’API ou un mot de passe de base de données en clair dans ses variables d’environnement. C’est un schéma d’erreur classique : la variable d’environnement Lambda semble pratique, elle apparaît pourtant en clair dans la console AWS pour quiconque a le droit de lecture sur la fonction, et elle finit souvent copiée dans des journaux de déploiement ou des captures d’écran de support.

La bonne pratique consiste à stocker les secrets dans AWS Secrets Manager ou dans Parameter Store, puis à les récupérer à l’exécution avec les permissions IAM minimales nécessaires.

aws secretsmanager create-secret \
  --name demo-scan-fn/db-credentials \
  --secret-string '{"username":"app_user","password":"CHANGEZ_MOI"}' \
  --region eu-west-3

aws iam put-role-policy \
  --role-name lambda-demo-scan-role \
  --policy-name lecture-secret-specifique \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:eu-west-3:VOTRE_COMPTE:secret:demo-scan-fn/db-credentials-*"
    }]
  }'

Notez la restriction de la ressource à un secret précis plutôt qu’à un joker (wildcard) sur l’ensemble des secrets du compte. C’est un détail qui fait souvent la différence entre un incident limité à une fonction et une compromission qui se propage à tout le compte AWS. La fiche de bonnes pratiques OWASP sur la gestion des secrets recommande d’ailleurs la rotation automatique des identifiants sensibles, une fonctionnalité nativement supportée par Secrets Manager pour les bases de données RDS.

Étape 6 : déployer la fonction Lambda corrigée sur AWS

aws iam create-role \
  --role-name lambda-demo-scan-role \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name lambda-demo-scan-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

aws lambda create-function \
  --function-name demo-scan-fn \
  --runtime nodejs22.x \
  --role arn:aws:iam::VOTRE_COMPTE:role/lambda-demo-scan-role \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --region eu-west-3

Le fichier trust-policy.json doit contenir la politique de confiance standard autorisant le service Lambda à assumer ce rôle. Limitez toujours les permissions du rôle d’exécution au strict nécessaire, c’est le principe du moindre privilège, rappelé dans les bonnes pratiques IAM publiées par AWS.

Étape 7 : automatiser le scan dans votre pipeline CI/CD

Un scan manuel a une valeur limitée si personne ne le relance à chaque déploiement. Intégrez le scan agentless comme une porte de qualité dans votre pipeline, avant tout déploiement en production.

# .github/workflows/scan-lambda.yml
name: Scan Lambda avant deploiement
on:
  pull_request:
    paths:
      - 'src/**'

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Construire l'archive
        run: |
          npm ci
          zip -r function.zip index.js node_modules package.json
      - name: Scanner avec Sysdig
        env:
          SECURE_API_TOKEN: ${{ secrets.SYSDIG_API_TOKEN }}
        run: |
          curl -sLO https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/latest/linux/amd64/sysdig-cli-scanner
          chmod +x sysdig-cli-scanner
          ./sysdig-cli-scanner scan-lambda \
            --zip-path ./function.zip \
            --runtime nodejs22.x \
            --fail-on-severity high

L’option d’échec sur sévérité haute bloque la fusion de la pull request si une vulnérabilité critique ou haute est détectée. Adaptez ce seuil à la maturité de votre équipe : un seuil trop strict dès le premier jour génère de la friction et pousse les développeurs à contourner le contrôle.

Étape 8 : étendre le scan au registre pour les Lambda conteneurisées

Si vos fonctions Lambda tournent sous forme d’image de conteneur plutôt que d’archive ZIP, le Registry Scanner de Sysdig, en version 0.12.3 depuis le 15 septembre 2026, surveille en continu votre dépôt Amazon ECR et déclenche un nouveau scan à chaque push d’image.

aws ecr create-repository --repository-name lambda-demo-container --region eu-west-3

docker build -t lambda-demo-container .
docker tag lambda-demo-container:latest \
  VOTRE_COMPTE.dkr.ecr.eu-west-3.amazonaws.com/lambda-demo-container:latest

aws ecr get-login-password --region eu-west-3 | \
  docker login --username AWS --password-stdin VOTRE_COMPTE.dkr.ecr.eu-west-3.amazonaws.com

docker push VOTRE_COMPTE.dkr.ecr.eu-west-3.amazonaws.com/lambda-demo-container:latest

Configurez ensuite le Registry Scanner pour surveiller ce dépôt automatiquement depuis la console Sysdig Secure, sans intervention manuelle à chaque nouvelle image.

Étape 9 : corréler avec le Runtime Scanner pour détecter l’exploitation active

Le scan statique dit ce qui est vulnérable. Le Runtime Scanner, en version 1.8.11, dit ce qui est réellement invoqué et exploité. La combinaison des deux réduit drastiquement le bruit : plutôt que de traiter 200 vulnérabilités théoriques, vous priorisez celles qui touchent du code effectivement exécuté en production.

./sysdig-cli-scanner scan-lambda \
  --zip-path ./function.zip \
  --runtime nodejs22.x \
  --correlate-runtime \
  --function-arn arn:aws:lambda:eu-west-3:VOTRE_COMPTE:function:demo-scan-fn

Cette corrélation exige que le Runtime Scanner soit déjà actif sur votre compte AWS avec les permissions adéquates pour observer les invocations Lambda via CloudWatch et les journaux d’exécution.

Étape 10 : étendre l’analyse aux nœuds EKS et GKE si vous êtes multi-cloud

Si votre organisation combine du serverless AWS et des clusters Kubernetes managés, ne traitez pas ces deux mondes séparément. Depuis août 2026, l’évaluation des vulnérabilités des nœuds Kubernetes s’est étendue au-delà d’Azure AKS pour couvrir aussi Amazon EKS et Google GKE, d’abord en préversion. L’objectif : une vue unique de la posture de sécurité, plutôt que des tableaux de bord séparés par fournisseur cloud.

./sysdig-cli-scanner scan-node \
  --cluster-type eks \
  --cluster-name mon-cluster-eks \
  --region eu-west-3

./sysdig-cli-scanner scan-node \
  --cluster-type gke \
  --cluster-name mon-cluster-gke \
  --project mon-projet-gcp

Si vous gérez déjà vos clusters Kubernetes en respectant des règles de durcissement, voyez ce scan comme une couche supplémentaire, pas un remplacement de votre stratégie existante de sécurisation des conteneurs.

Étape 10 bis : prioriser avec le score CVSS et le contexte d’exploitabilité

Un premier scan sur un parc de fonctions Lambda existant depuis plusieurs années remonte souvent des dizaines, voire des centaines de résultats. Traiter cette liste dans l’ordre d’arrivée est une perte de temps. La priorisation doit combiner trois signaux : le score CVSS de base, la présence d’un exploit public documenté, et le contexte d’exposition réel de la fonction concernée.

Une vulnérabilité critique dans une dépendance utilisée uniquement par une fonction interne, jamais exposée à internet et déclenchée seulement par un job de nuit planifié, ne mérite pas le même délai de traitement qu’une vulnérabilité de sévérité moyenne dans une fonction exposée directement via une API Gateway publique et non authentifiée. Sysdig et la plupart des scanners équivalents exposent un champ d’exploitabilité en réseau qui aide à faire ce tri, mais il revient à votre équipe de croiser ce signal avec la cartographie réelle de vos déclencheurs.

cat scan-result.json | jq '.vulnerabilities[] | select(.severity == "Critical" or .severity == "High") | {package, cve, severity, exploitability}' | jq -s 'sort_by(.severity) | reverse'

Cette commande extrait uniquement les vulnérabilités critiques et hautes puis les trie, une première étape simple avant d’y ajouter manuellement le contexte d’exposition de chaque fonction dans votre tableau de suivi.

Étape 10 ter : passer à l’échelle avec AWS Organizations

Ce tutoriel a jusqu’ici raisonné à l’échelle d’un compte AWS unique. Dans une organisation qui gère des dizaines de comptes AWS via AWS Organizations, typiquement un compte par équipe ou par environnement, il faut industrialiser le déploiement de ce pipeline de scan plutôt que de le reproduire manuellement compte par compte.

L’approche la plus robuste consiste à déployer un rôle IAM d’audit en lecture seule dans chaque compte membre, assumable depuis un compte central de sécurité, puis à faire tourner le scan planifié depuis ce compte central sur l’ensemble du parc.

for account_id in $(aws organizations list-accounts --query 'Accounts[].Id' --output text); do
  creds=$(aws sts assume-role \
    --role-arn "arn:aws:iam::${account_id}:role/audit-lambda-readonly" \
    --role-session-name scan-lambda-central \
    --query 'Credentials' --output json)

  export AWS_ACCESS_KEY_ID=$(echo $creds | jq -r '.AccessKeyId')
  export AWS_SECRET_ACCESS_KEY=$(echo $creds | jq -r '.SecretAccessKey')
  export AWS_SESSION_TOKEN=$(echo $creds | jq -r '.SessionToken')

  echo "Scan du compte ${account_id}"
  aws lambda list-functions --query 'Functions[].FunctionName' --output text
done

Cette centralisation évite qu’un compte oublié échappe à toute politique de scan, un scénario fréquent quand chaque équipe gère son propre compte AWS sans supervision transverse. Elle simplifie aussi le reporting : un seul tableau de bord pour l’ensemble de l’organisation, plutôt qu’un export à consolider manuellement compte par compte.

Étape 11 : construire une matrice de conformité européenne

Pour une équipe soumise à NIS2, au Cyber Resilience Act ou à des exigences de souveraineté numérique, chaque vulnérabilité détectée doit être reliée à un contexte réglementaire. Construisez un tableau simple qui croise vos findings avec le niveau de criticité et le délai de remédiation attendu.

Critère de conformitéExigence typiqueAction liée au scan Lambda
Localisation des donnéesTraitement dans une région UEVérifier la région AWS de déploiement de chaque fonction
Chiffrement au reposVariables d’environnement chiffréesActiver le chiffrement KMS sur les variables sensibles
Délai de signalementNotification rapide des failles critiquesAlerte automatique dès qu’une CVE critique est détectée
Conservation des journauxTraçabilité des invocationsRétention CloudWatch Logs configurée et exportée
Accès administrateurPrincipe du moindre privilègeAudit des rôles IAM attachés aux fonctions Lambda
Dépendance fournisseurRéversibilité et portabilitéDocumentation des dépendances propriétaires par fonction

Cette matrice n’est pas un exercice bureaucratique isolé, elle donne à votre RSSI un langage commun entre l’équipe technique qui lance les scans et les équipes juridique ou conformité qui répondent aux auditeurs.

Étape 12 : mettre en place une revue périodique et un tableau de bord

Un scan ponctuel a une valeur qui décroît vite. Les nouvelles CVE sont publiées en continu, y compris pour des paquets que vous n’avez pas touchés depuis des mois. Planifiez un scan de l’ensemble de vos fonctions Lambda existantes au moins une fois par semaine, indépendamment des déploiements.

# Script de scan planifie (a executer via cron ou EventBridge Scheduler)
#!/bin/bash
FUNCTIONS=$(aws lambda list-functions --query 'Functions[].FunctionName' --output text)

for fn in $FUNCTIONS; do
  aws lambda get-function --function-name "$fn" \
    --query 'Code.Location' --output text > /tmp/url-$fn.txt
  curl -s -o /tmp/$fn.zip "$(cat /tmp/url-$fn.txt)"
  ./sysdig-cli-scanner scan-lambda \
    --zip-path /tmp/$fn.zip \
    --output json >> /tmp/rapport-hebdo.json
done

Centralisez ensuite ces résultats dans le tableau de bord Sysdig Secure ou exportez-les vers votre outil de gestion des vulnérabilités habituel pour garder une trace historique et mesurer votre tendance de remédiation dans le temps.

Étape 13 : rassembler l’ensemble dans un projet complet et fonctionnel

En rassemblant toutes les étapes précédentes, voici l’architecture complète que vous devriez avoir en place à la fin de ce tutoriel : un registre d’images sécurisé avec Amazon ECR, des signatures d’image vérifiées, un inventaire logiciel par fonction, une politique en tant que code pour bloquer les déploiements non conformes, un scan agentless à chaque pull request, un scan planifié hebdomadaire sur l’ensemble du parc, et une corrélation avec le runtime pour prioriser les vulnérabilités réellement exploitées.

Ce n’est pas un empilement d’outils pour le plaisir de la complexité. Chaque brique répond à une question différente : l’inventaire logiciel répond à “qu’est-ce qui est dedans”, le scan agentless répond à “qu’est-ce qui est vulnérable”, et le Runtime Scanner répond à “qu’est-ce qui est réellement à risque maintenant”. Si vous voulez approfondir la génération de SBOM pour vos images de conteneur, notre guide sur Syft et Grype pour générer un SBOM Docker complète directement cette étape, et si vous déployez encore vos fonctions manuellement, notre tutoriel sur le déploiement de fonctions AWS Lambda couvre la partie mise en production que ce guide suppose déjà acquise.

Combien coûte ce pipeline, et combien coûte l’absence de scan

La question du coût revient systématiquement quand une équipe FinOps découvre qu’un nouvel outil de sécurité va s’ajouter à la facture cloud mensuelle. Le calcul mérite d’être posé clairement plutôt qu’esquivé. Le CLI Scanner lui-même est gratuit à l’usage direct, seule la plateforme Sysdig Secure qui héberge les résultats, la corrélation runtime et le tableau de bord est facturée, généralement selon un modèle par charge de travail surveillée. Le coût marginal d’ajouter le scan Lambda à un abonnement Sysdig Secure déjà en place pour vos conteneurs Kubernetes reste faible.

Le vrai poste de coût n’est pas l’outil, c’est le temps humain de triage et de remédiation. Une fonction Lambda avec cinquante findings hérités d’années d’accumulation de dette technique peut mobiliser plusieurs jours d’un développeur senior. C’est précisément pour cela que l’étape de priorisation par contexte d’exploitabilité, décrite plus haut, a un impact direct sur le budget : elle réduit le nombre de findings traités de manière urgente, sans réduire la couverture du scan.

À l’inverse, le coût d’un incident lié à une dépendance vulnérable non corrigée se mesure rarement en heures d’ingénieur. Il se mesure en temps d’indisponibilité, en notification obligatoire aux autorités si des données personnelles sont concernées, et en coût de communication de crise. Une approche FinOps mature intègre ce risque dans le calcul de retour sur investissement d’un outil de sécurité, plutôt que de comparer uniquement le prix de la licence à un budget d’infrastructure classique. Notre guide sur le FinOps appliqué à AWS détaille cette logique de calcul du coût total, au-delà du seul prix affiché sur la facture cloud.

5 pièges fréquents à éviter

  • Scanner uniquement au déploiement initial. Une dépendance saine aujourd’hui peut devenir vulnérable demain suite à la publication d’une nouvelle CVE. Sans scan planifié, vous ne le saurez jamais.
  • Ignorer les couches Lambda partagées. Une couche utilisée par 15 fonctions et jamais rescannée devient un point de propagation silencieux d’une même vulnérabilité.
  • Fixer un seuil de blocage trop strict trop tôt. Bloquer sur toute sévérité moyenne dès le premier jour pousse les équipes à demander des dérogations en masse, ce qui vide le contrôle de son sens.
  • Confondre absence de CVE connue et absence de risque. Un scanner de vulnérabilités ne détecte que ce qui est déjà référencé dans une base de données publique, pas les erreurs de logique métier ni les mauvaises configurations IAM.
  • Oublier les runtimes en fin de vie. Une fonction sous Node.js 16 ou Python 3.8 ne reçoit plus de correctifs de sécurité de la part d’AWS, même si le scanner de dépendances ne signale rien d’anormal dans votre propre code.

Conseils avancés pour aller plus loin

Une fois le pipeline de base opérationnel, plusieurs affinements valent la peine. D’abord, isolez vos fonctions Lambda sensibles dans un VPC dédié avec des groupes de sécurité restrictifs, plutôt que de les laisser dans le VPC par défaut. Ensuite, signez vos archives de déploiement avec une clé de signature de code, de sorte qu’une archive modifiée après le scan ne puisse pas être déployée sans déclencher une alerte d’intégrité. Cette pratique répond aussi à une exigence de plus en plus fréquente dans les cahiers des charges de sécurité des grands comptes européens, qui demandent une preuve d’intégrité entre le code scanné et le code réellement déployé.

Un autre réglage souvent négligé concerne la fréquence de rotation des rôles IAM temporaires utilisés par vos jobs CI/CD. Un jeton d’API Sysdig ou des identifiants AWS temporaires qui traînent plusieurs mois dans un fichier de configuration CI mal protégé représentent un risque comparable à celui d’une dépendance vulnérable, avec l’aggravation qu’il est rarement détecté par un scanner de code.

Pensez aussi à croiser vos résultats de scan Lambda avec les CVE surveillées côté Kubernetes si votre organisation gère les deux environnements. Notre tutoriel sur le durcissement de Kubernetes contre les CVE containerd propose une méthodologie transposable presque telle quelle au monde serverless : inventaire, scan continu, seuils de criticité, puis remédiation planifiée. Vous pouvez aussi renforcer la détection réseau associée grâce à notre guide sur les règles personnalisées AWS GuardDuty, qui complète le scan de vulnérabilités par une surveillance comportementale.

Enfin, si vous exposez vos fonctions Lambda via une API publique, ne négligez pas la couche réseau. La checklist OWASP pour les architectures serverless recommande de traiter chaque événement déclencheur, API Gateway, S3 ou EventBridge, comme une entrée non fiable, au même titre qu’une requête HTTP classique dans une application traditionnelle. Si vos fonctions stockent des données dans un bucket, notre guide pour sécuriser un bucket AWS S3 ferme cette boucle côté stockage.

Alternatives si vous ne pouvez pas adopter Sysdig immédiatement

Toutes les organisations ne peuvent pas signer un contrat avec une plateforme commerciale du jour au lendemain, que ce soit pour des raisons budgétaires ou parce qu’un processus d’achat interne prend plusieurs mois. Si c’est votre cas, vous pouvez reproduire une version simplifiée de ce pipeline avec des outils open source, quitte à migrer vers une solution commerciale plus tard une fois la valeur démontrée en interne.

Trivy, l’outil open source que nous avons déjà couvert pour le scan de conteneurs Docker, sait aussi analyser une archive de système de fichiers, ce qui inclut un dossier décompressé contenant votre code Lambda et son node_modules. La commande de base ressemble à ceci.

unzip function.zip -d function-extracted
trivy fs --scanners vuln ./function-extracted --format table

Cette approche n’offre pas la corrélation runtime ni le tableau de bord centralisé multi-comptes décrits plus haut, mais elle couvre la détection de base des dépendances vulnérables à coût nul. Pour une petite équipe qui démarre sa démarche de sécurité serverless, c’est un point de départ raisonnable avant d’investir dans une plateforme plus complète. Si vous gérez déjà Trivy pour vos conteneurs, notre tutoriel dédié détaille sa configuration complète, y compris l’intégration en pipeline CI/CD que vous pouvez adapter directement à ce cas d’usage Lambda.

Dépannage : 8 problèmes courants et leurs solutions

  • Le scanner renvoie une erreur d’authentification. Vérifiez que la variable d’environnement SECURE_API_TOKEN est bien exportée dans la session courante et que le jeton n’a pas expiré côté console Sysdig Secure.
  • Le scan agentless ne détecte aucune dépendance. Confirmez que le dossier node_modules a bien été inclus dans l’archive ZIP avant compression, c’est l’erreur la plus fréquente lors des premiers essais.
  • Le runtime déclaré ne correspond pas à celui détecté. Utilisez exactement l’identifiant de runtime AWS, par exemple nodejs22.x et non node22 ou nodejs 22.
  • Le pipeline CI/CD dépasse le délai pendant le scan. Les archives volumineuses avec de nombreuses dépendances natives peuvent prendre plus de temps, augmentez le délai d’exécution du job CI à 10 minutes minimum.
  • Le Registry Scanner ne détecte pas les nouvelles images poussées sur ECR. Vérifiez que le rôle IAM utilisé par l’intégration Sysdig dispose bien des permissions ecr:GetDownloadUrlForLayer et ecr:BatchGetImage.
  • La corrélation runtime ne renvoie aucune donnée. Le Runtime Scanner a besoin de plusieurs invocations réelles de la fonction avant de construire un profil de comportement, attendez au moins 24 heures après activation.
  • Le job CI bloque toutes les pull requests, y compris pour des vulnérabilités mineures. Ajustez le paramètre fail-on-severity de critical à high, puis affinez progressivement selon la maturité de l’équipe.
  • Les résultats du scan ZIP et du scan d’image container diffèrent pour la même fonction. C’est normal si vous maintenez les deux formats en parallèle, la base d’image de conteneur inclut souvent des paquets système absents de l’archive ZIP pure.

Comparatif rapide : scan agentless contre approche traditionnelle

CritèreScan agentless (Sysdig)Agent embarqué classique
Installation requise sur le runtimeAucuneCouche ou agent à intégrer dans chaque fonction
Impact sur le temps de démarrage à froidNulSouvent mesurable, surtout sur les runtimes interprétés
Compatible archives ZIPOui, depuis le 10 septembre 2026Rarement, la plupart ciblent les images de conteneur
Détection à l’exécutionVia corrélation avec le Runtime ScannerNative mais coûteuse en ressources
Intégration CI/CDImmédiate via CLINécessite souvent un webhook ou un sidecar

Pour les équipes qui gèrent aussi des clusters Kubernetes, ce même principe agentless se retrouve dans l’écosystème conteneur avec des outils comme Trivy pour scanner des conteneurs Docker, une bonne porte d’entrée si vous voulez uniformiser vos pratiques de scan entre serverless et conteneurs classiques.

FAQ : les questions les plus posées sur la sécurisation des fonctions Lambda

Le scan agentless de Sysdig fonctionne-t-il aussi sur les fonctions Python ou Java ?
Oui, l’analyse sans agent couvre les archives ZIP quel que soit le runtime déclaré, tant que le gestionnaire de paquets (npm, pip, Maven) est identifiable dans l’archive. Adaptez simplement le paramètre runtime à votre configuration réelle.

Faut-il payer pour utiliser le CLI Scanner de Sysdig ?
Le binaire lui-même est gratuit à télécharger, mais il nécessite un jeton d’API valide lié à un compte Sysdig Secure, qui est un service payant au-delà de la période d’essai.

Quelle est la différence entre le scan de fonction Lambda et le scan d’image de conteneur classique ?
Le scan de fonction cible directement l’archive de déploiement Lambda, ZIP ou image spécifique au runtime managé, alors que le scan d’image classique cible une image Docker complète destinée à Kubernetes ou ECS, avec potentiellement plus de couches système à analyser.

Le scan de vulnérabilités remplace-t-il un audit de sécurité manuel ?
Non. Le scan détecte les vulnérabilités connues et référencées dans des bases publiques comme la NVD, mais il ne remplace pas une revue de code, un test d’intrusion, ni un audit de la logique métier et des permissions IAM.

Comment gérer les faux positifs remontés par le scanner ?
La plupart des scanners permettent de créer des règles d’exception documentées, avec une justification écrite et une date de réévaluation, plutôt que d’ignorer silencieusement une alerte.

Ce pipeline fonctionne-t-il pour des fonctions déployées via Terraform ou le Serverless Framework ?
Oui, il suffit d’insérer l’étape de scan avant l’étape de déploiement dans votre pipeline, quel que soit l’outil d’infrastructure as code utilisé.

Combien de temps prend un scan agentless typique ?
Pour une archive de quelques mégaoctets avec une centaine de dépendances, comptez généralement entre 15 et 60 secondes, selon la taille de l’archive et la charge de l’API au moment de la requête.

Doit-on scanner aussi les couches Lambda partagées entre plusieurs fonctions ?
Absolument, et c’est même prioritaire : une couche vulnérable propage le même risque à toutes les fonctions qui l’utilisent, ce qui en fait souvent un point de correction à fort effet de levier.