Les produits SaaS posent un problème particulier de risque lié à la chaîne d'approvisionnement logicielle : ils présentent les mêmes vulnérabilités de chaîne d'approvisionnement que les logiciels installés (dépendances open source, risques de compromission du pipeline de build, infrastructure de distribution), mais l'entreprise cliente n'a aucune visibilité ni aucun contrôle sur les pratiques de sécurité de la chaîne d'approvisionnement de l'éditeur SaaS, car le logiciel ne lui est jamais livré sous forme d'artefact. Les contrôles de SBOM, d'analyse SCA et de vérification de la provenance qui s'appliquent aux logiciels installés n'ont pas d'équivalent direct pour les services SaaS, car l'éditeur SaaS conserve le logiciel et ne fournit que l'interface du service.
L'asymétrie de visibilité est le défi fondamental de la chaîne d'approvisionnement SaaS. Lorsqu'une plateforme SaaS construite sur des centaines de composants open source comporte une dépendance vulnérable, l'entreprise ne peut pas le découvrir par sa propre analyse SCA : elle ne dispose pas du logiciel à analyser. Lorsque le pipeline de build de l'éditeur SaaS est compromis, l'entreprise n'a aucune attestation de provenance à vérifier : l'éditeur ne distribue pas d'attestations de provenance. Lorsqu'une CVE critique est publiée pour un composant de l'arbre de dépendances de la plateforme SaaS, l'entreprise dépend de la propre surveillance des vulnérabilités de l'éditeur et de sa communication avec les clients : il n'existe aucun moyen de découverte indépendant.
Les dimensions du risque lié à la chaîne d'approvisionnement SaaS sont équivalentes à celles des logiciels installés. Une plateforme SaaS dont l'éditeur a une mauvaise hygiène des dépendances accumule des composants vulnérables. Une plateforme SaaS dont le pipeline de build est compromis livre des fonctionnalités malveillantes à tous ses clients. Une plateforme SaaS distribuée par un mécanisme de mise à jour compromis envoie du code malveillant simultanément à chaque locataire client. L'entreprise qui évalue les plateformes SaaS de production uniquement sur leur configuration de sécurité et leurs contrôles d'accès, sans évaluer le programme de sécurité de la chaîne d'approvisionnement logicielle de l'éditeur, gère le risque opérationnel du service SaaS tout en abandonnant entièrement son risque lié à la chaîne d'approvisionnement aux pratiques de l'éditeur.
Pourquoi c’est important
La sécurité de la chaîne d'approvisionnement SaaS est importante pour la TPRM, car les entreprises qui ont le plus investi dans les contrôles de la chaîne d'approvisionnement des logiciels installés (SBOM, SCA, provenance) dépendent simultanément de services SaaS dont la sécurité de la chaîne d'approvisionnement est entièrement gérée par l'éditeur. Le programme de chaîne d'approvisionnement des logiciels installés offre des contrôles directs. La chaîne d'approvisionnement SaaS exige l'évaluation du programme de l'éditeur, seul mécanisme d'assurance disponible.
- Risque lié à la chaîne d'approvisionnement SaaS hors du périmètre du programme de sécurité de la chaîne d'approvisionnement
- Pratiques de SBOM, d'SCA et de provenance non évaluées pour les fournisseurs SaaS
- Sécurité du pipeline de build non évaluée pour la livraison logicielle de l'éditeur SaaS
- Aucun processus de notification des CVE établi pour les vulnérabilités des dépendances SaaS
- Rapport SOC 2 accepté comme preuve de la sécurité de la chaîne d'approvisionnement SaaS sans questions propres à la chaîne d'approvisionnement
À quoi ressemblent les bonnes pratiques
Les évaluations matures de la chaîne d'approvisionnement SaaS étendent aux éditeurs SaaS les questions de sécurité de la chaîne d'approvisionnement des logiciels installés, en les interrogeant sur leurs pratiques en matière de SBOM, la gestion des vulnérabilités de leurs dépendances, la sécurité de leur pipeline de build et leurs processus de notification des CVE, et considèrent le programme de chaîne d'approvisionnement logicielle du fournisseur comme le mécanisme d'assurance qui remplace l'inspection directe des artefacts.
- Évaluation du programme SBOM et SCA de l'éditeur SaaS
- Sécurité du pipeline de build SaaS : les mêmes questions sur le pipeline que pour les éditeurs de logiciels installés
- Processus de notification des CVE : comment l'entreprise est informée des vulnérabilités des composants
- Capacité d'IR de l'éditeur SaaS pour la chaîne d'approvisionnement : comment les incidents de la chaîne d'approvisionnement sont gérés
- Contrôles SOC 2 propres à la chaîne d'approvisionnement, et pas seulement à la sécurité opérationnelle
Outils
Évaluation de la chaîne d'approvisionnement SaaS : SIG de Shared Assessments avec sa section sur la chaîne d'approvisionnement logicielle ; contrôles de chaîne d'approvisionnement propres au cloud du CAIQ de la CSA
Les cadres normalisés d'évaluation des fournisseurs comportent désormais des sections sur la sécurité de la chaîne d'approvisionnement logicielle : le SIG de Shared Assessments comprend des contrôles de chaîne d'approvisionnement applicables aux fournisseurs SaaS. Pour les praticiens de la TPRM, étendre l'évaluation SIG aux questions sur la chaîne d'approvisionnement logicielle offre une approche structurée de l'évaluation de la chaîne d'approvisionnement SaaS, en complément des questions de sécurité opérationnelle que traitent les évaluations SaaS standard.
Enjeux de gouvernance
Le défi de gouvernance de l'évaluation de la chaîne d'approvisionnement SaaS est la disponibilité des informations du fournisseur. Les éditeurs SaaS n'ont pas l'habitude de communiquer à leurs clients des informations sur leur SBOM ou sur la sécurité de leur pipeline de build : ce sont des pratiques d'ingénierie internes que la plupart des fournisseurs ne divulguent pas d'ordinaire. La solution de gouvernance consiste à inclure des questions sur la sécurité de la chaîne d'approvisionnement dans les questionnaires d'évaluation des fournisseurs et à considérer la volonté et la capacité du fournisseur à y répondre comme un indicateur de maturité de la sécurité de sa chaîne d'approvisionnement.
- Étendre les questions sur la chaîne d'approvisionnement aux évaluations des éditeurs SaaS
- Interroger l'éditeur SaaS sur son programme SBOM et SCA
- Interroger sur la sécurité du pipeline de build SaaS : les mêmes questions que pour les éditeurs de logiciels installés
- Interroger sur le processus de notification des CVE pour les vulnérabilités des dépendances SaaS
- Considérer la qualité des réponses aux questions sur la chaîne d'approvisionnement comme un indicateur de maturité
Si vous êtes une petite équipe
Ajoutez trois questions sur la chaîne d'approvisionnement logicielle à votre prochaine évaluation d'un éditeur SaaS critique : tenez-vous un SBOM pour votre plateforme, comment surveillez-vous les CVE critiques de vos dépendances open source et, si votre pipeline de build était compromis et qu'un code malveillant était déployé sur votre plateforme, comment le détecteriez-vous et comment en informeriez-vous les clients ? Ces trois questions révèlent si le programme de sécurité de la chaîne d'approvisionnement de l'éditeur SaaS existe et s'il est conçu pour vous protéger, et pas seulement sa propre infrastructure.
- Demander aux éditeurs SaaS s'ils tiennent un SBOM pour leur plateforme
- Interroger sur la surveillance des CVE dans les dépendances open source
- Interroger sur la détection des compromissions du pipeline de build et la notification des clients
- Inclure des questions sur la chaîne d'approvisionnement dans l'évaluation des éditeurs SaaS
Ce qu’il faut exiger
Demandez directement :
« Pour votre plateforme SaaS : tenez-vous un SBOM, comment surveillez-vous les vulnérabilités critiques de vos dépendances open source et, si votre pipeline de build ou votre infrastructure de déploiement était compromis, quelle surveillance le détecterait et comment informeriez-vous les clients concernés ? »
Preuves attendues
- SBOM de la plateforme SaaS ou inventaire équivalent des dépendances
- Programme de surveillance des vulnérabilités des dépendances open source
- Processus de détection et de notification des compromissions du pipeline de build
- Processus de notification des clients en cas d'incident de la chaîne d'approvisionnement
Il faut interroger un éditeur SaaS qui confirme disposer de contrôles SOC 2 sur son programme de chaîne d'approvisionnement logicielle. Le SOC 2 couvre la sécurité opérationnelle. La chaîne d'approvisionnement logicielle couvre le code qui fait tourner les opérations. Les deux sont nécessaires pour obtenir une assurance sur la chaîne d'approvisionnement SaaS.
Comment le prouver
- Registres d'évaluation de la chaîne d'approvisionnement SaaS
- Examen du programme SBOM et SCA du fournisseur
- Évaluation de la sécurité du pipeline de build des éditeurs SaaS
- Mise en place d'un processus de notification des CVE
À retenir
Logiciels installés : SBOM collectés, analyse SCA en place, provenance vérifiée. Plateforme SaaS : même risque lié à la chaîne d'approvisionnement, visibilité nulle, aucun moyen de l'obtenir. La sécurité de la chaîne d'approvisionnement SaaS est entièrement gérée par l'éditeur : l'entreprise ne dispose d'aucun contrôle direct. L'évaluation du programme de l'éditeur remplace l'inspection directe des artefacts comme mécanisme d'assurance. Les pratiques en matière de SBOM, la surveillance des dépendances, la sécurité du pipeline de build et le processus de notification des CVE sont les questions sur la chaîne d'approvisionnement que l'évaluation SaaS doit inclure, en plus des questions de sécurité opérationnelle que l'évaluation SaaS standard couvre déjà.