Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È possibile estendere le funzionalità di Security Copilot creando plug-in personalizzati. La piattaforma supporta un framework flexbile per creare plug-in che possono essere usati per eseguire attività specializzate che soddisfano i requisiti del flusso di lavoro.
Creazione di nuovi plug-in
A seconda di come gli amministratori configurano Security Copilot, è possibile creare nuovi plug-in seguendo questa procedura:
Creare un plug-in dall'elenco dei plug-in supportati.
Creare un file manifesto del plug-in YAML o JSON, che descrive i metadati relativi al plug-in e come richiamarlo.
Pubblicare il manifesto del plug-in in Security Copilot.
Requisiti del plug-in
Ogni plugin di Security Copilot richiede un file manifesto in formato YAML o JSON (ad esempio: plugin.yaml o plugin.json) che descrive i metadati relativi al set di competenze e le modalità di richiamo delle competenze.
Un manifesto è costituito da due chiavi di primo livello necessarie, Descriptor e SkillGroups, ognuna con coppie sottochiave o valore e campi obbligatori/facoltativi a seconda del formato della competenza.
Per informazioni, vedere Manifesto dell'agente.
Differenze tra i manifesti OpenAI e Security Copilot
I plugin OpenAI costruiti seguendo la documentazione dei plugin ChatGPT utilizzano in genere un formato di manifest diverso da quello di Security Copilot. Security Copilot supporta entrambi i formati.
Il manifesto del plug-in OpenAI al momento del caricamento viene convertito nel manifesto di Security Copilot.
Nota
I dettagli di mapping, in particolare per quanto riguarda le restrizioni nelle note, possono cambiare in futuro. Attualmente, la piattaforma supporta solo i plug-in nelle versioni OpenAPI 3.0 o 3.0.1.
Mapping dei campi del plug-in
| Campo del plug-in | Tipo | Campo descrittore | Obbligatorio | Note |
|---|---|---|---|---|
schema_version |
stringa | No | Si tratta della versione dello schema del manifesto OpenAI, ad esempio 'v1'. Attualmente non in uso. | |
name_for_model |
stringa | Nome | Sì | Limite di lunghezza di 100 caratteri. Nome interno delle competenze. Non consente / \ ? #. |
name_for_human |
stringa | DisplayName | Sì | Nome leggibile del plug-in. Limite di lunghezza di 40 caratteri. |
description_for_model |
stringa | Descrizione | Sì | Limite di lunghezza di 16.000 caratteri. Descrizione interna da usare con LLM. |
description_for_human |
stringa | DescriptionDisplay | Sì | Descrizione leggibile del plug-in. Limite di lunghezza di 200 caratteri. |
logo_url |
stringa | Icona | Consigliata | URL usato per recuperare l'icona principale per il plug-in. |
contact_email |
stringa | No | Contatto di posta elettronica per il plug-in. Attualmente non in uso. | |
legal_info_url |
stringa | No | Collegamento per informazioni sui plug-in. Attualmente non in uso. | |
api |
oggetto | Per la struttura degli oggetti, vedi la sezione API del plug-in. | Sì | |
auth |
oggetto | Sì |
authorization_type è limitato a bearer. Dettagli da seguire sul supporto per un'autenticazione type diversa, ad esempio nessuno, oauth, api_key, aad, aad_delegated. |
Plug-in (campo API)
Struttura dell'oggetto per il campo api
| Campo | Tipo | Descrizione | Obbligatorio |
|---|---|---|---|
type |
stringa | L'unico tipo attualmente supportato è openapi. |
Sì |
url |
stringa | Collegamento al file di specifica OpenAPI | Sì |
Linee guida per la creazione di plug-in
Ci sono molte considerazioni sulla creazione di plug-in. Questo documento ha lo scopo di acquisire alcune delle linee guida e delle procedure consigliate per la scrittura di plug-in per Security Copilot.
Nota
Una "collisione di competenze" si verifica quando Security Copilot non distingue accuratamente tra due competenze diverse.
Anziché avere più funzionalità che restituiscono lo stesso tipo di risposta, ma differiscono solo in base agli input, è opportuno definire le funzionalità, che accettano più input e pertanto consentono di capire internamente come ottenere i dati.
- Ad esempio, avere una singola competenza
GetDevicesche accetta l'ID dispositivo, l'ID utente o il nome utente invece di separareGetDeviceById,GetDeviceByUserIdeGetDeviceByUserName
- Ad esempio, avere una singola competenza
Security Copilot supporta i campi
DescriptioneDescriptionForModel.Descriptionviene usato nell'esperienza utente (e per la selezione delle competenze seDescriptionForModelnon è impostato) eDescriptionForModelviene usato solo per la selezione delle competenze.- Ad esempio, supponiamo di avere una funzionalità GetSslCertsByHostname, con la descrizione "Restituisce i certificati SSL associati a un nome host". Una descriptionForModel dettagliata potrebbe essere la seguente: "Recupera i certificati SSL (noti anche come certificati TLS) per un nome host DNS o un nome di dominio. Restituisce un elenco di certificati SSL insieme ai dettagli del certificato, ad esempio autorità di certificazione, soggetto, numero di serie, sha1 e date".
Le descrizioni delle competenze devono essere dettagliate e formulate per una persona che ha una conoscenza ragionevole, ma che potrebbe non essere un esperto del problema. Dovrebbe descrivere cosa fa la funzionalità e il motivo per cui una persona potrebbe usarla.
- Ad esempio, una descrizione valida è la seguente: "Ottiene informazioni sulla reputazione di un indirizzo IP. Consente agli utenti di stabilire se un indirizzo IP è rischioso".