Documentation / PAC Attacks
Metadata File
metadata.yaml Reference
Every custom add-on or custom scan ships with a metadata.yaml manifest. Prancer reads it to know how to load and execute the add-on, and uses the Tags: section to match it against your PAC files.
Tip: metadata.yaml is currently used most by ZAP add-ons, but the format is generic — Prancer applies it to other tooling too (Nuclei, standalone scanners).
Before you start
- You're building a custom add-on — see Custom Add-ons for the end-to-end flow.
- You know which dimensions you want to tag your add-on by (cloud, compliance, MITRE, etc.).
Field reference
Name
Short identifier. Prancer uses this to load the add-on, so keep it stable across versions.
Description
A clear sentence explaining what the add-on does and when it applies.
Charset
Character encoding — almost always UTF-8.
Engine
The runtime the add-on needs. ZAP needs to know whether to run it as Java, ZEST, ECMAScript, Python, etc.
Parameters and Secrets
Parameters— values that should be injected into the PAC file at scan time.Secrets— values that should be fetched from your vault (never put secret values inmetadata.yaml).
Warning: anything sensitive must live in Secrets and be retrieved at runtime — never hardcode tokens or passwords in this file.
Type
Category of the add-on. One of:
| Value | Meaning |
| ------- | --------- |
| Addon | A ZAP add-on. |
| Script | Code executed by ZAP. |
| ZEST | A ZEST script set. |
| Standalone | An external tool — runs without ZAP. |
| Zap | A built-in ZAP add-on. |
Tags
The richest section. Use these to power auto-tag loading.
| Tag | Use it for |
| ----- | ----------- |
| Cloud | Azure, AWS, GCP, Onpremise. |
| Compliance | CIS, CSA-CCM, HIPAA, ISO 27001, PCI_DSS, NIST 800, HITRUST, SOC 2, GDPR, Best Practice. |
| CWEID | All applicable CWE IDs. |
| MITRE | All applicable MITRE ATT&CK IDs. |
| Os | Windows, Linux. |
| Programming | Language of the vulnerability being scanned. |
| Service | HTTP, FTP, SSH, RDP. |
| Type | All, Web, OpenAPI, GraphQL, SOAP. |
Tip: be generous with tags. The more dimensions you cover, the easier it is to reuse the add-on across PAC files.
Full example
Name: Name of the Addon
Description: Description of the Addon
Charset: UTF-8
Engine: [Java, ZEST, ECMAScript, Python]
Parameters:
ExampleParameter: Parameters that should get passed onto the pac file
Secrets:
ExampleSecret: Secret values that should be accessed from the vault
Type: [Addon, Script, ZEST, Standalone, Zap]
Tags:
Cloud: [Azure, AWS, GCP, Onpremise]
Compliance: [CIS, CSA-CCM, HIPAA, ISO 27001, PCI_DSS, NIST 800, HITRUST, SOC 2, GDPR, Best Practice]
CWEID: All CWE IDs associated with the addon
MITRE: All MITRE Att&CK IDs associated with the addon
Os: [Windows, Linux]
Programming: Language of the vulnerability being scanned
Service: [HTTP, FTP, SSH, RDP]
Type: [All, Web, OpenAPI, GraphQL, SOAP]
Next steps
- Use the metadata to power Attack Auto Tagging.
- See it in context: Custom Add-ons walkthrough.
- Custom Nuclei templates use a slightly different metadata — Custom Nuclei.