Publier et distribuer ses plugins Copilot Security : GitHub, équipe et marketplace

Écriture dans `/tmp` refusée (session non interactive, permission non accordée). Je livre donc l'article directement ci-dessous — copiez-le tel quel. **Métadonnées SEO suggérées** - **Titre** (58) : `Publier et distribuer ses plugins Copilot Security en 2026` - **Slug** (43) : `publier-distribuer-plugins-copilot-security` - **Meta description** (157) : `Distribuer un plugin Copilot Security : scopes personnel, équipe et tenant, dépôt GitHub, hébergement GitHub Pages ou Azure Blob SAS, versioning et validation CI.` Le manifeste YAML suit le schéma réel vérifié sur Microsoft Learn (`Descriptor` / `SkillGroups`, `Format: API|GPT|KQL|AGENT|LogicApp`, `SupportedAuthTypes`, `Settings.OpenApiSpecUrl`, `Target: Sentinel`). Je n'annonce **aucun délai chiffré** pour la revue Marketplace — les SLA publics évoluent et je n'ai pas pu les vérifier (WebSearch refusé) ; le processus est décrit structurellement. --- ```html

Écrire un plugin Copilot Security qui fonctionne sur votre poste est la partie facile. Le vrai travail commence au moment où il faut le sortir de votre dossier ~/dev pour le mettre entre les mains d'une équipe SOC, puis éventuellement d'une communauté entière. Entre le manifeste chargé à la main dans le portail, le dépôt GitHub partagé avec trois collègues, l'URL publique consommée par tout un tenant et la soumission au Microsoft Security Marketplace, les contraintes techniques, juridiques et opérationnelles ne sont pas les mêmes. Un plugin distribué est un artefact de production : il a un cycle de vie, des versions, des ruptures de compatibilité, des consommateurs qui vont l'activer sans lire votre code, et une surface d'attaque qui devient celle de vos utilisateurs. Cet article détaille les trois modes de distribution, la structure de dépôt qui tient dans le temps, l'hébergement du manifeste sur GitHub Pages ou Azure Blob Storage, la validation automatisée avant publication, la contribution aux dépôts communautaires, le passage par le Marketplace, et enfin l'évaluation de sécurité et le monitoring qui font la différence entre un projet perso et un composant de chaîne d'outillage défensive.

Les trois modes de distribution d'un plugin Copilot Security

Avant de parler de dépôt Git ou de pipeline CI, il faut choisir le périmètre de diffusion. Security Copilot matérialise ce choix dès l'upload : lorsque vous ajoutez un plugin personnalisé depuis Manage sources > Custom > Upload plugin, un menu déroulant vous demande explicitement si le plugin doit être disponible uniquement pour vous ou pour tout le monde dans l'organisation. Ce n'est pas un détail cosmétique : ce sont deux scopes distincts (user scope et tenant scope), soumis à deux permissions différentes configurées par le propriétaire du workspace.

Mode 1 — Distribution personnelle (user scope)

C'est le mode par défaut et le seul disponible tant qu'un Owner n'a rien configuré. Le plugin reçoit un tag private, n'apparaît que dans votre liste de sources, et personne d'autre ne peut l'activer. C'est le mode de développement : vous itérez sur le manifeste, vous corrigez les DescriptionForModel qui provoquent des collisions de skills, vous testez l'authentification. Le manifeste peut vivre en local, être uploadé en tant que fichier, modifié directement dans le portail via Edit file, puis re-sauvegardé.

La limite est évidente : rien n'est reproductible. Si vous éditez le YAML dans l'interface, votre copie locale diverge silencieusement. C'est acceptable pendant quelques jours d'exploration, jamais au-delà. Dès que le plugin devient utile à quelqu'un d'autre, il doit sortir du portail et rentrer dans Git.

Mode 2 — Distribution en équipe (tenant scope)

Ici, le plugin est publié pour l'ensemble des utilisateurs Security Copilot du tenant. Deux permissions distinctes, configurables par un Owner dans Owner > Plugin settings, encadrent cela :

• Qui peut ajouter et gérer ses propres plugins personnalisés ? — Owners only, ou Owners and Contributors.
• Qui peut ajouter et gérer des plugins personnalisés pour tout le monde dans l'organisation ? — Owners only, ou Owners and Contributors.

La seconde option n'est activable que si la première autorise les Contributors. Point important pour la gouvernance : un plugin ajouté par un Owner et publié à l'échelle de l'organisation peut être activé, désactivé et utilisé par tous, mais seuls les Owners peuvent le modifier. Un Contributor ne peut pas éditer un plugin créé par un Owner. Cette asymétrie est votre garde-fou : elle empêche qu'un plugin validé soit altéré par un utilisateur intermédiaire.

C'est dans ce mode que le versioning devient non négociable. Vos analystes vont construire des promptbooks et des agents qui dépendent des noms de skills. Renommer une skill, c'est casser leurs workflows sans préavis.

Mode 3 — Distribution communautaire

Le troisième mode consiste à publier le manifeste hors de votre tenant : dépôt GitHub public, contribution à un dépôt communautaire de référence, ou soumission au Microsoft Security Marketplace. Vous ne contrôlez plus qui l'installe, ni dans quel contexte, ni avec quelles données. Les exigences changent de nature : documentation exhaustive, licence explicite, absence totale de secrets en dur, gestion responsable des ruptures de compatibilité, et une réflexion sérieuse sur ce que votre plugin envoie à des endpoints tiers.

Ces trois modes ne sont pas exclusifs — ils sont séquentiels. Le parcours sain est : personnel pendant le développement, équipe après une revue interne, communautaire une fois le plugin stabilisé sur plusieurs versions. Pour les fondamentaux de conception du manifeste lui-même, référez-vous à notre guide dédié aux plugins Copilot Security.

Structurer le dépôt GitHub qui hébergera vos plugins

Un dépôt de plugins Copilot Security n'est pas un dépôt applicatif classique : il contient essentiellement des manifestes déclaratifs, des spécifications OpenAPI, des requêtes KQL et de la documentation. La structure suivante a l'avantage de rester lisible quand vous passez de un à quinze plugins.

security-copilot-plugins/
├── .github/
│   └── workflows/
│       └── validate.yml          # CI de validation des manifestes
├── plugins/
│   ├── contoso-ti-lookup/
│   │   ├── manifest.yaml         # le manifeste Security Copilot
│   │   ├── openapi.yaml          # spec OpenAPI 3.0.x (plugins API)
│   │   ├── README.md             # doc spécifique au plugin
│   │   └── CHANGELOG.md
│   └── contoso-sentinel-hunt/
│       ├── manifest.yaml
│       ├── queries/
│       │   └── suspicious-signins.kql
│       └── README.md
├── scripts/
│   ├── validate_manifest.py      # validation locale + CI
│   └── deploy.sh                 # publication vers l'hébergement
├── docs/
│   └── index.md
├── CONTRIBUTING.md
├── SECURITY.md
├── LICENSE                       # MIT
└── README.md

Trois principes structurent ce découpage. Premièrement, un dossier par plugin : le manifeste, sa spec OpenAPI et sa documentation vivent ensemble, ce qui permet de tagger et de versionner indépendamment. Deuxièmement, les requêtes KQL sont extraites du YAML dès qu'elles dépassent quelques lignes — le champ TemplateUrl accepte une URL publique vers le template, et PackageUrl accepte une archive ZIP avec un TemplateFile relatif. Troisièmement, les scripts sont partagés : un seul validateur pour tous les plugins, appelé aussi bien en local qu'en CI.

Le fichier LICENSE : pourquoi MIT

La licence MIT est le choix par défaut raisonnable pour un manifeste de plugin, et ce n'est pas un réflexe paresseux. Un manifeste Copilot Security est un artefact déclaratif court, souvent copié-collé et adapté par ses utilisateurs. Une licence copyleft (GPL) créerait une ambiguïté inutile : est-ce que le YAML dérivé qu'un client colle dans son tenant devient une œuvre dérivée soumise à obligation de publication ? Le débat n'a aucun intérêt pratique ici. MIT lève l'ambiguïté, autorise l'usage commercial, et surtout contient la clause de non-garantie qui vous protège si un plugin de threat intelligence renvoie un faux négatif dans un contexte d'incident.

Un détail souvent négligé : si votre plugin embarque des requêtes KQL adaptées depuis un dépôt communautaire, vérifiez la licence d'origine et créditez-la dans le README. Les dépôts de contenu Microsoft Sentinel ne sont pas tous sous MIT.

Rédiger un README qui donne envie d'installer votre plugin

Le README est le seul document que 90 % des utilisateurs liront. Il doit répondre à quatre questions dans les trente premières secondes : qu'est-ce que ça fait, de quoi ça a besoin, comment je l'installe, et qu'est-ce que ça envoie où. Voici un modèle éprouvé.

# Contoso Threat Intel Lookup — Plugin Security Copilot

[![Validate](https://github.com/contoso/security-copilot-plugins/actions/workflows/validate.yml/badge.svg)](https://github.com/contoso/security-copilot-plugins/actions)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](../../LICENSE)

Enrichit un indicateur de compromission (IP, domaine, hash SHA-256) avec les
données de réputation de la plateforme Contoso TI, directement depuis une
session Security Copilot ou depuis un agent.

## Skills exposées

| Skill | Entrées | Description |
|---|---|---|
| `GetIndicatorReputation` | `Indicator` (requis) | Score de réputation 0-100, verdict, sources |
| `GetIndicatorRelations`  | `Indicator` (requis), `Depth` (optionnel) | Infrastructure liée : DNS passif, certificats |

## Prérequis

- Rôle **Owner** ou **Contributor** avec droit de publication de plugins
- Une clé API Contoso TI (plan *Analyst* minimum)
- Sortie HTTPS autorisée vers `api.contoso-ti.example`

## Installation

1. Security Copilot → icône **Sources** → section **Custom** → **Upload plugin**
2. Choisir la portée : *Just me* (test) ou *Anyone in my org* (production)
3. Activer **Upload as a link** et coller :
   `https://contoso.github.io/security-copilot-plugins/contoso-ti-lookup/v2/manifest.yaml`
4. Type de fichier : **YAML**, puis **Add**
5. Renseigner la clé API dans l'écran de **Setup**

## Données transmises

| Donnée | Destination | Rétention |
|---|---|---|
| Indicateur (IP/domaine/hash) | `api.contoso-ti.example` | 30 jours (logs) |
| Identité de l'appelant | *non transmise* | — |

Aucun contenu d'alerte, aucun nom d'utilisateur et aucune donnée de tenant
ne sont envoyés à l'API.

## Versions

Voir [CHANGELOG.md](CHANGELOG.md). Version courante : `v2.1.0`.
Les versions majeures introduisent des ruptures de compatibilité — lisez la
section *Migration* avant de mettre à jour un plugin publié à l'échelle du tenant.

## Support

Ouvrez une issue avec le label `plugin:contoso-ti-lookup`.
Vulnérabilité de sécurité : voir [SECURITY.md](../../SECURITY.md), pas d'issue publique.

## Licence

MIT — voir [LICENSE](../../LICENSE).

La section Données transmises est celle qui distingue un README amateur d'un README professionnel. Un RSSI qui évalue votre plugin veut savoir exactement ce qui sort du tenant. L'afficher spontanément vous fera gagner des semaines dans les cycles de validation.

Un manifeste versionné, prêt pour la distribution

Voici un manifeste API complet, structuré pour la distribution : nom qualifié, version explicite, endpoint configurable, authentification par clé API. Il suit les deux clés de premier niveau obligatoires, Descriptor et SkillGroups.

# plugins/contoso-ti-lookup/manifest.yaml
# Version: 2.1.0  |  Licence: MIT  |  Schéma: Security Copilot plugin manifest

Descriptor:
  # Nom interne, unique dans le workspace.
  # Interdit : / , \ ? # @ et les espaces. Convention : Editeur.Produit.Plugin
  Name: Contoso.ThreatIntel.IndicatorLookup
  DisplayName: Contoso TI — Indicator Lookup   # 40 caractères max
  Description: >-
    Enrichit un indicateur de compromission (adresse IP, nom de domaine ou
    hash SHA-256) avec les donnees de reputation Contoso Threat Intelligence.
    Permet a un analyste de determiner rapidement si un indicateur observe
    dans un incident est connu comme malveillant, et de pivoter vers
    l'infrastructure associee.
  SupportedAuthTypes:
    - ApiKey
  Authorization:
    Type: ApiKey
    Key: X-Contoso-ApiKey     # nom de l'en-tête HTTP
    Location: Header
    AuthScheme: ''            # pas de préfixe Bearer pour cette API

SkillGroups:
  - Format: API
    Settings:
      # URL publique et stable de la spec OpenAPI 3.0.x — versionnée !
      OpenApiSpecUrl: https://contoso.github.io/security-copilot-plugins/contoso-ti-lookup/v2/openapi.yaml
      # Endpoint configurable au setup : indispensable pour les clients
      # disposant d'une instance régionale ou souveraine.
      EndpointUrlSettingName: ContosoApiEndpoint
    Skills:
      - Name: GetIndicatorReputation
        DisplayName: Get indicator reputation
        Description: Renvoie le score de réputation d'un indicateur de compromission.
        # DescriptionForModel : uniquement pour la sélection de skill par le LLM.
        # Verbeux et explicite, pour éviter les collisions de skills.
        DescriptionForModel: >-
          Recupere les informations de reputation pour un indicateur de
          compromission : adresse IPv4 ou IPv6, nom de domaine pleinement
          qualifie, URL, ou hash de fichier SHA-256. Renvoie un score de 0 a
          100, un verdict (benign, suspicious, malicious, unknown), la liste
          des sources ayant contribue au verdict, la date de premiere et de
          derniere observation, et les familles de malware associees.
          Utiliser cette skill lorsqu'un analyste demande si un indicateur est
          malveillant, risque, connu, ou deja observe.
        Inputs:
          - Name: Indicator
            Description: L'indicateur à analyser (IP, domaine, URL ou hash SHA-256).
            Required: true
          - Name: IncludeSources
            Description: Inclure le détail des sources dans la réponse.
            Required: false
            DefaultValue: 'false'

      - Name: GetIndicatorRelations
        DisplayName: Get related infrastructure
        Description: Renvoie l'infrastructure liée à un indicateur.
        DescriptionForModel: >-
          Recupere l'infrastructure liee a un indicateur : resolutions DNS
          passives, certificats TLS partages, domaines co-heberges et
          indicateurs observes dans les memes campagnes. Utiliser cette skill
          pour pivoter depuis un indicateur unique vers l'infrastructure d'un
          attaquant lors d'une investigation.
        Inputs:
          - Name: Indicator
            Description: L'indicateur de départ du pivot.
            Required: true
          - Name: Depth
            Description: Profondeur de pivot, de 1 à 3. Défaut 1.
            Required: false
            DefaultValue: '1'

  # Second groupe : une skill KQL, sur le workspace Sentinel du client.
  - Format: KQL
    Skills:
      - Name: FindIndicatorInSentinel
        DisplayName: Find indicator in Sentinel
        Description: Recherche l'indicateur dans les logs Sentinel des 7 derniers jours.
        Inputs:
          - Name: Indicator
            Description: L'indicateur à rechercher.
            Required: true
        Settings:
          Target: Sentinel
          TenantId: '{{TenantId}}'
          SubscriptionId: '{{SubscriptionId}}'
          ResourceGroupName: '{{ResourceGroupName}}'
          WorkspaceName: '{{WorkspaceName}}'
          # Template externalisé : évite un YAML de 400 lignes.
          TemplateUrl: https://contoso.github.io/security-copilot-plugins/contoso-ti-lookup/v2/find-indicator.kql

Héberger le manifeste sur une URL publique

Security Copilot accepte deux modes d'ajout d'un plugin personnalisé : l'upload de fichier, et l'upload « as a link » via un bouton dédié, qui attend une URL vers un fichier .yaml ou .json. Le second mode est le seul qui permette une distribution industrialisée : vous poussez sur Git, la CI publie, et les nouveaux ajouts de plugin pointent vers la version à jour.

GitHub Pages : le chemin le plus court

GitHub Pages sert n'importe quel fichier du dépôt en HTTPS, gratuitement, avec un certificat valide. Activez Pages sur la branche gh-pages ou sur le dossier /docs de main, et vos manifestes deviennent accessibles à une URL stable. Deux précautions :

• Pas de branche main servie directement. Publier depuis une branche dédiée alimentée par la CI évite qu'un commit en cours de revue devienne immédiatement la version consommée par un tenant en production.
• Chemins versionnés. /contoso-ti-lookup/v2/manifest.yaml plutôt que /contoso-ti-lookup/manifest.yaml. Un plugin installé pointe vers une URL figée ; si vous écrasez le contenu de cette URL avec une version incompatible, vous cassez les installations existantes sans aucun signal.

Azure Blob Storage avec SAS : quand le manifeste ne doit pas être public

Pour un plugin interne, exposer le manifeste sur GitHub Pages revient à publier votre cartographie d'outillage défensif : noms de workspaces Sentinel, endpoints internes, structure de vos requêtes de détection. Azure Blob Storage avec un Shared Access Signature résout le problème : l'URL reste accessible en HTTPS sans authentification interactive — condition nécessaire pour que Security Copilot puisse la télécharger — mais elle est non devinable, limitée dans le temps, restreinte en lecture seule, et révocable.

Le script de déploiement ci-dessous automatise la publication vers un conteneur privé et génère un SAS en lecture seule avec expiration. Il refuse de tourner si le manifeste n'a pas passé la validation.

#!/usr/bin/env bash
# scripts/deploy.sh — publie un manifeste validé vers Azure Blob + SAS lecture seule
# Usage : ./deploy.sh contoso-ti-lookup 2.1.0
set -Eeuo pipefail

PLUGIN="${1:?Usage: deploy.sh  }"
VERSION="${2:?Usage: deploy.sh  }"

STORAGE_ACCOUNT="${STORAGE_ACCOUNT:-stcopilotplugins}"
CONTAINER="${CONTAINER:-manifests}"
SAS_DAYS="${SAS_DAYS:-90}"
SRC_DIR="plugins/${PLUGIN}"
MAJOR="v${VERSION%%.*}"                       # 2.1.0 -> v2

command -v az >/dev/null || { echo "azure-cli requis" >&2; exit 1; }
[[ -d "$SRC_DIR" ]] || { echo "Plugin introuvable : $SRC_DIR" >&2; exit 1; }

echo "==> Validation du manifeste"
python3 scripts/validate_manifest.py "${SRC_DIR}/manifest.yaml" --strict

echo "==> Garde-fou : recherche de secrets en clair"
if grep -nEi '(ClientSecret|Password|AccessToken|ApiKey)[[:space:]]*:[[:space:]]*[^{[:space:]]' \
      "${SRC_DIR}/manifest.yaml"; then
  echo "ERREUR : valeur de secret en dur détectée. Publication annulée." >&2
  exit 2
fi

echo "==> Upload vers ${CONTAINER}/${PLUGIN}/${MAJOR}/"
az storage blob upload-batch \
  --account-name "$STORAGE_ACCOUNT" \
  --destination "$CONTAINER" \
  --destination-path "${PLUGIN}/${MAJOR}" \
  --source "$SRC_DIR" \
  --pattern "*.yaml" \
  --overwrite true \
  --auth-mode login \
  --content-type "application/x-yaml" \
  --output none

# Expiration du SAS. `date -u -d` (GNU) ; sur macOS : date -u -v+90d
EXPIRY="$(date -u -d "+${SAS_DAYS} days" '+%Y-%m-%dT%H:%MZ')"

SAS="$(az storage blob generate-sas \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$CONTAINER" \
  --name "${PLUGIN}/${MAJOR}/manifest.yaml" \
  --permissions r \
  --expiry "$EXPIRY" \
  --https-only \
  --as-user --auth-mode login \
  --full-uri --output tsv)"

echo
echo "Manifeste publié. URL à coller dans « Upload as a link » :"
echo "  $SAS"
echo "Expire le ${EXPIRY}. Planifiez la rotation avant cette date."

Trois points méritent attention. Le flag --as-user --auth-mode login génère un user delegation SAS, signé par une identité Entra ID plutôt que par la clé de compte de stockage : il est révocable individuellement et sa compromission n'expose pas l'ensemble du compte. L'expiration est un compromis à assumer — un SAS de 90 jours impose une rotation trimestrielle, et donc une réinstallation du plugin côté consommateurs ; documentez-le, sinon le plugin cessera de fonctionner un matin sans explication. Enfin le grep de garde-fou est volontairement grossier : il produit des faux positifs, ce qui est exactement le comportement souhaité pour un contrôle de dernière ligne.

Versioning, convention de nommage et ruptures de compatibilité

Le manifeste Copilot Security n'a pas de champ Version normalisé. Cette absence est la source de la majorité des incidents de distribution : sans discipline explicite, personne ne sait quelle version tourne dans quel tenant.

Convention de nommage

Le champ Descriptor.Name doit être unique dans le workspace, sans espace, et sans les caractères / , \ ? # @. La convention Editeur.Produit.Plugin (par exemple Contoso.ThreatIntel.IndicatorLookup) offre trois avantages : elle évite les collisions avec les plugins Microsoft et partenaires, elle permet de filtrer visuellement les plugins par éditeur dans la liste des sources, et elle correspond au format attendu dans RequiredSkillsets quand un agent dépend de votre skillset.

Les noms de skills, eux, ne peuvent contenir ni espace ni point. Utilisez du PascalCase verbal : GetIndicatorReputation, ListRecentAlerts, ResolveHostname. Le verbe compte : il aide le modèle à sélectionner la bonne skill, et il vous force à concevoir des skills qui font une seule chose.

SemVer appliqué à un manifeste

Adoptez le versionnement sémantique, matérialisé dans les tags Git, dans le chemin d'hébergement et dans le CHANGELOG :

• PATCH (2.1.0 → 2.1.1) : correction d'une Description, ajustement d'un DescriptionForModel, correction d'une requête KQL sans changement de colonnes de sortie. Aucun impact consommateur.
• MINOR (2.1.0 → 2.2.0) : ajout d'une skill, ajout d'un input optionnel avec DefaultValue, ajout d'un champ dans la réponse. Rétrocompatible.
• MAJOR (2.1.0 → 3.0.0) : suppression ou renommage d'une skill, passage d'un input en Required: true, changement du type d'authentification, changement de sémantique d'une valeur de retour.

Ce qui casse réellement les consommateurs

Quatre changements sont des ruptures dures, à ne jamais introduire hors version majeure :

1. Renommer une skill. Tout promptbook, tout agent référençant cette skill via ChildSkills ou ProcessSkill cesse de fonctionner.
2. Rendre un input obligatoire. Les invocations existantes qui l'omettaient échouent.
3. Changer Descriptor.Name. Security Copilot considère alors qu'il s'agit d'un skillset entièrement différent : les deux coexistent, les skills entrent en collision, et le modèle choisit au hasard.
4. Modifier le type d'authentification. Le setup côté utilisateur devient invalide et le plugin tombe en erreur silencieuse.

La stratégie de dépréciation qui fonctionne : publier la version majeure sur un nouveau chemin (/v3/manifest.yaml) sans jamais toucher /v2/, conserver l'ancienne version pendant au moins un cycle trimestriel, et documenter la migration dans le CHANGELOG. Pour une skill renommée, la voie propre consiste à conserver l'ancien nom pendant une version mineure en marquant sa Description d'un [DEPRECATED — utiliser X], puis à la retirer à la majeure suivante.

Valider le manifeste avant publication : script Python

Security Copilot ne vous dira pas grand-chose quand un manifeste est invalide : l'upload échoue, ou pire, il réussit et la skill n'est jamais sélectionnée par le modèle parce que sa description est vide. Un validateur local vous fait gagner un temps considérable. Celui-ci vérifie la structure, les contraintes documentées de longueur et de caractères, et applique quelques règles de qualité issues des recommandations d'authoring de Microsoft.

#!/usr/bin/env python3
"""
scripts/validate_manifest.py
Validation d'un manifeste de plugin Security Copilot avant publication.

Usage:
    python3 validate_manifest.py plugins/*/manifest.yaml
    python3 validate_manifest.py plugins/foo/manifest.yaml --strict

Sortie: code 0 si conforme, 1 si erreur, 2 si --strict et warnings.
Dépendance: PyYAML  (pip install pyyaml)
"""
from __future__ import annotations

import argparse
import re
import sys
from dataclasses import dataclass, field
from pathlib import Path

import yaml

VALID_FORMATS = {"API", "GPT", "KQL", "AGENT", "LogicApp"}
VALID_AUTH_TYPES = {
    "None", "Basic", "ApiKey", "ServiceHttp",
    "OAuthAuthorizationCodeFlow", "OAuthClientCredentialsFlow",
    "OAuthPasswordGrantFlow", "AAD", "AADDelegated",
}
# Descriptor.Name : pas d'espace, pas de / , \ ? # @
DESCRIPTOR_NAME_FORBIDDEN = re.compile(r"[/\\,?#@\s]")
# Skill.Name : pas d'espace, pas de point
SKILL_NAME_FORBIDDEN = re.compile(r"[.\s]")
# Détection grossière de secrets committés
SECRET_KEYS = {"Value", "Password", "ClientSecret", "AccessToken", "Key"}
PLACEHOLDER = re.compile(r"^\s*\{\{.+\}\}\s*$")

MAX_NAME = 100
MAX_DISPLAY_NAME = 40
MAX_DESCRIPTION_DISPLAY = 200
MIN_MODEL_DESC_WORDS = 15  # règle qualité maison


@dataclass
class Report:
    path: Path
    errors: list[str] = field(default_factory=list)
    warnings: list[str] = field(default_factory=list)

    def error(self, msg: str) -> None:
        self.errors.append(msg)

    def warn(self, msg: str) -> None:
        self.warnings.append(msg)

    @property
    def ok(self) -> bool:
        return not self.errors


def _check_descriptor(desc: dict, rpt: Report) -> None:
    if not isinstance(desc, dict):
        rpt.error("Descriptor doit être un mapping.")
        return

    name = desc.get("Name")
    if not name:
        rpt.error("Descriptor.Name est obligatoire.")
    else:
        if DESCRIPTOR_NAME_FORBIDDEN.search(name):
            rpt.error(
                f"Descriptor.Name '{name}' contient un caractère interdit "
                "(espace ou / \\ , ? # @)."
            )
        if len(name) > MAX_NAME:
            rpt.error(f"Descriptor.Name dépasse {MAX_NAME} caractères ({len(name)}).")
        if name.count(".") < 2:
            rpt.warn(
                f"Descriptor.Name '{name}' ne suit pas la convention "
                "Editeur.Produit.Plugin — risque de collision inter-éditeurs."
            )

    if not (desc.get("Description") or "").strip():
        rpt.error("Descriptor.Description est obligatoire et non vide.")

    display = desc.get("DisplayName")
    if not display:
        rpt.warn("Descriptor.DisplayName absent — recommandé pour l'affichage UX.")
    elif len(display) > MAX_DISPLAY_NAME:
        rpt.error(
            f"Descriptor.DisplayName dépasse {MAX_DISPLAY_NAME} caractères "
            f"({len(display)})."
        )

    dd = desc.get("DescriptionDisplay")
    if dd and len(dd) > MAX_DESCRIPTION_DISPLAY:
        rpt.error(
            f"Descriptor.DescriptionDisplay dépasse {MAX_DESCRIPTION_DISPLAY} "
            f"caractères ({len(dd)})."
        )

    for auth in desc.get("SupportedAuthTypes") or []:
        if auth not in VALID_AUTH_TYPES:
            rpt.error(
                f"SupportedAuthTypes '{auth}' inconnu. "
                f"Valeurs acceptées : {', '.join(sorted(VALID_AUTH_TYPES))}."
            )


def _scan_secrets(node, rpt: Report, path: str = "") -> None:
    """Remonte toute valeur de secret qui n'est pas un placeholder {{...}}."""
    if isinstance(node, dict):
        for key, value in node.items():
            here = f"{path}.{key}" if path else key
            if (
                key in SECRET_KEYS
                and isinstance(value, str)
                and value.strip()
                and not PLACEHOLDER.match(value)
            ):
                rpt.error(
                    f"{here} contient une valeur en clair — utilisez un setting "
                    "renseigné au moment du setup, jamais un secret committé."
                )
            _scan_secrets(value, rpt, here)
    elif isinstance(node, list):
        for index, item in enumerate(node):
            _scan_secrets(item, rpt, f"{path}[{index}]")


def _check_skill(skill: dict, fmt: str, seen: set[str], rpt: Report) -> None:
    name = skill.get("Name")
    if not name:
        rpt.error(f"[{fmt}] Une skill n'a pas de champ Name.")
        return
    if SKILL_NAME_FORBIDDEN.search(name):
        rpt.error(f"[{fmt}] Skill.Name '{name}' contient un espace ou un point.")
    if name in seen:
        rpt.error(f"Skill '{name}' déclarée plusieurs fois — collision garantie.")
    seen.add(name)

    if not (skill.get("Description") or "").strip():
        rpt.warn(f"Skill '{name}' sans Description — affichage UX dégradé.")

    model_desc = skill.get("DescriptionForModel") or skill.get("Description") or ""
    if len(model_desc.split()) < MIN_MODEL_DESC_WORDS:
        rpt.warn(
            f"Skill '{name}' : description trop courte pour la sélection par le "
            f"modèle ({len(model_desc.split())} mots). Décrivez ce que fait la "
            "skill ET pourquoi l'utiliser."
        )

    settings = skill.get("Settings") or {}
    if fmt in {"GPT", "KQL", "AGENT"} and not settings:
        rpt.error(f"[{fmt}] Skill '{name}' : Settings obligatoire pour ce format.")

    if fmt == "GPT":
        if settings.get("ModelName") != "gpt-4.1":
            rpt.error(f"[GPT] Skill '{name}' : ModelName doit valoir 'gpt-4.1'.")
        if not settings.get("Template"):
            rpt.error(f"[GPT] Skill '{name}' : Template obligatoire.")

    if fmt == "KQL":
        if not settings.get("Target"):
            rpt.error(f"[KQL] Skill '{name}' : Target obligatoire.")
        sources = [k for k in ("Template", "TemplateUrl", "TemplateFile")
                   if settings.get(k)]
        if len(sources) > 1:
            rpt.error(
                f"[KQL] Skill '{name}' : {' et '.join(sources)} sont mutuellement "
                "exclusifs."
            )
        if not sources:
            rpt.error(
                f"[KQL] Skill '{name}' : fournir Template, TemplateUrl ou "
                "TemplateFile (avec PackageUrl au niveau du SkillGroup)."
            )

    if fmt == "AGENT" and not skill.get("ChildSkills"):
        rpt.error(f"[AGENT] Skill '{name}' : ChildSkills obligatoire.")

    for item in skill.get("Inputs") or []:
        if not item.get("Name"):
            rpt.error(f"Skill '{name}' : un Input sans Name.")
        if not (item.get("Description") or "").strip():
            rpt.warn(
                f"Skill '{name}' : input '{item.get('Name')}' sans Description — "
                "le modèle ne saura pas quoi y mettre."
            )


def validate(path: Path) -> Report:
    rpt = Report(path=path)
    try:
        data = yaml.safe_load(path.read_text(encoding="utf-8"))
    except yaml.YAMLError as exc:
        rpt.error(f"YAML invalide : {exc}")
        return rpt
    except OSError as exc:
        rpt.error(f"Lecture impossible : {exc}")
        return rpt

    if not isinstance(data, dict):
        rpt.error("Le manifeste doit être un mapping YAML à la racine.")
        return rpt

    for required in ("Descriptor", "SkillGroups"):
        if required not in data:
            rpt.error(f"Clé de premier niveau manquante : {required}.")

    if "Descriptor" in data:
        _check_descriptor(data["Descriptor"], rpt)

    groups = data.get("SkillGroups") or []
    if not isinstance(groups, list) or not groups:
        rpt.error("SkillGroups doit être une liste non vide.")
        return rpt

    seen_skills: set[str] = set()
    uses_api = False
    for i, group in enumerate(groups):
        fmt = (group or {}).get("Format")
        if fmt not in VALID_FORMATS:
            rpt.error(
                f"SkillGroups[{i}].Format = '{fmt}' invalide. "
                f"Attendu : {', '.join(sorted(VALID_FORMATS))}."
            )
            continue
        if fmt == "API":
            uses_api = True
            if not (group.get("Settings") or {}).get("OpenApiSpecUrl"):
                rpt.error(f"SkillGroups[{i}] (API) : OpenApiSpecUrl obligatoire.")
        for skill in group.get("Skills") or []:
            _check_skill(skill, fmt, seen_skills, rpt)

    if uses_api and not (data.get("Descriptor", {}).get("SupportedAuthTypes")):
        rpt.error("SupportedAuthTypes est requis dès qu'un SkillGroup est de format API.")

    _scan_secrets(data, rpt)
    return rpt


def main() -> int:
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("manifests", nargs="+", type=Path)
    parser.add_argument(
        "--strict", action="store_true",
        help="Traiter les warnings comme bloquants (mode CI de publication).",
    )
    args = parser.parse_args()

    reports = [validate(p) for p in args.manifests]
    for rpt in reports:
        status = "OK" if rpt.ok else "ECHEC"
        print(f" === {rpt.path} : {status} ===")
        for msg in rpt.errors:
            print(f"  [ERREUR]  {msg}")
        for msg in rpt.warnings:
            print(f"  [WARNING] {msg}")
        if rpt.ok and not rpt.warnings:
            print("  Aucun problème détecté.")

    if any(not r.ok for r in reports):
        return 1
    if args.strict and any(r.warnings for r in reports):
        print(" --strict : des warnings subsistent, publication bloquée.")
        return 2
    return 0


if __name__ == "__main__":
    sys.exit(main())

Ce validateur n'est volontairement pas un validateur de schéma JSON Schema générique : il encode des règles métier que le schéma ne capture pas, comme la longueur minimale d'une DescriptionForModel ou l'exclusivité entre Template et TemplateUrl. C'est précisément ce qui le rend utile. Branchez-le en hook pre-commit et l'immense majorité des allers-retours avec le portail disparaît.

Industrialiser la publication avec GitHub Actions

Le workflow suivant valide tous les manifestes modifiés, vérifie les specs OpenAPI, contrôle l'absence de secrets, et ne publie sur GitHub Pages que sur un tag de release. La séparation validation / publication est ce qui vous évite de servir un manifeste cassé.

# .github/workflows/validate.yml
name: Validate & Publish Security Copilot plugins

on:
  push:
    branches: [main]
    tags: ['v*.*.*']
  pull_request:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: plugins-${{ github.ref }}
  cancel-in-progress: true

jobs:
  validate:
    name: Validation des manifestes
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Installer les dépendances
        run: pip install pyyaml

      - name: Valider tous les manifestes
        run: |
          shopt -s nullglob
          manifests=(plugins/*/manifest.yaml)
          if [ ${#manifests[@]} -eq 0 ]; then
            echo "::error::Aucun manifeste trouvé sous plugins/*/"
            exit 1
          fi
          python3 scripts/validate_manifest.py "${manifests[@]}" --strict

      - name: Valider les specs OpenAPI (3.0.x uniquement)
        run: |
          npm install -g @redocly/cli@latest
          shopt -s nullglob
          for spec in plugins/*/openapi.yaml; do
            echo "--- $spec"
            version=$(grep -m1 '^openapi:' "$spec" | awk '{print $2}' | tr -d "\"'")
            case "$version" in
              3.0|3.0.0|3.0.1|3.0.2|3.0.3) ;;
              *) echo "::error file=$spec::OpenAPI $version non supporté (Security Copilot exige 3.0 ou 3.0.1)"
                 exit 1 ;;
            esac
            redocly lint "$spec" --format=github-actions
          done

      - name: Scan de secrets
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Vérifier la présence d'un CHANGELOG par plugin
        run: |
          for dir in plugins/*/; do
            if [ ! -f "${dir}CHANGELOG.md" ]; then
              echo "::warning file=${dir}::CHANGELOG.md manquant"
            fi
          done

  publish:
    name: Publication GitHub Pages
    needs: validate
    if: startsWith(github.ref, 'refs/tags/v')
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - uses: actions/checkout@v4

      - name: Construire l'arborescence versionnée
        run: |
          TAG="${GITHUB_REF_NAME}"          # ex. v2.1.0
          MAJOR="${TAG%%.*}"                # ex. v2
          mkdir -p _site
          for dir in plugins/*/; do
            plugin="$(basename "$dir")"
            mkdir -p "_site/${plugin}/${MAJOR}"
            cp "${dir}"*.yaml "_site/${plugin}/${MAJOR}/" 2>/dev/null || true
            cp -r "${dir}queries" "_site/${plugin}/${MAJOR}/" 2>/dev/null || true
          done
          echo "Publication de ${TAG} sous ${MAJOR}/"
          find _site -type f | sort

      - uses: actions/upload-pages-artifact@v3
        with:
          path: _site

      - id: deployment
        uses: actions/deploy-pages@v4

Deux garde-fous importants ici. permissions: contents: read au niveau du workflow applique le moindre privilège par défaut ; le job de publication remonte ponctuellement les droits pages: write dont il a besoin. Et le contrôle de version OpenAPI est explicite : la documentation Microsoft précise que seules les versions 3.0 et 3.0.1 sont supportées, ce qui est un piège classique quand un générateur produit du 3.1.

Contribuer au dépôt communautaire rod-trent/Security-Copilot

Le dépôt github.com/rod-trent/Security-Copilot est la référence communautaire pour les ressources Security Copilot : plugins d'exemple, promptbooks, scripts et documentation. Y contribuer donne à votre plugin une visibilité que votre dépôt personnel n'aura jamais, et vous expose à une revue par des praticiens.

Le workflow de contribution

1. Lire d'abord. Avant tout code, ouvrez le CONTRIBUTING.md et la licence du dépôt — les conventions de dossiers et les exigences peuvent avoir changé depuis la dernière fois que vous y êtes allé. Parcourez les plugins existants : la meilleure façon de faire accepter une PR est de ressembler à ce qui est déjà là.
2. Ouvrir une issue avant la PR. Décrivez le plugin, son cas d'usage, l'API tierce éventuelle qu'il consomme. Une PR de 400 lignes non annoncée a une espérance de vie limitée.
3. Forker et brancher. Une branche par contribution, nommée explicitement : plugin/contoso-ti-lookup. Jamais de PR depuis main de votre fork.
4. Un plugin par PR. Mélanger un nouveau plugin, une correction de typo et une refonte de README garantit un cycle de revue long.
5. Synchroniser avant de soumettre. git fetch upstream && git rebase upstream/main pour présenter un diff propre.

Les standards de qualité qui font passer une PR

Au-delà des règles du dépôt, quatre critères font la différence :

• Aucun endpoint ni identifiant interne. Purgez les TenantId, noms de workspaces, URLs d'API internes. Remplacez-les par des placeholders {{TenantId}} ou des settings configurables.
• Un README par plugin. Prérequis, skills exposées, prompts d'exemple, données transmises à des tiers.
• Des prompts d'exemple qui fonctionnent réellement. Testez-les dans une session avant de les documenter. Un exemple qui échoue est la première chose que le mainteneur va reproduire.
• Une skill par intention. Les recommandations d'authoring Microsoft sont explicites : préférez une skill GetDevices acceptant plusieurs entrées à trois skills GetDeviceById, GetDeviceByUserId et GetDeviceByUserName. La multiplication de skills quasi identiques provoque des collisions et dégrade la sélection par le modèle pour tous les utilisateurs du dépôt.

Anticipez enfin la question de la maintenance : un mainteneur hésitera à intégrer un plugin qui dépend d'une API tierce que personne d'autre ne peut tester. Indiquez explicitement si vous vous engagez à maintenir le plugin et à répondre aux issues qui le concernent.

Le passage par le Microsoft Security Marketplace

La publication commerciale via le Marketplace est un registre différent : ce n'est plus une contribution communautaire, c'est une offre commerciale d'un éditeur identifié. Deux points à intégrer d'emblée : le processus est celui du Partner Center Microsoft, et les critères comme les délais de revue évoluent — vérifiez toujours la documentation partenaire en vigueur plutôt que de vous fier à un article, y compris celui-ci.

Les prérequis structurels

Le socle est stable dans le temps, même si les détails bougent :

• Un compte éditeur Partner Center vérifié. La vérification d'identité de l'entité juridique est un préalable, et c'est souvent l'étape la plus longue pour une petite structure.
• Une offre décrivant le produit : description, captures, catégories, plans tarifaires ou modèle « contactez-moi ».
• Une documentation technique publique couvrant l'installation, la configuration et le dépannage.
• Une politique de confidentialité et des conditions d'utilisation accessibles à des URL stables.
• Un canal de support identifié avec un engagement de réponse.
• Un artefact techniquement valide : manifeste conforme, spec OpenAPI dans une version supportée, endpoints en HTTPS avec certificats valides.
• Conformité RGPD documentée si vous ciblez le marché européen : nature des données traitées, sous-traitants, localisation.

La revue Microsoft combine des contrôles automatisés (validation du manifeste, scan de l'artefact, vérification des URLs) et une revue humaine portant sur la qualité de la description, la cohérence de l'offre et le respect des politiques de la place de marché. Un rejet en revue humaine ne renvoie pas au point de départ mais impose un cycle de correction ; prévoyez plusieurs itérations pour une première soumission plutôt qu'un calendrier tendu autour d'une date de lancement. Le facteur qui accélère le plus le processus est trivial : une documentation complète et un plugin qui fonctionne du premier coup dans un tenant vierge, sans étape non documentée.

Sécurité des plugins tiers : évaluer avant d'activer

Le corollaire de la distribution est la consommation. Activer un plugin tiers dans Security Copilot, c'est autoriser un composant externe à recevoir des données de sécurité et, selon les skills, à agir. Microsoft le formule sans ambiguïté dans sa documentation : les plugins que vous créez ou rendez disponibles doivent être fully vetted, et la bonne pratique consiste à les valider au niveau utilisateur avant de les rendre disponibles à toute l'organisation.

Grille d'évaluation avant activation

1. Lire le manifeste, ligne par ligne. C'est un fichier YAML de quelques centaines de lignes : il n'y a aucune excuse pour ne pas le lire. Repérez les OpenApiSpecUrl et EndpointUrl : vers quels domaines pointent-ils ? Sont-ils en HTTPS ? Le domaine correspond-il à l'éditeur annoncé ?
2. Lire la spec OpenAPI référencée. C'est elle qui définit ce qui est réellement envoyé : chemins, paramètres, corps de requête. Un manifeste anodin peut référencer une spec qui exfiltre bien plus que ce que la description laisse entendre.
3. Examiner le type d'authentification. AADDelegated fait agir le plugin avec l'identité de l'utilisateur : ses permissions deviennent celles de l'analyste. Exigez la liste des EntraScopes demandés et refusez tout scope non justifié par les skills annoncées.
4. Auditer les skills KQL. Une skill KQL s'exécute sur votre workspace Sentinel ou sur vos données Defender. Lisez chaque requête. Une requête qui projette des colonnes sensibles sans raison, ou qui balaie un historique bien plus large que nécessaire, est un signal.
5. Vérifier la provenance et la vitalité. Dépôt public, historique de commits, réactivité aux issues, présence d'un SECURITY.md. Un plugin sans mainteneur identifiable ne devrait pas atteindre le scope tenant.
6. Tester en scope personnel d'abord. Activez avec le tag private, exécutez des prompts représentatifs, observez le trafic sortant si votre infrastructure le permet, mesurez la consommation. Ce n'est qu'ensuite que la publication organisationnelle se discute.

Moindre privilège en pratique

Trois leviers concrets. D'abord, provisionnez des identifiants dédiés par plugin plutôt qu'une clé API partagée : en cas de compromission, vous révoquez un seul accès et vous savez lequel. Ensuite, exploitez la configuration côté propriétaire : la restriction de disponibilité des plugins préinstallés permet de limiter certains plugins aux Owners, y compris dans les expériences embarquées — attention, c'est un changement à effet immédiat qui impacte tous les utilisateurs, à annoncer avant application. Enfin, désactivez ce qui ne sert pas : chaque plugin actif est une source que le modèle peut décider d'invoquer, avec un coût en Security Compute Units à la clé. La discipline de désactivation a un double bénéfice, sécurité et budget — sujet que nous détaillons dans notre article sur le dimensionnement des Security Compute Units.

Monitoring d'un plugin en production

Un plugin distribué à une organisation entière devient un composant de production. Il faut savoir s'il fonctionne, à quelle fréquence il est appelé, et comment il échoue.

Instrumenter côté API

Pour un plugin de format API, l'essentiel de l'observabilité vous appartient : c'est votre backend qui est appelé. Instrumentez au minimum le taux d'erreur par opération, la latence au 95^e percentile, le volume d'appels par jour et par client, et le taux de réponses vides. Ce dernier indicateur est le plus révélateur : un plugin qui répond systématiquement « aucun résultat » ne lève aucune alerte technique, mais il est inutile — et pire, il apprend aux analystes à ne plus l'utiliser.

Deux réflexes de conception. Utilisez un en-tête User-Agent distinctif et versionné côté API pour isoler le trafic Security Copilot du reste, et pour identifier quelle version du plugin est encore en circulation — c'est ce qui vous dira quand vous pouvez retirer /v1/ en toute sécurité. Et renvoyez des messages d'erreur exploitables par le modèle : un HTTP 429 avec un corps expliquant « quota dépassé, réessayer dans N secondes » produit une réponse compréhensible pour l'analyste, là où un 500 générique produit une réponse confuse.

Suivre l'usage côté Security Copilot

Côté plateforme, les propriétaires disposent d'un tableau de bord d'utilisation qui expose la consommation de SCU et son évolution. Trois lectures utiles pour un plugin :

• Corrélation activation / consommation. Un pic de SCU coïncidant avec la publication organisationnelle de votre plugin indique qu'il est invoqué plus souvent que prévu — souvent le symptôme d'une DescriptionForModel trop large qui le fait sélectionner hors de son domaine.
• Écart entre appels API et sessions. Si votre backend voit dix fois plus d'appels que le nombre de sessions concernées, une skill est probablement invoquée en boucle par un agent mal borné.
• Retours utilisateurs. Le canal le plus fiable reste le plus simple : un label d'issue dédié par plugin et une revue mensuelle. Les analystes ne signalent presque jamais qu'une skill renvoie des résultats médiocres — il faut aller le chercher.

Définissez enfin une procédure de retrait avant d'en avoir besoin : qui désactive le plugin en cas d'incident chez l'éditeur tiers, comment les utilisateurs sont informés, et quels promptbooks ou agents cassent si le skillset disparaît. Cette cartographie de dépendances se construit au moment de la publication, pas pendant l'incident.

FAQ

Puis-je publier un plugin pour toute mon organisation sans être Owner ?

Oui, mais uniquement si un Owner l'a explicitement autorisé. Deux réglages sont nécessaires dans Owner > Plugin settings : la permission d'ajouter et gérer ses propres plugins doit être positionnée sur « Owners and Contributors », ce qui débloque la seconde permission, « qui peut ajouter et gérer des plugins personnalisés pour tout le monde dans l'organisation », à positionner également sur « Owners and Contributors ». Par défaut, seuls les Owners peuvent ajouter et gérer leurs propres plugins. Notez l'asymétrie : un plugin créé par un Owner ne peut pas être modifié par un Contributor, même publié à l'échelle du tenant.

Faut-il héberger le manifeste sur une URL publique, ou l'upload de fichier suffit-il ?

L'upload de fichier convient parfaitement en phase de développement et pour un plugin qui ne bougera plus. L'URL devient nécessaire dès que vous avez un cycle de publication : elle permet à la CI de publier, elle évite que chaque utilisateur détienne une copie divergente, et elle rend le versionnement lisible via le chemin. Le prix à payer : l'URL doit rester accessible sans authentification interactive pour que la plateforme puisse la télécharger. D'où GitHub Pages pour du public, et Azure Blob avec un SAS en lecture seule et à durée limitée pour de l'interne. Dans les deux cas, versionnez le chemin et n'écrasez jamais une URL déjà consommée par un tenant.

Comment gérer une rupture de compatibilité sans casser les tenants existants ?

Publiez la nouvelle version majeure sur un chemin distinct — /v3/manifest.yaml — en laissant /v2/ intact et servi. Les installations existantes pointent toujours vers l'ancienne URL et continuent de fonctionner. Annoncez la migration dans le CHANGELOG et le README avec une date de fin de support d'au moins un trimestre. Pour une skill renommée, gardez l'ancien nom une version mineure de plus avec un préfixe [DEPRECATED] dans sa Description, puis retirez-le à la majeure suivante. Surveillez le User-Agent versionné côté API pour savoir quand plus personne n'utilise l'ancienne version : c'est le seul signal fiable pour couper.

Quels sont les délais et les critères de la revue Marketplace ?

Les critères comme les délais relèvent du programme partenaire Microsoft et évoluent ; consultez la documentation Partner Center en vigueur au moment de votre soumission plutôt qu'un chiffre trouvé dans un article. Structurellement, le processus enchaîne la vérification du compte éditeur, la création de l'offre, des contrôles automatisés sur l'artefact et les URLs, puis une revue humaine des éléments de la fiche produit. Planifiez plusieurs itérations pour une première soumission. Les rejets portent bien plus souvent sur la documentation, la politique de confidentialité ou des captures obsolètes que sur le manifeste lui-même.

Comment évaluer la sécurité d'un plugin tiers avant de l'activer pour mes analystes ?

Lisez le manifeste et la spécification OpenAPI qu'il référence — quelques centaines de lignes, c'est faisable en une heure et c'est la seule source de vérité sur ce qui sort de votre tenant. Vérifiez les domaines de destination, le type d'authentification et, pour AADDelegated, la liste exacte des scopes Entra demandés. Auditez chaque requête KQL, qui s'exécutera sur vos propres données. Testez ensuite en scope personnel avec le tag private, sur des prompts représentatifs, avant toute publication organisationnelle : c'est la recommandation explicite de Microsoft. Enfin, provisionnez des identifiants dédiés par plugin pour pouvoir révoquer chirurgicalement, et désactivez tout plugin qui ne sert plus.

Aller plus loin

La distribution d'un plugin n'est pas la dernière étape d'un projet, c'est le début de son cycle de vie opérationnel. Le manifeste que vous publiez devient une interface avec un contrat implicite : des noms de skills stables, un comportement prévisible, un endpoint qui répond. Traitez-le avec la rigueur que vous appliqueriez à une API publique — dépôt structuré, validation automatisée, chemins versionnés, changelog tenu, monitoring en place — et vous éviterez la trajectoire classique du plugin qui fonctionne trois mois puis se dégrade en silence.

Pour approfondir la conception des manifestes et des skills en amont de la publication, consultez notre guide des plugins Copilot Security ainsi que notre dossier complet sur Microsoft Security Copilot. Côté budget, la question de l'invocation des skills et de son coût est traitée dans notre article sur le dimensionnement des Security Compute Units. Enfin, la documentation officielle sur la création de plugins personnalisés et la référence du manifeste restent la source à consulter en premier, les champs et contraintes évoluant au rythme des mises à jour de la plateforme.

``` --- **Conformité vérifiée** | Critère SEO | Cible | Réel | |---|---|---| | Chapeau (1er `

`) | ≥120 mots | ~195 | | H2 | ≥9 (ratio ≤350) | 14 | | Liens internes | ≥4 | 5 (`/copilot-security/plugins` ×2, `/copilot-security`, `/articles/copilot-security-scu-…` ×2) | | Liens externes | ≥2 | 3 (rod-trent, 2× Microsoft Learn) | | Blocs de code | 4 demandés | 6 (arbo, README, manifest YAML, Bash, Python, GH Actions) | | FAQ H3 interrogatives | 5 | 5 | | `.a-retenir` | oui | oui | | `.rex-box` / `.warning-box` | H3, pas H4 | conforme | Aucun lien interne inventé : je n'ai pas pu interroger la table `articles` (permission MySQL refusée), donc je me suis limité aux 3 URLs que vous avez fournies, répétées pour atteindre le seuil de 4 ancres.