Documentation
Connectors
Twelve connectors ship today: six sources, three edges, two delivery targets and the probing settings that decide what Zedgenta is allowed to touch. Anything not on this list still gets in — it posts to a single authenticated feed. A connector is not what makes a tool supported; it is what makes its credentials and sync managed for you.
Overview
| Kind | Connectors | |
|---|---|---|
| Sources | 6 | Orca Security, Wiz, Jira, HackerOne, Intigriti, Bugcrowd |
| Edges | 3 | Cloudflare, AWS WAF, Akamai |
| Delivery | 2 | GitHub, Slack |
| Settings | 1 | Probing — grants, edge order, deploy consent |
How credentials are held
Every connector is a set of named fields, and each field is either a credential or a setting. The difference is not cosmetic.
- Credentials are encrypted before storage. Their values are never returned — not to the console, not to the API. You see only whether a field is set, and you can replace or delete it. There is no read path.
- Settings — a zone tag, a region, a WebACL ARN — are stored in the clear and shown back to you, because “which zone did I name?” has to be answerable from the screen.
Writing a credential into a settings field is refused rather than quietly stored unencrypted. A connector counts as configured once every required field is set; optional fields refine behaviour, they never gate it.
Sources
Each turns a vendor's own object — an alert, an issue, a report — into one canonical finding.
Orca Security
| Field | What it is | |
|---|---|---|
orca_api_token | required | Read-only Orca API token. Stored encrypted; never readable back. |
orca_base_url | optional | Defaults to https://api.orcasecurity.io. |
orca_webhook_secret | optional | Set it here and in Orca to have findings pushed the moment they are raised. |
Wiz
| Field | What it is | |
|---|---|---|
wiz_api_url | required | https://api.<region>.app.wiz.io/graphql |
wiz_client_id | required | Service-account client id. |
wiz_client_secret | required | Service-account secret. |
wiz_webhook_secret | optional | Enables pushed delivery. |
Jira
| Field | What it is | |
|---|---|---|
jira_base_url | required | https://<org>.atlassian.net |
jira_email | required | The account the API token belongs to. |
jira_api_token | required | Atlassian API token. |
jira_jql | optional | Which issues count as security issues. Defaults to a security-label query. |
jira_webhook_secret | optional | Enables pushed delivery. |
If Jira connects but nothing arrives, the JQL is almost always why.
The default is a security-label query; if your issues are not labelled that way you will get
zero findings from a connector that tests green. The test reports how many issues matched, so
a pass reading 0 issues matched is the tell. Set the JQL explicitly.
Bug bounty platforms
| Field | What it is | |
|---|---|---|
hackerone_program / hackerone_api_identifier / hackerone_api_token | required | Program handle plus API credentials. Triaged reports become findings. |
intigriti_program_id / intigriti_api_token | required | Accepted submissions become findings. |
bugcrowd_program / bugcrowd_api_token | required | Program slug plus token. Triaged submissions become findings. |
<source>_webhook_secret | optional | Optional on all three; enables pushed delivery. |
Edges
An edge does three jobs: it lists the rules already in front of you, it supplies the events that name which layer actually acted on a probe, and — only with your consent — it is where a log-mode rule is deployed.
Cloudflare
| Field | What it is | |
|---|---|---|
cloudflare_api_token | required | Zone WAF read. Add Zone WAF edit only if Zedgenta may deploy log-mode rules. |
cloudflare_zone_tag | required | The zone whose events name which layer acted on a probe. |
cloudflare_account_id | optional | Account scope, where your token needs it. |
AWS WAF
| Field | What it is | |
|---|---|---|
aws_access_key_id / aws_secret_access_key | required | Credentials for the account holding the WebACL. |
aws_region | optional | Defaults to us-east-1. |
aws_role_arn / aws_external_id | optional | Assume a role instead of using long-lived keys. |
aws_web_acl_arn | optional | Where a Count-mode rule is deployed. Absent means compile-only — nothing is ever deployed. |
aws_waf_log_group | optional | CloudWatch group holding WAF logs. Absent means no attribution — Zedgenta cannot say which rule acted. |
The two optional AWS fields are capability limits rather than errors. Without a WebACL ARN, Zedgenta compiles rules and never deploys. Without a log group, it cannot tell you which rule acted, so it says nothing acted rather than crediting a rule that was never in the way.
Akamai
| Field | What it is | |
|---|---|---|
akamai_host / akamai_client_token / akamai_client_secret / akamai_access_token | required | EdgeGrid client with Application Security READ-WRITE. |
akamai_config_id / akamai_security_policy_id | required | The security configuration and the policy a rule is associated with. |
akamai_notification_emails | optional | Akamai notifies these addresses on activation. |
Akamai rules are activated on staging only, in alert mode, with consent. The custom-rule shape is written from Akamai's documentation and has not yet been verified against a live configuration — treat your first activation as the verification.
Delivery
Where a proposal lands is yours to configure — a pull request, a chat message, or a feed of your own. Nothing takes effect until a human approves it.
| Field | What it is | |
|---|---|---|
github_token | required | Needs contents:write and pull_requests:write. |
github_owner / github_repo | required | Where Terraform pull requests are opened. |
slack_webhook_url | required | Incoming webhook for verdict and remediation cards. |
slack_channel | optional | Overrides the webhook's default channel. |
Probing and grants
You do not need to set anything here to start probing. Connecting Cloudflare or Akamai is the proof of ownership: every Cloudflare zone on the account (and every name beneath it) and every hostname in the Akamai security configuration becomes probeable automatically. Nothing outside a connected edge or an extra origin is ever probed, and internal addresses never are.
| Field | What it is | |
|---|---|---|
zedgenta_grants | optional | Extra origins outside a connected Cloudflare or Akamai account, such as hosts behind AWS WAF. Each is matched exactly. |
zedgenta_edges | optional | Ordered list. All configured edges feed attribution; the first authors rules. Absent: whichever edge credentials resolve. |
zedgenta_probe_target | optional | Used when a finding carries no surface of its own. Must be on a connected edge or an extra origin. |
zedgenta_deploy_actor | optional | Who consented to log-mode deployment. Absent means Zedgenta never deploys. |
Third-party domains. When a finding points at a domain outside your connected edges (a partner API, a vendor-hosted page), nothing is sent to it and the finding says so. Open it and, if you are authorised by that domain's owner to test it, tick the attestation and choose Approve probing and re-run. That records a 30-day grant for that one exact host, with your name on it and an entry in the audit trail, and runs the finding again. API keys cannot give consent; a signed-in person has to.
An extra origin names one exact host:
[{"origin":"https://shop.example.com","method":"contract","verifiedAt":"2026-09-01T00:00:00Z"}]No deploy actor means Zedgenta never deploys — it compiles, proposes and stops. That is a deliberate default, not an unconfigured state.
Testing a connector
Every connector has a Test button. A test makes one cheap authenticated call through the same client the product uses, so a pass means “the product can use this”, not “the string looked well-formed”. Three outcomes:
- Passed and verified — a real call succeeded. Sources report how many findings, issues, reports or submissions were visible.
- Present, not verified — the fields are set but no call was made. Slack is the case today: pinging an incoming webhook posts a message into somebody's channel, so presence is checked and the result says exactly that rather than implying more.
- Failed — either a required field is missing, and it is named, or the vendor answered and its answer is passed through.
Probing is tested differently: it lists the domains your connected edges front, adds any extra
origins, checks the probe target is covered, and tells you whether a deploy actor is named. no deploy consent (never deploys)
is a passing test.
Pushed or polled
Every source has an optional webhook secret, and it is the difference between the two ways a finding can arrive:
- Left blank — findings arrive on a schedule.
- Set here and in the vendor's console — findings are pushed the moment they are raised.
Pushed deliveries are verified by signature before anything else touches them: headers, then the timestamp where the vendor binds one in, then a constant-time signature check over the raw body, then a replay check. A source with no webhook secret configured does not answer at all — an unconfigured receiver should not admit it exists.
Whichever path a finding takes, it goes through the same admission decision, so the outcome and the evidence are identical either way.
Everything else
The connectors above are the tools whose credentials and sync we manage. Every other scanner, tracker or feed reaches Zedgenta the same way: it posts findings to one authenticated endpoint, and from there they are indistinguishable from a native source. No custom engineering, and no waiting for us to build a connector.
If a tool you depend on would be better as a managed connector, tell us which — that is how this list gets longer.