Connect the tools your teams use
One connector hub reaches three ITSM platforms, Jira, ServiceNow, and ManageEngine, and six CI/CD systems including GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket, with credentials encrypted at rest.
PMAP capability
ITSM and CI/CD Integrations
Push findings into the tools your teams already work in. PMAP creates and syncs tickets in Jira, ServiceNow and ManageEngine, gates CI/CD pull requests on new risk, and triggers runbooks from a 22-action catalog.
Meet teams where they already work
Security findings only get fixed when they reach the systems engineers and operators use every day. Copying items by hand breaks that link and lets status drift.
PMAP wires findings directly into ITSM and CI/CD. Tickets stay in sync both ways, pipelines react to new risk, and automated runbooks handle the repetitive response.
From hand-copied tickets to one synced record
The same finding, retyped into three tools and already drifting out of step, becomes one governed finding wired to one ticket, with status flowing back both ways.
Copied by hand, drifting apart
- Jira In Review hand-entered
- ServiceNow New hand-entered
- Spreadsheet done? tracker
- PMAP Open source finding
One synced finding
One finding, one ticket
- JIRA-4821
- two-way sync
- P1 mapped
A webhook push plus a 5-minute reconciling poll keep ticket and finding in step, so a status change an owner makes reflects back without anyone chasing it.
What integrations cover
Two-way ticket sync
Create Jira, ServiceNow or ManageEngine tickets from PMAP and keep status in sync via polling and webhooks, so neither side goes stale.
- Jira, ServiceNow and ManageEngine
- Status kept in sync both ways
- Polling and webhook updates
Create from a finding or in bulk
Open a ticket from a single finding or from a bulk selection, so large remediation campaigns do not become manual ticket entry.
- Single-finding or bulk creation
- Campaign-scale ticketing
- Mapped fields on create
Gate CI/CD pull requests
CI/CD pipelines can gate pull requests on new critical or high findings, so risky changes are caught before they ship.
- Gate on new critical or high findings
- Block risky merges early
- Fits existing pipelines
Event-triggered runbooks
Event-triggered runbooks automate response across a 22-action catalog when subscribed events match, so routine handling does not wait on a person.
- 22-action automation catalog
- Triggered by subscribed events
- Consistent, repeatable response
How the integrations work end to end
Findings flow out to the tools owners and developers already use, status flows back into one governed record, and every inbound message is verified and tenant-scoped first.
Map fields before any ticket lands
Persistent per-integration rules resolve severity to vendor priority, status to the right workflow transition, and assignee, with conditional overrides, all evaluated before a single vendor call.
Create one ticket or up to 500
Open a ticket from a single finding or bulk-create up to 500 at once. A per-finding result list reports each outcome, so one failure never aborts the batch, and a dry run previews the diff first.
Keep ticket and finding in step
A webhook push plus a background poll every five minutes reconcile status both ways, so a ticket moved to done reflects back onto the finding without the security team chasing anyone.
Verify every inbound webhook
CI events are checked with a per-vendor HMAC or constant-time token over the raw body before the payload is read, and an unsigned hook is rejected in production.
Gate the merge on new risk
A verified CI event fans out to SAST and SCA targets on the branches you choose, then posts a pass or fail commit status that evaluates only the new findings the change introduced.
What your team gets
Remediation where work already happens
Owners act on tickets in Jira or ServiceNow and developers stay in their pipeline, so findings get fixed in the tools people already live in instead of a console nobody opens.
No drift between ticket and finding
A two-way channel keeps both records in step, so the status a remediation owner sets is the status the security team sees, with no manual reconciliation.
Risky merges caught early
The pull-request gate blocks a change that introduces a new critical or high finding before it ships, so vulnerabilities are stopped at the source rather than triaged after release.
Frequently asked questions
How many tickets can one bulk action create?
Up to 500. The bulk endpoint enforces a server-side hard cap of 500 finding IDs and rejects a larger request before any vendor call. A per-finding failure is collected rather than aborting the batch, so the response returns a per-finding success or failure list.
Does a ticket closed in the vendor close the finding?
Only if you enable it. With auto-close on, a done-status ticket closes the finding directly. With it off, the default, the finding moves to retest so an analyst verifies the fix first. Either way the change arrives through the webhook or the 5-minute poller.
How is an inbound webhook verified?
Per vendor, over the raw body, before the payload is trusted. GitHub uses an HMAC-SHA256 and the other CI vendors a constant-time token or UUID. In production a missing secret rejects the hook with a 401 and the body is never read.
Are tickets isolated per tenant?
Yes. The org-wide list, per-finding activity, and bulk creation all enforce scope and access checks, so no finding from one company is ever pushed into another company vendor system.
See the integrations live
Watch PMAP open tickets, sync status and gate a pipeline from a real finding.