Que fait Audit de sécurité préproduction ?
Produire une évaluation de sécurité utile à la prise de décision pour la version spécifiée. Expliquer ce qui a été examiné, ce que les preuves soutiennent, ce qui reste inconnu, et comment corriger et vérifier chaque problème. Par défaut, le rapport est en anglais sauf si l'utilisateur demande une autre langue.
Utiliser uniquement les capacités disponibles et autorisées de l'hôte actuel. Résoudre les références groupées par rapport à ce dossier de compétence. L'accès aux fichiers locaux, aux shells/scanners, à la navigation, aux connecteurs et à la délégation ne sont pas présumés. Lorsqu'une capacité n'est pas disponible, examiner les preuves fournies et enregistrer les lacunes U-###. Si la destination du système de fichiers demandée ne peut pas être écrite, fournir le rapport en tant qu'artefact téléchargeable ou texte Markdown et indiquer cette limitation de livraison.
Calibrer avant de sélectionner les vérifications
- Identifier l'évaluation demandée, la version ou le commit cible, la cible de déploiement, les preuves disponibles et l'autorisation existante. Préserver la portée et les réponses antérieures de l'utilisateur.
- Lire les questions d'orientation. Résoudre Q-00 avant d'inspecter le contenu du dépôt si la revue du dépôt n'a pas déjà été demandée ou clairement incluse. Une demande d'audit du dépôt ou du code y répond déjà ; ne pas redemander. Si l'utilisateur exclut la revue du dépôt, travailler à partir des documents/configuration/preuves d'exécution sélectionnés et enregistrer la limite.
- Inspecter uniquement les métadonnées et la documentation du projet dans le périmètre sans exécuter le code du projet. Enregistrer les faits séparément des inférences et des déclarations de l'utilisateur. Poser un petit lot de questions matérielles restantes et bifurquer par produit, exposition, hébergement, identité, données et accès disponible. Poursuivre le travail autorisé de manière indépendante en attendant ; le silence ne répond pas à un choix de portée non résolu.
- Enregistrer un instantané de la portée, les modules sélectionnés, les identifiants de contrôle applicables, les vérifications autorisées et les questions non résolues dans le rapport. Mettre à jour cet instantané lorsque les réponses modifient la portée.
Router vers les modules pertinents
Toujours utiliser la méthode d'audit et les constats et priorités. Charger les détails du module uniquement lorsque leur surface est présente ou nécessite une enquête. Ne pas charger chaque module simplement parce qu'il existe.
Utiliser la carte de couverture à 35 domaines pour relier les domaines d'évaluation d'origine aux identifiants de contrôle. Lorsque des vérifications assistées par outils sont dans le périmètre, suivre les procédures d'exécution des scanners pour Gitleaks, Semgrep CE, Trivy et ZAP ; sélectionner les outils en fonction des preuves et de la disponibilité, et enregistrer les exécutions réelles, les erreurs et les omissions. Une demande manuelle uniquement n'active pas les scanners.
Pour les inventaires de dépendances, réutiliser d'abord un SBOM correspondant à la cible, puis utiliser Trivy si la génération est nécessaire et autorisée. Les graphes de paquets natifs, Syft et l'analyse des imports sources sont des suppléments optionnels ; suivre la procédure d'inventaire dans la même référence. Garder les relations de paquets séparées des imports de code et des relations d'exécution.
| Surface | Module | Conseils de routage |
|---|---|---|
| Chaque évaluation | Architecture | Établir les actifs, les limites de confiance, les actions critiques, l'exposition et la responsabilité. |
| Comptes, autorisations, locataires, sessions ou identités de service | Identité et accès | Inclure les identités d'infrastructure même si le produit n'a pas de connexion. |
| Interfaces Web, API, workers, fichiers ou intégrations | Application et API | Sélectionner les contrôles pour les chemins d'entrée, sortie, protocole et métier réels. |
| Données, identifiants, cryptographie, bases de données ou stockage | Données et secrets | Inclure les identifiants et les métadonnées même lorsque les données personnelles sont absentes. |
| Un service déployé ou un déploiement prévu | Infrastructure et déploiement | Correspondre au fournisseur et au modèle de déploiement ; distinguer la configuration prévue de l'exécution observée. |
| Source, dépendances, construction ou processus de publication | Chaîne d'approvisionnement | Lorsque la revue du dépôt est incluse, inspecter les définitions CI/CD découvertes, leurs scripts/modèles, les transitions de confiance et les barrières de déploiement sans attendre une deuxième question d'autorisation. Les paramètres de plateforme effectifs restent une source de preuve distincte. |
| Un service entrant ou déjà en service | Opérations et résilience | Évaluer la détection, la récupération, la gestion des incidents, la disponibilité et la propriété. |
| LLMs, RAG, outils IA, agents ou MCP | IA et agents | Examiner les entrées du modèle, l'accès aux données, l'autorité déléguée, les sorties et les limites de ressources. |
| Client mobile, bureau ou extension de navigateur | Mobile et bureau | Sélectionner les sections de plateforme et auditer le backend séparément. |
Pour les surfaces spécialisées non prises en charge, telles que les équipements industriels ou le matériel personnalisé, documenter la limite de couverture et la revue spécialisée requise. Ne pas laisser entendre que les modules logiciels les évaluent complètement.
Examiner et enregistrer
- Suivre les règles de preuve, d'autorisation et d'exécution de la méthode d'audit. Une demande d'audit autorise l'analyse et la création de rapport ; elle n'autorise pas automatiquement les modifications de production, les sondes destructrices ou la publication de résultats sensibles.
- Une revue de dépôt couvre les fichiers convenus, les chemins sources, les manifestes, l'historique pertinent et les définitions CI/CD. Elle inclut les secrets codés en dur, les valeurs de repli non sécurisées, les destinations spécifiques à l'environnement et la politique de sécurité/identité fixe. Honorer les exclusions de chemin/historique plus étroites ; ne pas étiqueter les constantes ordinaires comme des vulnérabilités sans conséquence de sécurité.
- Maintenir un registre des preuves, une matrice de contrôle, des constats, des inconnues, des bords de chemin d'audit et des bords de dépendance pendant le travail. Relier toutes les allégations matérielles à des emplacements sources exacts ou à des observations et à la version/environnement inspectés.
- Traiter la sortie du scanner comme un indice jusqu'à contextualisation. Tracer les appelants, les gardiens, les chemins de données, la configuration et les hypothèses de déploiement pertinents avant d'attribuer un défaut confirmé ou une conséquence de publication.
- Après l'inventaire, appliquer le triage ciblé des avis actuels du module de chaîne d'approvisionnement (SC-003), en priorisant les composants critiques et les problèmes connus exploités ou critiques/élevés. Enregistrer les correspondances exactes de paquet/version, les sources datées, les correctifs vérifiés, l'exposition locale et la couverture interrogée ; les recherches hors ligne ou échouées restent des lacunes explicites.
- Utiliser le même identifiant de contrôle dans la couverture, les constats, la correction et les graphiques. Dédupliquer les constats ayant la même cause sous-jacente tout en préservant les surfaces affectées.
- Pour les longues revues, déléguer les modules indépendants lorsqu'ils sont pris en charge. Donner à chaque réviseur la portée et l'attribution d'ID, puis réconcilier les limites de confiance partagées et les allégations contradictoires avant de rédiger le rapport.
- Si l'accès ou un outil n'est pas disponible, enregistrer la limitation et continuer le travail utile. Une vérification échouée n'est pas une vérification réussie. Un contrôle inconnu n'est pas non applicable.
Livrer le rapport
Utiliser le modèle de rapport. Par défaut, créer un nouveau fichier à security-audits/<YYYY-MM-DD>-<revision-or-target>/security-audit.md dans le projet audité sauf si l'utilisateur spécifie une autre destination. Utiliser un suffixe sans conflit si cette destination existe déjà. Ne pas enregistrer les rapports cibles dans cette compétence, écraser une évaluation antérieure, ou valider/télécharger des rapports sauf demande.
Inclure les deux diagrammes Mermaid requis :
- Graphe du chemin d'analyse : la piste d'audit observable de la portée et des artefacts à travers les vérifications effectuées jusqu'aux constats, aux conclusions soutenues et aux lacunes. Montrer ce qui a été inspecté et où une vérification s'est arrêtée. Il s'agit d'une carte des preuves, pas d'un raisonnement privé ou d'une chronologie inventée.
- Graphe des dépendances analysées : les composants inspectés, les dépendances de paquets, les services, les systèmes d'identité, le stockage et les intégrations externes, avec des types de bords explicites, des références de preuves et une couverture d'inspection. Inclure les limites matérielles non inspectées comme telles.
Construire les graphiques à partir des registres en utilisant le contrat de graphique dans la méthode d'audit. Inclure des tables de nœuds/bords pour que le rapport reste utilisable sans rendu Mermaid. Diviser les grandes cartes de dépendances par exécution/service, paquet/construction, ou relations de confiance CI/CD sous la section des dépendances. Pour les pipelines examinés, montrer déclencheur/entrée → tâche → exécuteur/identité → artefact → environnement, avec les barrières réelles, les limites de confiance et les paramètres non inspectés distingués.
Le rapport doit contenir un plan de correction priorisé, des propriétaires ou des rôles non attribués, des dépendances entre les correctifs, des tests d'acceptation, des risques résiduels et des décisions non résolues. Énoncer une recommandation de préparation limitée en utilisant les règles de constats ; la compétence n'approuve pas un déploiement ou ne certifie pas la conformité.
Vérification qualité finale
- Vérifier la portée, la révision, les liens de preuves, les statuts de contrôle et tous les ID de constats/inconnues concordants dans le texte, les tableaux, les graphiques et le plan.
- Vérifier les directions et les étiquettes des bords du graphique. Marquer distinctement les déclarations, le comportement observé, les inférences et les preuves indisponibles. Supprimer toutes les données d'exemple de modèle.
- S'assurer qu'aucun identifiant, échantillon de données personnelles, contenu sensible d'invite ou identifiant d'infrastructure privé n'est divulgué inutilement.
- Chaque constat nécessite une correction concrète et un critère de vérification. Chaque inconnue critique nécessite une action suivante et sa conséquence de décision de publication.
- Indiquer quelles vérifications ont réellement été effectuées, lesquelles ont échoué ou ont été ignorées, et si les diagrammes ont été rendus ou seulement examinés pour la syntaxe. Ne jamais prétendre à un test, un rendu ou une vérification d'exécution qui n'a pas eu lieu.
- Livrer l'emplacement du fichier, les principaux bloqueurs de publication et les limites de couverture de manière concise. Laisser la mise en œuvre des correctifs à un suivi autorisé, sauf si déjà inclus dans la demande.