sebinbenjamin/skill-warehouse

Divulgation du dépôt

Décider si le fournisseur d'IA cible peut recevoir des informations de ce projet. Il s'agit d'une décision de divulgation, pas d'un scan secret. La question est :

Si ce fournisseur peut conserver, réutiliser ou s'entraîner sur ce qu'il reçoit, quelles informations du projet pourraient échapper au contrôle du propriétaire, et est-ce acceptable ?

Signaler chaque constatation par type, emplacement, risque et action requise. Les secrets et les valeurs personnelles restent hors du rapport.

Cible de l'évaluation

Établir avant de décider :

• le fournisseur évalué, et si les données soumises peuvent être conservées, réutilisées ou utilisées pour l'entraînement
• l'utilisation prévue : accès statique au dépôt, exécution agentique/outils, ou les deux
• le périmètre : dépôt, arbre de travail, ou répertoire
• l'agent évaluateur : exécuter l'évaluation avec un fournisseur déjà approuvé pour le dépôt ; le fournisseur sous évaluation ne doit jamais être celui qui lit les fichiers

Les conditions varient selon les niveaux et les points de terminaison d'un même fournisseur (consommateur vs API vs entreprise, gratuit vs payant, paramètres de désinscription, accords de non-conservation des données) ; évaluer le niveau et le compte exacts utilisés, pas la politique générale du fournisseur. Les conditions inconnues sont évaluées comme rétention-et-entraînement, avec cette hypothèse spécifiée.

Terminé lorsque la cible, le mode d'accès, le périmètre et la séparation de l'agent évaluateur du fournisseur évalué sont chacun connus ou explicitement supposés.

Classes de données

Classer chaque constatation avec la classe la plus restrictive qui s'applique : RESTREINT > CONFIDENTIEL > PRIVE-PROPRIETE > PUBLIC.

• PUBLIC. Volontairement public : code source open source publié, documentation publique, exemples synthétiques, configuration d'espace réservé. Compatible avec un fournisseur admissible à l'entraînement en soi ; les fichiers locaux, les modifications non suivies, les identifiants et les outils connectés peuvent encore rendre le projet de travail dangereux.
• PRIVE-PROPRIETE. Non public, entièrement détenu par l'utilisateur, sans restriction d'employeur, client, collaborateur, de confidentialité, contractuelle ou de licence (un projet personnel non publié). Sûr une fois que le propriétaire a l'autorité de consentir et accepte les conditions du fournisseur.
• CONFIDENTIEL. Informations non publiques dont la divulgation violerait une attente d'emploi, de client, de NDA, contractuelle, de licence ou de sécurité : code source d'entreprise privée ou de client ; architecture interne, noms d'hôte, infrastructure ; plans de produit non publics, recherche, tarification, stratégie ; algorithmes propriétaires, logique métier, jeux de données ; constatations de sécurité, incidents, procédures opérationnelles ; tickets internes, notes de réunion, conversations de support ; matériel sous licence tiers non autorisé pour cette utilisation. Divulgable uniquement avec la preuve que ce fournisseur/cette utilisation est autorisée. Un fichier n'a pas besoin d'étiquette CONFIDENTIEL, ni d'identifiants à l'intérieur, pour être confidentiel.
• RESTREINT. L'exposition crée un risque direct de sécurité, de confidentialité, réglementaire ou d'accès au compte : mots de passe, clés API, jetons, cookies de session, clés privées, certificats de signature, magasins d'identifiants, chaînes de connexion et configuration de production ; identifiants cloud et de registre de paquets, état Terraform, configuration Kubernetes ; données personnelles réelles (client, candidat/étudiant, employé, support, authentification, paiement, enregistrements réglementés) où qu'elles se trouvent (dumps, exportations, fixtures, journaux, captures d'écran) ; secrets actifs présents uniquement dans l'historique Git. Une constatation restreinte confirmée est UTILISATION INTERDITE jusqu'à ce qu'elle soit hors de portée du fournisseur. Un identifiant possiblement exposé reçoit une recommandation de rotation ou de révocation ; la suppression seule le laisse actif.

Verdicts

Retourner exactement un verdict global : la première règle qui correspond. Une constatation sérieuse décide ; il n'y a pas de score.

1. Du matériel restreint est à portée → UTILISATION INTERDITE.
2. Du matériel confidentiel est à portée et ce fournisseur/cette utilisation est connue pour être interdite ou non autorisée → UTILISATION INTERDITE.
3. Du matériel non public est à portée et sa propriété, sa politique, son NDA, son client, sa licence ou son autorité de divulgation n'est pas résolu → NÉCESSITE APPROBATION POLITIQUE/PROPRIÉTAIRE (bloquant jusqu'à résolution).
4. Du matériel dangereux existe mais une frontière exécutoire le maintient hors de portée → SÛR AVEC EXCLUSIONS.
5. Tout ce qui est à portée est public, privé-propriété avec le consentement explicite du propriétaire aux conditions du fournisseur, ou confidentiel avec une autorisation prouvée pour ce fournisseur/cette utilisation → SÛR.

Les utilisations statique et agentique reçoivent des verdicts séparés ; le verdict global couvre l'utilisation demandée. Lorsque l'utilisation demandée n'est pas claire, rapporter les deux et prendre la plus restrictive.

Portée

La portée est tout ce que le fournisseur peut recevoir pendant le flux de travail prévu, pas seulement la source suivie :

• source suivie et documentation
• fichiers non suivis, ignorés, cachés, générés et de configuration locale du développeur, et cibles de liens symboliques
• définitions d'infrastructure, manifests de déploiement et migrations de base de données
• diffs, correctifs et historique Git
• fixtures, exportations, dumps, journaux, captures d'écran
• sortie de terminal, de test, de construction et de débogage
• variables d'environnement et configuration d'exécution
• tickets, issues, PRs et documentation interne
• tout ce qui se trouve derrière des outils connectés : systèmes authentifiés, outils cloud, bases de données, e-mail, calendriers, systèmes de support

Les caches de dépendances et les sorties de construction génériques sont hors de portée sauf s'ils contiennent des données spécifiques au projet ou réelles. Un fichier ignoré par Git est aussi accessible qu'un fichier suivi ; un arbre de travail propre ne prouve rien.

Processus

1. Établir la propriété et l'autorisation

Déterminer si le projet est public, personnel, détenu par un employeur, détenu par un client, éducatif, open source ou mixte ; qui possède la source, les données, la documentation et les artefacts générés ; si l'utilisateur a l'autorité de consentir aux conditions de ce fournisseur ; et si la politique de l'employeur, les conditions du client, les NDA, les contrats, les licences ou les règles de traitement des données restreignent la divulgation.

Terminé lorsque la propriété et l'autorité de divulgation sont chacune établies ou explicitement marquées comme non résolues.

2. Inventorier la portée

Parcourir le dépôt et lister chaque surface dans la section Portée ci-dessus pour le mode d'accès demandé.

Terminé lorsque chaque voie pratique par laquelle le fournisseur pourrait recevoir des informations du projet est listée.

3. Vérifier les données restreintes

Traquer l'inventaire pour du matériel RESTREINT. Distinguer les véritables secrets des espaces réservés, et les enregistrements réels des fixtures synthétiques.

Terminé lorsque chaque constatation suspectée restreinte est confirmée, faux positif ou non résolue. Le matériel restreint suspecté non résolu à portée compte comme confirmé.

4. Examiner la confidentialité sémantique

Lire la source et la documentation d'apparence ordinaire pour des informations CONFIDENTIELLES qu'un scan de motifs manque. En cas d'incertitude :

Le propriétaire s'opposerait-il raisonnablement si ce matériel exact était soumis à un fournisseur autorisé à conserver ou à s'entraîner dessus ?

Terminé lorsque chaque élément de l'inventaire a une classe de données et une décision de divulgation.

5. Examiner l'historique Git

Lorsque l'historique est à portée, vérifier les secrets supprimés, les valeurs de production retirées, les anciennes données client, les documents internes et les messages de commit sensibles.

Terminé lorsque le rapport indique si l'historique était dans le périmètre et s'il modifie le verdict.

6. Examiner l'exposition agentique

Évaluer l'exécution d'outils séparément de l'accès statique. Chaque surface de la section Portée est active ici, plus ce que l'exécution elle-même crée : tests ou commandes exécutés contre la préproduction ou la production, journalisation verbeuse qui imprime des données sensibles, et captures d'écran, exportations ou journaux générés pendant l'exécution. Un dépôt peut être sûr pour une revue statique et dangereux pour une exécution agentique.

Terminé lorsque les risques statique et agentique sont séparément indiqués, même lorsqu'ils partagent un verdict.

7. Tester les exclusions

SÛR AVEC EXCLUSIONS nécessite une frontière exécutoire : une qui supprime l'accès par construction. Par ordre de préférence :

1. une copie nettoyée du projet
2. un arbre de travail séparé contenant uniquement du matériel approuvé
3. un conteneur ou un bac à sable sans fichiers restreints, identifiants ou accès aux systèmes en direct
4. des autorisations d'outils qui bloquent chaque voie pratique vers les données exclues

Les règles de lecture basées sur les chemins sont faibles là où un shell non restreint, des outils connectés, des liens symboliques, des variables d'environnement ou des systèmes d'exécution atteignent les mêmes données ; la discipline manuelle n'est pas une frontière du tout.

Terminé lorsque chaque exclusion nomme sa frontière et qu'aucune autre voie autour d'elle n'est apparente.

8. Décider

Appliquer les règles de verdict aux preuves, en vérifiant les deux dimensions : fuite technique (secrets, données personnelles, jeux de données réels, journaux, historique, sortie d'outils) et gouvernance (propriété, obligations client/employeur, licences, autorité de divulgation, conditions du fournisseur). Une dimension non résolue donne le verdict bloquant pour ce problème avec une confiance réduite, jamais SÛR.

Terminé lorsque les verdicts global, statique et agentique sont cohérents avec les constatations et l'utilisation demandée.

Format du rapport

# Évaluation de la sécurité des données du dépôt IA

**Verdict global :** SÛR | SÛR AVEC EXCLUSIONS | UTILISATION INTERDITE | NÉCESSITE APPROBATION POLITIQUE/PROPRIÉTAIRE
**Dépôt statique :** <verdict>
**Exécution agentique/outils :** <verdict>
**Évalué pour :** <fournisseur, ou l'hypothèse conservatrice d'admissibilité à l'entraînement>
**Périmètre évalué :** <dépôt/arbre de travail/répertoire et mode d'accès>
**Confiance :** Haute | Moyenne | Faible

## Pourquoi
<les raisons décisives, un court paragraphe>

## Constatations bloquantes
<par bloqueur : gravité, classe de données, emplacement, type d'information, pourquoi c'est important, action requise, ou `Aucune trouvée`>

## Constatations de confidentialité
<par zone : classe de données, chemin ou zone du projet, pourquoi cela peut être sensible, si le fournisseur/utilisation évalué peut le recevoir>

## Inconnues
<questions non résolues de propriété, politique, licence, conditions du fournisseur ou de périmètre qui affectent le verdict, ou `Aucune`>

## Périmètre sûr
<parties du projet utilisables avec le fournisseur évalué, ou `Périmètre évalué entier`>

## Périmètre exclu
<chaque élément qui doit rester hors de portée, avec la frontière qui l'applique, ou `Aucun`>

## Recommandation
<une recommandation opérationnelle directe>

Exemples de recommandation :

• Ne pas utiliser un modèle admissible à l'entraînement pour ce dépôt.
• Utiliser le modèle admissible à l'entraînement uniquement avec une copie nettoyée contenant la source publique approuvée.
• Le dépôt est techniquement propre ; l'approbation du propriétaire/employeur pour l'entraînement du fournisseur est requise avant de procéder.
• La revue de source statique est acceptable ; utiliser un modèle privé approuvé pour les tests et les outils pouvant accéder aux systèmes en direct.