Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez étendre les fonctionnalités de Security Copilot en créant vos propres plug-ins personnalisés. La plateforme prend en charge un framework flexbile pour créer des plug-ins qui peuvent être utilisés pour effectuer des tâches spécialisées qui répondent à vos besoins de flux de travail.
Création de nouveaux plugins
Selon la manière dont vos administrateurs configurent Sécurité Copilot, vous pourrez peut-être créer de nouveaux plugins en suivant les étapes suivantes :
Créer un plugin à partir de la liste des plugins pris en charge.
Créer un fichier manifeste de plugin YAML ou JSON, qui décrit les métadonnées du plugin et la manière de l'invoquer.
Publier le manifeste du plugin dans Sécurité Copilot.
Conditions requises pour les plug-ins
Chaque plugin Sécurité Copilot nécessite un fichier manifeste au format YAML ou JSON (par exemple : plugin.yamlouplugin.json ) qui décrit les métadonnées relatives à l'ensemble de compétences et la manière d'invoquer les compétences.
Un manifeste se compose de deux clés de niveau supérieur requises, Descriptor et SkillGroups, chacune avec des paires sous-clé ou valeur, et des champs obligatoires/facultatifs en fonction du format de compétence.
Pour plus d’informations, consultez Manifeste de l’agent.
Différences entre les manifestes OpenAI et Sécurité Copilot
Les plugins OpenAI construits en suivant la documentation du plugin ChatGPT utilisent généralement un format de manifeste différent de celui du Security Copilot. Sécurité Copilot prend en charge les deux formats.
Le manifeste du plugin OpenAI, lorsqu'il est téléchargé, est traduit en manifeste Sécurité Copilot.
Remarque
Les détails de la cartographie, notamment en ce qui concerne les restrictions dans les notes, peuvent changer à l'avenir. Actuellement, la plateforme ne prend en charge que les plug-ins des versions 3.0 ou 3.0.1 de l' OpenAPI.
Cartographie des champs du plug-in
| Champ du plug-in | Type | Champ du descripteur | Obligatoire | Remarques |
|---|---|---|---|---|
schema_version |
string | Non | Il s'agit de la version du schéma du manifeste de l' OpenAI, par exemple « v1 ». Actuellement non utilisé. | |
name_for_model |
string | Nom | Oui | Limité à 100 caractères. Nom interne de l'ensemble de compétences. Ne permet pas / \ ? #. |
name_for_human |
string | DisplayName | Oui | Nom lisible par l'homme du plug-in. Limité à 40 caractères. |
description_for_model |
string | Description | Oui | Limité à 16 000 caractères. Description interne à utiliser avec LLM. |
description_for_human |
string | DescriptionAffichage | Oui | Description lisible par l'homme du plug-in. Limité à 200 caractères. |
logo_url |
string | Icône | Recommandé | URL utilisée pour récupérer l'icône principale du plug-in |
contact_email |
string | Non | Contact e-mail pour le plug-in. Actuellement non utilisé. | |
legal_info_url |
string | Non | Lien pour des informations sur le plug-in. Actuellement non utilisé. | |
api |
objet | Voir la section API du plug-in pour la structure de l'objet | Oui | |
auth |
objet | Oui |
authorization_type est limité àbearer. Détails à suivre sur le support des différentes authentifications type comme none, oauth, api_key, aad, aad_delegated. |
Plug-in (champ API)
Structure de l'objet pour le api champ
| Champ | Type | Description | Obligatoire |
|---|---|---|---|
type |
chaîne | Le seul type pris en charge actuellement est openapi. |
Oui |
url |
string | Lien vers votre fichier de spécification OpenAPI | Oui |
Conseils pour la création de plug-ins
De nombreuses considérations entourent la création de plug-ins. Ce document a pour but de présenter certaines des lignes directrices et des meilleures pratiques en matière d'écriture de plug-ins pour Sécurité Copilot.
Remarque
Une « collision de compétences » se produit quand Security Copilot ne fait pas la distinction entre deux compétences différentes.
Au lieu d'avoir plusieurs compétences qui renvoient le même type de réponse mais qui diffèrent uniquement en fonction des entrées, définissez des compétences qui acceptent plusieurs entrées et qui déterminent ensuite en interne comment obtenir les données.
- Par exemple, il est possible d'avoir une
GetDevicescompétence unique qui prend en compte l'identifiant de l'appareil, l'identifiant de l'utilisateur ou le nom de l'utilisateur au lieu d'avoir des compétences distinctesGetDeviceById,GetDeviceByUserId, etGetDeviceByUserName
- Par exemple, il est possible d'avoir une
Le Copilot de sécurité prend en charge
DescriptionetDescriptionForModelremplit les champs.Descriptionest utilisé dans l'interface utilisateur (et pour la sélection des compétences siDescriptionForModelelle n'est pas définie) etDescriptionForModeln'est utilisé que pour la sélection des compétences.- Par exemple, supposons que nous ayons une compétence GetSslCertsByHostname, dont la description est « Renvoie les certificats SSL associés à un nom d'hôte ». Une description détaillée deForModel pourrait être « Récupère » les certificats SSL (également connus sous le nom de certificats TLS) pour un nom d'hôte DNS ou un nom de domaine. Renvoie une liste de certificats SSL avec les détails du certificat tels que l'émetteur, le sujet, le numéro de série, sha1, et les dates ».
Les descriptions de compétences doivent être verbeuses et formulées pour quelqu'un qui a des connaissances raisonnables, mais qui n'est pas nécessairement un expert dans votre domaine de problèmes. Elle doit décrire non seulement ce que fait la compétence, mais aussi pourquoi quelqu'un voudrait l'utiliser.
- Par exemple, une bonne description est la suivante : « Obtient des informations sur la réputation d'une adresse IP. Permet aux utilisateurs de déterminer si une adresse IP est risquée ».