Connect Jira to CYBRET.
Two-way. CYBRET pushes findings into Jira with full attack-path context and remediation owners, and reads Jira's permission graph to flag the times Jira itself becomes part of the path.
Projects, schemes, and the people who can read them.
Jira is the system of record for engineering work in most of our customers. The integration covers the structure of that record (so CYBRET findings appear correctly) and the permission model (so we can flag where it fails).
- Projects: all projects in scope, project types (software, service desk), default issue types, lead.
- Issue model: issue types, custom fields, screens, the field configuration scheme per project.
- Workflow: workflows, statuses, transitions, including the conditions and post-functions on each transition.
- Permission schemes: the permission scheme per project, broken down by permission (Browse Projects, Edit Issues, Set Issue Security) and the roles / groups granted each.
- Project roles: who is in which role per project, including outside collaborators.
- Automation: automation rules, the trigger and actions, and the actor on whose behalf they run.
- Audit log: the audit log, scoped to permission scheme changes, role membership changes, and automation rule edits.
When Jira itself is part of the path.
Jira shouldn't be on the attack-path map; in practice it often is. These are the patterns we see when Jira leaks data, automates an unsafe action, or holds an over-privileged credential.
1. Public-comment field used for sensitive ticket data
Service-desk project → engineer pastes prod credentials into a public comment to reproduce an issue → contractor with Browse Projects on the project reads it.
The permission scheme allows Browse Projects to a broad role; the comment field is not security-restricted; the credential lands in the audit log searchable surface. CYBRET reads the permission scheme, identifies who can browse the project, and flags the high-blast-radius combination. Closing the path is a permission scheme change plus secret rotation.
2. Automation rule with admin actor runs user-supplied input
Automation rule with actor = Jira Admin → webhook trigger from a third-party tool → rule executes a smart-value templated step using payload fields → effective privilege escalation.
The rule's actor is Jira Admin; its trigger payload is attacker-controllable through an upstream service that's less trusted than the Jira admin role. CYBRET reads the rule definition, classifies the smart-value-from-payload pattern, and surfaces the path. The fix is changing the actor to a least-privilege service account or constraining the smart-value substitutions.
3. Leaked Jira PAT in CI
Personal access token of a user with Jira admin → in a CI variable used by a pipeline that runs on PRs → full Jira admin compromised on token leak.
The token is bound to a real user and has admin scope. CYBRET enumerates the API token inventory, joins it to the GitHub workflow file that consumes it, and surfaces the path. The fix is moving to a Connect app or a least-privilege service account, plus IP allowlisting.
One Connect app, project-scoped read, write to a configured project.
The integration is an Atlassian Connect app for Jira Cloud, or a Jira Server / Data Center plugin for self-hosted. CYBRET runs the app in your tenancy with read scope across the projects you select and write scope only on the project you nominate as the "CYBRET findings" destination.
- Open the CYBRET console and go to Integrations → Jira.
- Click Install Connect app for Jira Cloud, or download the supplied plugin for Server / Data Center.
- Choose the projects in scope for the read inventory. Select one project as the findings destination.
- Configure issue mapping. The default maps a CYBRET finding severity to a Jira priority and creates issues with the "CYBRET-Finding" issue type. Both are customisable.
- Optional: configure a webhook so Jira issue state changes flow back into CYBRET (closing a finding in Jira closes it in CYBRET).
- The first inventory pass typically completes inside fifteen minutes. Findings start landing in the configured project as the rest of your integrations build out the graph.
Disconnect by uninstalling the Connect app. CYBRET retains the issue audit trail of what it created and stops creating new issues at uninstall.
Read everywhere it's in scope. Write only to the configured project.
The Connect app uses Atlassian's standard scopes. READacross the projects you place in scope; WRITE only on the single project you nominate as the findings destination. We do not request ADMIN or DELETE. The app cannot read issues outside its scope, cannot edit permission schemes, and cannot install other apps.
For self-hosted Jira (Server / Data Center) the same model applies via a CYBRET-supplied plugin. Customers running an air-gapped CYBRET in the same network as Jira use the plugin variant; no inbound connection from the CYBRET cloud is required.
Where Jira data shows up in the platform.
Exposure Intelligence uses Jira primarily as a finding-delivery target. The product's reachable paths land as Jira issues with full attack-path context, remediation owner, and a backlink to the CYBRET console. We treat Jira's state machine as the source of truth; closing the issue closes the finding.
Validation uses Jira to attach proof. When CYBRET produces a proof-of-exploit screenshot or response sample, it lands in the same Jira issue as a comment with the appropriate visibility. Engineering teams can verify without cross-referencing two tools.
Runtime Detection uses Jira for paging during incidents that warrant a ticket. The integration can be configured so that only specific severities or specific surface types create Jira issues; everything else flows to chat.
Questions security engineers actually ask.
How does authentication work?
An Atlassian Connect app for Jira Cloud, or a CYBRET-supplied plugin for Server / Data Center. Connect tokens are managed by Atlassian; we do not store user passwords or PATs unless you explicitly opt into the API-token mode for legacy reasons.
Where does the Jira data live?
Inside the CYBRET deployment in your VPC. We do not move Jira issue contents to a multi-tenant SaaS backend.
What does the bot account need?
For the API-token mode (instead of Connect): a service account with Browse Projects on read-scope projects and Create Issues / Edit Issues / Add Comments on the findings project. No admin permissions.
Service Management (Jira Service Desk)?
Supported. The findings project can be a Service Management project; issues land as standard requests with the configured request type.
How do you avoid duplicate issues?
Each CYBRET finding has a stable graph identity. The integration uses that as a deduplication key on the Jira issue, so reopened paths re-open the existing issue rather than creating a new one.
On-prem Data Center?
Supported via the plugin. Air-gapped Data Center connects to a self-managed CYBRET in the same network; no internet egress is required.
Connect Jira →
Findings with attack-path context, remediation owners, and a clean backlink. Engineering teams keep working in Jira.
Connect JiraSee Exposure Intelligence