Audit de sécurité

Que fait Audit de sécurité ?

Identifiez les vulnérabilités qui violent une véritable frontière de confiance, puis fournissez aux propriétaires les preuves sources, une reproduction sûre, la priorité et le correctif efficace le plus petit possible. Il s'agit d'un workflow défensif, prioritaire sur la source. Un candidat sans principal, ressource ou résultat de sécurité concret affecté n'est pas une constatation confirmée.

Modes de fonctionnement

Cette compétence est par défaut une orientation. Son chargement n'autorise pas le workflow d'audit complet ou la création de fichiers.

• Mode orientation : Pour les questions de sécurité, les examens ciblés, la méthodologie, le triage ou l'investigation de constatations spécifiques, utilisez uniquement les parties pertinentes de cette compétence. N'exécutez pas automatiquement les six phases, ne créez pas de répertoire de sortie et n'écrivez pas d'artefacts d'audit. Vous pouvez lancer des agents ciblés lorsque cela est utile ; ils renvoient les résultats à la tâche en cours.
• Mode audit complet : Utilisez le workflow complet lorsque l'utilisateur demande explicitement un audit ou un test de pénétration d'une base de code, demande un examen de sécurité complet, exhaustif ou de bout en bout, ou demande des artefacts de rapport. Exécutez les six phases et écrivez les fichiers définis ci-dessous.

Si la demande pourrait correspondre à l'un ou l'autre mode, posez une question ciblée avant de créer des fichiers ou de démarrer le workflow complet.

Terminologie de la plateforme

Cette compétence est neutre vis-à-vis des agents :

• Parent est l'agent qui coordonne l'exécution et possède l'état partagé.
• Outil de tâche est le mécanisme de délégation ou de sous-agent de la plateforme.
• Agent research est un agent délégué pour l'exploration ciblée de la source et la vérification factuelle.
• Agent general est un agent délégué pour une investigation large et une exécution locale limitée.
• subagent_type: dans un en-tête nomme lequel de ces deux rôles d'agent délégué exécute ce travail.

Utilisez les capacités équivalentes de la plateforme tout en préservant les limites de rôle, d'isolation d'écriture, d'invite et d'indépendance.

Sécurité d'exécution universelle

Ces règles s'appliquent dans les deux modes de fonctionnement. L'inspection de la source est en lecture seule. Exécutez les builds, tests, processus, navigateurs, émulateurs, fuzzers et traitements de fixtures contrôlés par la cible uniquement à l'intérieur d'un sandbox imposé par le système d'exploitation qui fournit tous ces contrôles :

• aucun réseau externe ; utilisez uniquement un espace de noms loopback isolé lorsque la vérification nécessite du trafic client/serveur local ;
• un environnement vide peuplé à partir d'une liste d'autorisation explicite avec des valeurs sûres, avec HOME local au scratch, des répertoires temporaires et des caches ;
• une cible et une chaîne d'outils en lecture seule, le processus contrôlé par la cible pouvant écrire uniquement dans son répertoire scratch/ assigné ; et
• des limites explicites faibles pour le CPU, la mémoire, les processus, la taille des fichiers, le disque et le temps d'horloge murale.

L'agent, en dehors du processus contrôlé par la cible, peut effectuer une copie source jetable dans un répertoire scratch/ assigné lorsqu'un build doit écrire à côté de la source. En mode orientation, ne conservez pas les fichiers contrôlés par la cible. En mode audit complet, seul le code de confiance côté parent peut promouvoir le résultat non secret minimum vers les artifacts/ conservés en utilisant la procédure sous Isolation d'écriture. N'exposez jamais un répertoire de sortie conservé (autre que le scratch/ assigné à l'agent lui-même), le répertoire d'un autre agent, le répertoire personnel de l'hôte, les identifiants, les sockets ou les services partagés au code cible. N'installez pas de dépendances et ne laissez pas les builds les récupérer. Utilisez uniquement les outils et dépendances déjà disponibles localement. Si chaque contrôle ne peut pas être appliqué, n'exécutez pas le code cible : signalez la capacité de sandbox manquante comme un blocage nécessitant une validation et fournissez un plan de validation sûr.

Utilisez des principaux, fixtures et secrets factices. Ne sondez pas les points de terminaison déployés, les services externes, les infrastructures partagées, les identités de production, les données d'autres utilisateurs ou les plans de contrôle en direct. Ne testez pas la disponibilité sur un processus en direct ou partagé, ne publiez pas d'artefacts, ne modifiez pas les versions, ne dépensez pas de quota d'API payant et ne continuez pas au-delà de l'effet local minimum nécessaire pour établir un défaut. Si le fait décisif se trouve en dehors de la source ou de la fixture en sandbox, signalez-le comme nécessitant une validation.

Configuration de l'audit complet

En mode audit complet, résolvez ces valeurs avant la reconnaissance :

• Répertoire de la compétence : le répertoire absolu contenant ce SKILL.md.
• Cible : le répertoire racine absolu du dépôt sous examen.
• Nom du dépôt : un identifiant de dépôt stable provenant du répertoire ou du référentiel Git local distant.
• Répertoire de sortie : un nouveau répertoire inscriptible en dehors de la cible, par défaut ~/security-audit-skill/<nom-du-depot>/run-<N>, où <N> est le prochain entier non utilisé. Utilisez un répertoire à l'intérieur de la cible uniquement lorsque l'utilisateur le sélectionne explicitement et que le parent vérifie que le contrôle de version ignore l'ensemble du répertoire. Sinon, arrêtez-vous et demandez un chemin externe.
• Référence source : le commit examiné et si l'arbre de travail est modifié. Ne traitez pas les fichiers générés ou modifiés non examinés comme une autre révision.

Isolation d'écriture

Le parent crée et est le seul rédacteur des fichiers d'exécution partagés :

• run-metadata.json
• architecture.md
• coverage-ledger.json
• findings.json
• REPORT.md
• FINDINGS-DETAIL.md
• NEEDS-VALIDATION.md

Chaque chasseur ou vérificateur reçoit une racine unique sous <output-dir>/agents/<agent-id>/, avec des répertoires scratch/ et artifacts/ séparés. Les ID d'agent canoniques correspondent à ^[a-z0-9][a-z0-9_-]{0,63}$ et ne doivent pas être égaux à un nom de périphérique Windows tel que con, prn, aux, nul, com1 à com9 ou lpt1 à lpt9. Les ID en minuscules évitent les collisions de casse. L'agent et chaque processus contrôlé par la cible peuvent écrire uniquement dans scratch/ ; les artifacts/ conservés sont la propriété du parent, ne sont jamais exposés au sandbox et sont inscriptibles uniquement par un code de promotion de confiance côté parent. Les agents ne peuvent pas modifier les fichiers partagés, la source cible, les artefacts conservés ou le répertoire d'un autre agent. N'utilisez pas /tmp ou le répertoire personnel de l'hôte comme solution de repli inscriptible.

Avant l'exécution, le parent ouvre et conserve des descripteurs de répertoire de confiance et non héritables pour les racines scratch/ et artifacts/ de l'agent, et enregistre une liste d'autorisation des fichiers d'artefact attendus relatifs au scratch ainsi que des limites explicites par fichier et cumulatives en octets. Ne transmettez jamais ces descripteurs à l'agent ou au sandbox. Après la fin du sandbox et de tous ses processus, le code de confiance côté parent promeut chaque fichier de la liste d'autorisation séparément :

1. Validez le chemin relatif déclaré : rejetez les composants absolus, vides, ., .. ou les liens symboliques.
2. Parcourez chaque composant parent à partir du descripteur de racine scratch conservé avec des opérations relatives au répertoire sans suivi ; ne rouvrez jamais par chemin.
3. Ouvrez la feuille sans suivi et non bloquante.
4. Vérifiez avec fstat qu'il s'agit d'un fichier régulier avec un nombre de liens exactement égal à un et dans les limites par fichier et cumulatives en octets enregistrées.
5. Appliquez à nouveau ces limites lors de la lecture à partir de ce descripteur.
6. Copiez exactement la taille vérifiée, répétez fstat et rejetez une identité, un type, un nombre de liens ou une taille modifié.
7. Pour la destination, parcourez chaque composant parent à partir du descripteur de racine d'artefacts conservé avec des opérations relatives au répertoire sans suivi ; exigez que chaque composant existant soit un véritable répertoire, et créez tout répertoire manquant exclusivement avant de le rouvrir et de le vérifier sans suivi.
8. Créez la feuille exclusivement sans suivre les liens, vérifiez que la destination ouverte est un fichier régulier avec un nombre de liens exactement égal à un, et copiez à partir du descripteur source vérifié sans rouvrir aucun des deux chemins.
9. Utilisez des API équivalentes et sûres contre les courses sur les systèmes non POSIX.
10. Ne copiez jamais récursivement ou globalement le scratch, n'extrayez pas d'archive dans les artefacts, et n'ouvrez ni ne promouvez un lien symbolique, un FIFO, un socket, un périphérique, un répertoire, un fichier lié en dur, un fichier changeant ou un fichier qui dépasse sa limite.
11. Si une vérification n'est pas disponible, ne peut pas être appliquée ou échoue, jetez l'entrée scratch ; s'il s'agit d'une preuve décisive, conservez needs_v