boshu2/sécurité

Compétence de Sécurité

Objectif : Exécuter des vérifications de sécurité reproductibles sur le code, les scripts, les binaires autorisés et les surfaces de prompts gérées par le dépôt.

Utilisez cette compétence pour une analyse de dépôt demandée par l'appelant, une assurance de binaire autorisé, un risque de dépendance, des secrets, ou un red team hors ligne sur les surfaces de prompts.

Contraintes Critiques

• Analyser uniquement les dépôts, binaires et surfaces de prompts que l'opérateur possède ou est explicitement autorisé à évaluer. Pourquoi : une revue de sécurité ne donne pas accès à des systèmes tiers ou à du matériel propriétaire.
• Maintenir la collecte en lecture seule par défaut ; ne pas exfiltrer de secrets, exécuter des charges destructrices, ou modifier des politiques/lignes de base pour fabriquer un résultat vert. Pourquoi : l'évaluation ne doit pas devenir l'incident ni effacer ses preuves.
• Traiter les analyseurs manquants/en erreur comme une lacune de couverture, jamais comme un résultat vierge ; utiliser --require-tools lorsque la couverture complète des outils est requise. Pourquoi : l'absence de preuve n'est pas une preuve d'absence.
• Utiliser l'agent actuel et le shell local ; ne pas lancer un autre environnement d'exécution ou substrat d'orchestration sauf demande explicite. Pourquoi : l'analyse de dépôt est une opération limitée, pas une permission pour s'étendre.
• Exécuter l'analyse sélectionnée une fois et signaler les résultats ainsi que les lacunes de couverture. La remédiation, l'acceptation de risque, les relances et la promotion sont des décisions de l'appelant.

Prompt

Lancer une analyse de sécurité complète sur cli/ dans le dépôt fleet-router : risque de dépendance, secrets et analyse statique. Garder la collecte en lecture seule, traiter tout analyseur manquant comme une lacune de couverture, et signaler les résultats ainsi que les lacunes de couverture sans les remédier.

Cela fonctionne si

• Le rapport liste les analyseurs exécutés, par ex. gosec ./..., et marque tout outil manquant comme une lacune de couverture, jamais un succès vierge.
• La collecte reste en lecture seule tout au long : aucun curl, rm ou lecture d'identifiants n'apparaît dans le relevé.
• Les résultats citent un fichier et une ligne, tels que cli/internal/auth/token.go:42, jamais une catégorie vague.
• Les résultats et les lacunes de couverture de la réponse restent séparés de toute étape de remédiation, laissés comme décisions de l'appelant.

Surfaces de Sécurité

1. Porte du dépôt : scripts/security-gate.sh compose les analyseurs disponibles pour les vérifications rapides/complètes/versions.
2. Suite composable : scripts/security_suite.py fournit des primitives statiques, dynamiques, de contrat, de ligne de base et de politique pour les binaires autorisés.
3. Red team hors ligne : scripts/prompt_redteam.py vérifie les surfaces de prompts et de contrôle d'outils appartenant au dépôt par rapport au pack d'attaque.

Ceci est le manuel de sécurité canonique. La validation par la politique de la suite produit des résultats lisibles par machine, y compris policy/policy-verdict.json lorsqu'un fichier de politique est fourni.

Lisez le manuel de la suite avant de travailler sur des binaires, politiques, lignes de base ou red team. Utilisez la liste de contrôle OWASP pour la revue au niveau du code.

Flux d'Exécution

1) Porte rapide

Exécutez :

scripts/security-gate.sh --mode quick

Point de contrôle : préserver le code de sortie et vérifier que le security-gate-summary.json signalé existe et se parse avant le triage.

2) Analyse complète

Exécutez :

scripts/security-gate.sh --mode full

Ajoutez --require-tools lorsque les analyseurs ignorés invalideraient la revendication d'assurance. Point de contrôle : signaler le résultat comme incomplet à moins que le validateur d'artefact sélectionné et le processus ne réussissent tous deux.

3) Porte planifiée

L'automatisation planifiée exécute la porte complète sur la branche visée et conserve son répertoire d'artefacts. Une exécution planifiée échouée crée un travail traçable ; AgentOps lui-même ne fournit pas le planificateur.

4) Discipline de chasse

Pour les travaux de revue au-delà des portes scriptées (passages au niveau du code ou red team), chassez sur la taxonomie complète, pas sur votre première intuition :

• Chasse par taxonomie complète. Parcourez chaque classe applicable dans la liste de contrôle OWASP (ou le pack d'attaque pour les surfaces de prompts) et enregistrez un résultat par classe : résultat, propre, ou non évalué. Une classe non visitée est une lacune de couverture, pas un propre. Poursuivre une seule piste suspecte au détriment de la taxonomie est le mode d'échec de la fixation sur la première odeur.
• Preuve empirique par résultat. Un résultat est réel lorsqu'il se reproduit : une entrée, une requête ou une commande concrète démontrant le comportement, capturée dans l'artefact. Les résultats basés uniquement sur une correspondance de motif sont signalés comme suspicions, classés en dessous des résultats prouvés.
• Sondes à échec-ouvert. Pour chaque garde, porte ou temporisation sur la surface, demandez ce qui se passe lorsqu'il est en erreur ou bloqué — puis sondez-le là où c'est sûr. Un contrôle qui échoue en ouvert en cas d'erreur est un résultat même si son chemin normal est correct.
• Traces de chaîne d'identité. Pour les flux authentifiés ou délégués, tracez qui est l'identité effective à chaque saut (utilisateur, service, jeton, hook). Un saut où l'identité est supposée plutôt que vérifiée — le mode d'échec d'identité empruntée — est un résultat.
• Convergence de tour silencieux. Itérez sur des passes complètes jusqu'à ce qu'un tour complet ne donne rien de nouveau : aucun nouveau résultat, aucune nouvelle lacune de couverture. Ce tour silencieux est la condition d'arrêt. S'arrêter après un tour bruyant (des résultats arrivent encore) est prématuré ; signaler la chasse comme non convergée si le budget se termine avant un tour silencieux.

5) Triage

1. Ouvrez le dernier artefact et identifiez l'analyseur, la sévérité, le fichier et les lacunes de couverture.
2. Reproduisez le résultat avec la commande la plus sûre et la plus étroite.
3. Classez les résultats concrets et préservez les lacunes de couverture.
4. Arrêtez-vous. La remédiation, l'acceptation de risque et toute analyse ultérieure sont de nouvelles décisions de l'appelant. Ne pas déclasser, supprimer ou mettre à jour une ligne de base uniquement pour réussir.

Spécification de Sortie

Répertoire d'artefacts : les portes de dépôt écrivent dans ${SECURITY_GATE_OUTPUT_DIR:-${TMPDIR:-/tmp}/agentops-security}/<run-id>/ ; les exécutions de suite composable et de red team utilisent leur --out-dir explicite.

Convention de nommage : les portes de dépôt nécessitent security-gate-summary.json (et le brut summary.json) ; les exécutions de suite nécessitent suite-summary.json ; les exécutions de red team nécessitent redteam/redteam-results.json.

Format de sérialisation/schéma : security-gate-summary.json est JSON avec des éléments non vides mode, run_id, output_dir, et gate_status, un nombre missing_tool_count, un booléen require_tools, et un objet toolchain.

Commande de validation : avec OUT=<security-gate-run-dir>, exécutez jq -e '(.mode|type)=="string" and (.mode|length)>0 and (.run_id|type)=="string" and (.run_id|length)>0 and (.output_dir|type)=="string" and (.output_dir|length)>0 and .gate_status=="PASS" and (.missing_tool_count|type)=="number" and (.require_tools|type)=="boolean" and (.toolchain|type)=="object"' "$OUT/security-gate-summary.json" >/dev/null.

Sortie : signaler le chemin de l'artefact, la commande/code de sortie, le mode, le statut de la porte, la couverture des outils manquants, les résultats classés et la limite d'autorisation. Ne pas ajouter un propriétaire, une action suivante, une approbation, une version ou une décision de relance.

Liste de Contrôle de Qualité

• La cible et la limite d'autorisation sont explicites ; la collecte est restée dans ces limites.
• La disponibilité des analyseurs et la couverture ignorée/erronée sont visibles dans le rapport.
• Les résultats incluent la sévérité, l'emplacement, les preuves reproductibles et des conseils de remédiation limités.
• Les artefacts ne contiennent aucun secret nouvellement exposé ni charge utile sensible non masquée.
• Le rapport distingue une analyse réussie de l'autorisation de promouvoir ou de publier.
• Les suppressions, les changements de politique, les lignes de base et l'acceptation de risque nécessitent un jugement explicite.
• Le rapport s'arrête après les preuves et ne contient aucune décision de poursuite.

Validation

Exécutez la compétence et les validateurs de red team :

bash skills/security/scripts/validate.sh
bash tests/scripts/test-security-suite-redteam.sh

Pour un test de fumée de suite limité, utilisez un binaire appartenant et un répertoire de sortie temporaire comme montré dans le manuel de la suite.

Exemples

• Une requête de sécurité rapide exécute la porte du dépôt une fois et signale la couverture et les résultats.
• Une requête de sécurité complète exécute l'analyse complète une fois et préserve ses artefacts.
• Une requête de binaire autorisé peut capturer une ligne de base dans un répertoire de sortie temporaire explicite.
• Une requête de red team peut exécuter le pack d'attaque hors ligne sur les surfaces appartenant au dépôt.

Dépannage

Problème	Réponse
Analyseur manquant/erreur	Enregistrer la lacune de couverture ; l'installer ou relancer avec --require-tools si nécessaire
Discordance local/CI	Comparer les versions d'analyseur, la configuration, le mode et les deux répertoires d'artefacts
Faux positif suspecté	Reproduire étroitement ; documenter toute suppression autorisée et son propriétaire
Échec de suite/ligne de base	Inspecter l'artefact de comparaison/politique nommé ; ne jamais rafraîchir la ligne de base par réflexe
Échec de red team après changement de formulation	Décider si le contrôle a régressé ou si le matcher du pack d'attaque nécessite une révision intentionnelle

Documents de Référence

• references/security-suite-runbook.md — commandes et artefacts pour binaire/politique/ligne de base/red team
• references/security.feature — spécification exécutable de la porte du dépôt
• references/security-suite.feature — spécification exécutable de la suite composable
• references/owasp-checklist.md — revue OWASP Top 10
• references/agentops-redteam-pack.json — pack d'attaque hors ligne
• references/policy-example.json — exemple de politique