TL; DR
La plupart des exigences de sécurité en matière de développement logiciel sont formulées sous forme d'intentions, ce qui signifie que personne ne peut les respecter ou les rejeter. « Les dépendances doivent être sécurisées » est une formulation acceptable qui résiste à l'examen, jusqu'au moment où un auditeur demande à consulter le dossier. Cette liste de contrôle des exigences de sécurité logicielle vous propose 12 lignes formulées à l'inverse.
- Une exigence n'est vérifiable que lorsque trois conditions sont réunies. Un artefact nommé, un moment où il est vérifié et un comportement défini en cas d'échec de la vérification. La plupart des exigences de sécurité logicielle échouent dès la première étape.
- Chacune des 12 lignes apporte des preuves. Une attestation de provenance, une SBOM lié à une version publiée, un horodatage de révocation, une porte decisRapport d'analyse avec le propriétaire. Ceci n'est pas un rapport de scanner.
- Ils se sont divisés en trois groupes. Qu’est-ce qui entre dans votre logiciel, qu’est-ce qui le construit et qu’est-ce qui prouve son état ?
- Les vérifier est une SSCS et ASPM Problème, pas un problème de scanner. Six outils produisent six dashboardUn auditeur exige une seule réponse. Les preuves doivent provenir d'une source unique, sinon elles ne sont pas recevables.
Pourquoi la plupart des exigences de sécurité en matière de développement logiciel échouent-elles dès qu'elles font l'objet d'un audit ?
Ouvrez presque n'importe quel document d'exigences de sécurité, et vous y trouverez des phrases comme « les composants tiers doivent être exempts de vulnérabilités connues » et « la construction pipeline « Doit être sécurisé ». Ils se lisent bien. Ils résistent à la relecture. Et puis un auditeur, un questionnaire de sécurité client, ou un NIS2 or DORA L'évaluateur pose une question simple : montrez-moi.
À ce stade, l'exigence s'effondre, car personne n'a défini précisément ce que signifie « exempt de vulnérabilités connues », à quel moment du cycle de vie cela s'applique, qui en décide et quel fichier fournir. L'équipe se démène, exporte un rapport d'analyse et espère que le nombre de résultats obtenus témoignera de la diligence requise.
Le problème ne réside pas dans l'effort fourni. Les équipes qui utilisent quatre ou cinq outils accomplissent déjà un travail considérable. Le problème vient du fait que les exigences de sécurité logicielle ont été rédigées pour décrire un état souhaité plutôt qu'un événement vérifiable. Un état souhaité n'est pas étayé par des preuves. Un événement, en revanche, l'est. C'est sur cette distinction que repose tout ce qui rend la sécurité du développement logiciel auditable.
Qu’est-ce qui rend une exigence de sécurité logicielle vérifiable ?
Trois propriétés, et une exigence nécessite les trois :
- Un artefact nommé. Une attestation, une SBOM, un disque signé, une porte decision. Un élément qui existe sous forme de fichier ou d'entrée de journal et qui peut être produit sur demande.
- Un instant. Pull request, construire, publier ou en continu. « À un moment donné dans le SDLC« n’est pas un moment. »
- Un comportement de défaillance défini. Que se passe-t-il en cas d'échec du contrôle : blocage, avertissement, mise en quarantaine ou redirection vers un propriétaire désigné avec une procédure d'exception documentée ?
Vérifiez que vos exigences actuelles répondent à ces trois critères. La plupart échoueront au premier, ce qui explique pourquoi les équipes finissent par négocier avec les auditeurs au lieu de leur répondre.
Les 12 lignes ci-dessous sont rédigées de manière à satisfaire chacune aux trois conditions. Elles sont volontairement ennuyeuses. Les exigences vérifiables le sont généralement.
Liste de contrôle des exigences de sécurité pour le développement logiciel : 12 lignes vérifiables
Chaque ligne indique l'artefact qui le prouve, la question qui le met à l'épreuve et la provenance des preuves.
Groupe 1 : ce qui entre dans votre logiciel
| Exigence | Vérifier par | Preuve |
|---|---|---|
| 01Chaque dépendance est analysée pour détecter tout comportement malveillant sans attendre la publication d'une signature. | Demande de verdict de sélection pour tout colis ajouté au cours des 30 derniers jours | Alerte précoce contre les logiciels malveillants détecte les paquets malveillants dans le code, pipelines, IaC et les registres avant même l'existence d'une signature ou d'un avis, en utilisant la détection de preuves suivie d'une validation par IA |
| 02Chaque version a un SBOM, récupérable par version, généré par la compilation plutôt qu'assemblé manuellement | Nommer une version publiée et demander ses SBOM en moins de cinq minutes | SBOM génération par build, avec rapport de divulgation des vulnérabilités joint |
| 03Une vulnérabilité ne bloque une publication que si elle est accessible dans votre code. | En prenant trois résultats bloqués et en se demandant quel chemin fonctionnel les rend exploitables, on peut s'avérer utile. | Accessibilité au niveau fonctionnel, exploitabilité et EPSS dans le processus de priorisation |
| 04Les composants vulnérables connus ont un propriétaire et un decision, pas seulement un billet | Choisir une constatation critique non résolue et demander qui a accepté le risque, et jusqu'à quand. | La propriété et le statut sont suivis directement pour chaque actif, et non par rapport à une analyse. |
| 05Les dépendances liées à l'IA et à l'apprentissage automatique sont traitées comme une chaîne d'approvisionnement ordinaire, car elles le sont. | Quelles vulnérabilités CVE affectent les bibliothèques ML en production aujourd'hui ? | Analyse de la composition couvrant la pile d'IA sur la même plateforme que les ressources d'IA qui l'utilisent. |
Deuxième groupe : ce qui constitue votre logiciel
| Exigence | Vérifier par | Preuve |
|---|---|---|
| 06Chaque compilation génère une attestation de provenance qui peut être vérifiée indépendamment. | Récupération de l'attestation de l'artefact de production le plus récent et vérification par rapport à la source commit | SLSA provenance et attestations personnalisées intégrales avec des signatures sans clé, stockées dans n'importe quel registre, avec blocage des éléments falsifiés avant la livraison |
| 07Pipeline La configuration est analysée comme du code, à la même cadence que le code de l'application. | Demander quand la dernière modification de configuration de GitHub Actions ou de Jenkins a fait l'objet d'un examen de sécurité, et par qui. | CI/CD Sécurité pipeline mauvaise configuration, flux de travail perturbés et risques liés à la chaîne d'approvisionnement, avec SSCS conformité intégrée |
| 08Tout secret découvert à n'importe quel moment du cycle de vie est levé, et non simplement rapporté. | Demande des cinq derniers secrets détectés et de leurs dates de révocation | Détection dans le code, les configurations, les conteneurs et pipelineavec plus de 100 types secrets, plus révocation automatique playbooks par type de titre |
| 09Activité anormale dans le pipeline donne l'alerte avant que cela ne devienne un incident | Demander ce qu'est un coureur compromis ou un coureur inhabituel commit Le schéma se déclencherait, et qui le recevrait | Détection d'une anomalie sur une activité qui précède une attaque |
Troisième groupe : ce qui prouve l’état de votre logiciel
| Exigence | Vérifier par | Preuve |
|---|---|---|
| 10L'infrastructure en tant que code est contrôlée avant la fusion, et non corrigée après le déploiement. | La question est de savoir si une modification Terraform non sécurisée peut atteindre la branche principale, et ce qui l'empêche. | IaC numérisation avec guardrails au pull request |
| 11Les résultats de tous les outils, les vôtres et ceux de tiers, partagent un même modèle de gravité. | Demander à votre équipe si une alerte critique provenant d'un scanner et une alerte critique provenant d'un autre scanner signifient la même chose. | Le ASPM couche ingère les résultats de SAST, SCA, DAST et IaC Les outils que vous utilisez déjà, quel que soit leur concepteur, appliquent la même priorisation, le même triage, les mêmes explications et les mêmes mesures correctives que pour les résultats natifs. |
| 12Chaque ressource d'IA du code source est inventoriée et exportable. | Demander quels modèles, agents et serveurs MCP sont exécutés dans vos applications, et demander le fichier | Découverte continue de modèles, de cadres, d'ensembles de données, de points d'accès d'inférence, d'agents, de serveurs MCP, de compétences, d'invites et d'outils de codage IA, avec un CycloneDX ML-BOM généré à chaque analyse |
À qui est responsable chaque ligne de la liste de contrôle ?
Un document d'exigences sans colonne « responsable » est une liste de souhaits. Attribuez chaque ligne avant de le publier :
La deuxième colonne est celle qui échoue en pratique. La vérification continue ne fonctionne que lorsque les preuves s'accumulent d'elles-mêmes.
Comment vérifier une liste de contrôle des exigences de sécurité du développement logiciel sans ajouter de console supplémentaire ?
C’est à ce stade que la plupart des programmes s’enlisent. Les 12 exigences mentionnées ci-dessus impliquent des dépendances. pipelineVous créez des artefacts, des secrets, du code d'infrastructure et des ressources d'IA. Vérifiez-les avec six outils différents, et vous créez une septième tâche : la réconciliation de six éléments. dashboards en une seule réponse pour un auditeur qui souhaite un seul chiffre.
Deux capacités rendent cela gérable.
- Software supply chain security (SSCS) couvre les exigences qui existent entre les commit et l'artefact. Dépendances, pipelineL'intégrité des systèmes, les secrets et les activités anormales constituent une surface d'attaque, et c'est également de là que proviennent les preuves les plus difficiles à falsifier : une attestation signée vaut plus pour un évaluateur qu'un rapport de scanner, car elle ne peut pas être régénérée après coup.
- ASPM c'est la couche qui transforme les résultats en une position que vous pouvez rapporter. C'est important ici pour une raison précise : le système exploite les données produites par vos scanners existants. Vous n'avez pas besoin de remplacer les outils que vous avez déjà achetés pour répondre à cette liste de contrôle. Ses résultats deviennent une entrée, et la même priorisation, le même triage par IA, les mêmes explications et les mêmes corrections s'appliquent à ces résultats ainsi qu'aux résultats natifs. Un programme de sécurité du développement logiciel construit sur une plateforme qui ne comprend que ses propres scanners échouera systématiquement dès que les environnements sont hétérogènes, et tous les environnements le sont.
Qu’est-ce qui change lorsqu’un agent écrit le code ?
Tout ce qui précède part du principe qu'une personne a rédigé la modification et qu'une autre l'a vérifiée. Cette hypothèse est en train de disparaître, ce qui redéfinit le champ d'application de la sécurité du développement logiciel.
Lorsqu'un agent de codage produit mille fichiers par semaine, la revue de code cesse d'être un contrôle et devient une file d'attente. Dans ce contexte, trois des douze lignes de code sont cruciales : le filtrage des dépendances malveillantes (car les agents téléchargent rapidement les paquets, et les noms de paquets erronés constituent désormais un vecteur d'attaque connu). pull request analyse classée par exploitabilité plutôt que par gravité brute, et inventaire des actifs d'IA.
Il existe également une quatrième exigence qu'il convient d'ajouter à toute liste de contrôle des exigences de sécurité logicielle rédigée en 2026 : Les fichiers de configuration qui pilotent vos outils d'IA sont analysés en tant qu'éléments de sécurité. Les fichiers de compétences, les fichiers de règles et les configurations du serveur MCP sont commitCes instructions sont présentées sous forme de texte brut et examinées comme s'il s'agissait de documents ; elles définissent ce qu'un assistant doit faire et ce à quoi il est autorisé à accéder.
Comment passe-t-on d'une liste de contrôle à des preuves concrètes ?
Ne commencez pas par réécrire l'intégralité du document. Prenez les trois lignes que votre prochain audit, questionnaire client ou examen par le conseil d'administration testera réellement, généralement SBOM Sur demande, révocation secrète et traçabilité. Prouvez ces trois points de bout en bout, artefact en main. Puis, approfondissez.
La liste de contrôle des exigences de sécurité du développement logiciel n'est pas un document d'exercicecise. C’est la différence entre un programme de sécurité capable de répondre aux questions et un programme qui ne peut que se décrire. Douze lignes vérifiables valent mieux que quarante lignes théoriques, car douze d’entre elles résistent à l’épreuve d’une vérification par une personne qui demande à consulter le dossier.
Si vos exigences de sécurité logicielle ne permettent pas de produire un artefact à la demande, vous n'avez pas d'exigences. Vous avez des intentions, associées à un numéro de version.
Voyez ce que votre patrimoine prouve déjà. Connectez un dépôt, et Xygéni renvoie vos dépendances, pipelines, secrets, statut d'intégrité des bâtiments et inventaire de l'IA dans une vue d'ensemble unique, avec les preuves associées à chaque constatation. Commencer gratuitement or réserver une démo.
QFP
Combien d'exigences de sécurité logicielle une liste de contrôle doit-elle comporter ?
Moins que vous ne le pensez. Le nombre pertinent est celui que vous pouvez vérifier sur demande, généralement entre 10 et 20. Une liste de 60 exigences dont 45 ne sont étayées par aucune preuve est moins fiable qu'une liste de 12 où chaque critère est justifié par un élément concret. Commencez par les critères que votre prochain audit vérifiera et élargissez votre liste progressivement.
Quelle est la différence entre la sécurité du développement logiciel et un cadre de conformité ?
Un cadre de référence comme NIS2, DORA ou la loi sur la cyber-résilience (Cyber Resilience Act) définit les résultats attendus. La sécurité du développement logiciel permet de transformer ces résultats en contrôles que votre équipe d'ingénierie peut valider ou invalider selon un critère donné. pull request ou construire. Les cadres sont conçus pour les évaluateurs, les exigences pour les développeurs, et la plupart des difficultés rencontrées dans un programme de conformité proviennent du fait que personne n'effectue cette traduction.
Puis-je vérifier une liste de contrôle des exigences de sécurité logicielle avec les scanners que je possède déjà ?
En partie. Les scanners produisent des résultats, et plusieurs de ces exigences nécessitent plutôt des artefacts : une attestation de provenance, un SBOM lié à une version publiée, un enregistrement de révocation, une porte decision avec un propriétaire. C'est pourquoi la liste de contrôle se trouve sur SSCS et ASPM Plutôt que d'utiliser un scanner, la solution pratique consiste à conserver vos scanners existants et à ajouter une couche supérieure qui centralise leurs données et applique un modèle de priorisation unique à l'ensemble d'entre elles.
Quelle est la consigne que les équipes interprètent le plus souvent mal ?
Secrets. Presque toutes les listes de contrôle indiquent que les secrets ne doivent pas être commitIl est rare qu'une information secrète détectée soit révoquée dans un délai précis. Or, sans révocation, une authentification reste active dans l'historique du dépôt, et cet historique est public dès que le dépôt est supprimé. En reformulant cette exigence de révocation avec un horodatage, elle devient vérifiable.
