Route findings into the tools remediation owners already live in, keep ticket and finding in step both ways, and gate every merge on the vulnerabilities a change introduces.
Security teams produce findings, but remediation owners and developers act somewhere else. Owners live in Jira, ServiceNow, or ManageEngine; developers live in GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket. This surface of the integration domain bridges the governed finding model to both worlds.
Ticket creation turns a finding into a properly prioritised ticket, one at a time or up to 500 at once, governed by operator-defined mapping rules. A bidirectional channel keeps the ticket and finding in step: an inbound webhook push plus a 5-minute reconciling poll, so a status change a remediation owner makes reflects back without the security team chasing anyone.
A finding that nobody works is just a row in a database. Remediation happens in ticketing tools and velocity happens in code review, and neither audience adopts the security console as a daily driver.
At a glance
- Backend domain: internal/integration (Go modular monolith; ITSM and CI capability handlers)
- ITSM connectors: Jira, ServiceNow, ManageEngine ServiceDesk Plus (ITSMConnector archetype)
- CI/CD connectors: GitHub, GitLab, Jenkins, Azure DevOps, Bamboo, Bitbucket (AssetSourceConnector)
- Bulk ticketing: Single create plus bulk create with a server-side hard cap of 500 findings
- Bidirectional sync: Inbound webhook push plus a 5-minute background TicketPoller pull
- Webhook security: Per-vendor HMAC-SHA256 or constant-time token on every inbound hook
- Multi-tenancy: ScopeFilter and VerifyFindingsAccess on every ticket list, activity, and bulk create
How it works
Meet each audience in the tool they already use. Findings flow out to ITSM tickets and pipeline gates, status flows back into the governed finding, and every inbound message is verified and tenant-scoped before it is trusted.
Ticket creation escalates a finding into an enterprise ITSM platform with three creation modes: a standalone ticket, a Jira subtask under a parent, or a standalone ticket linked to a parent. Fields are driven by persistent per-integration mapping rules, evaluated before every creation rather than hand-picked per ticket.
Push delivery can fail silently, so PMAP keeps a finding and its ticket in step through two complementary channels. On the pipeline side, a verified CI event is routed by an orchestrator that is a router, not a scanner, fanning the change out to the configured scan targets and the merge gate.
Key capabilities
- The auto-scan orchestrator. Once a CI event is verified and normalized, the orchestrator reads the auto_scan config, applies the branch filter, and fans the event out to pipeline triggers and SAST or SCA targets, always emitting a runbook trigger so the runbook engine reacts even when auto-scan is off.
- Branch filter and budget. The branch filter is an allow list: empty matches all, a literal matches exactly, a prefix and beneath, or a single segment. A non-matching event is acknowledged with 200 but produces no scan, so a feature branch does not spend scanner budget when the policy targets protected branches.
- The pull-request gate. When a CI-triggered scan completes for a change carrying a pull-request number, PMAP posts a security-summary comment and a commit-check status. The gate evaluates only the new findings the change introduced against block_on_new and warn_on_new, defaulting to block on critical and high.
- One verified status, many readers. A ticket closed in Jira routes the finding to retest or closed, posts a note to the activity feed, and feeds the analytics SLA metrics, all from the same governed record rather than re-entry. The ticket workbench filters across every integration by SLA breach state.
Use cases
- Gate merges on new criticals. A security engineer wires a GitHub connector, sets the branch filter to the protected branches, points it at the SAST and SCA targets, and leaves block_on_new at critical and high. A pull request that introduces a new critical receives a failure commit status, and branch protection blocks the merge until it is resolved.
- Escalate an import in one action. After a weekly import, a SOC lead filters the new findings, runs the read-only ticket-link summary to skip anything already ticketed, and bulk-creates tickets in one call. The 500-cap guard keeps the batch within the vendor rate budget, and the per-finding result list shows exactly which findings were ticketed.
- Keep findings and tickets aligned. A vulnerability manager links findings to ServiceNow and lets the bidirectional channel do the rest. When an owner moves a ticket to a done status, the webhook reflects it and, because auto_close_on_resolve is false, the finding moves to retest. The 5-minute poller reconciles any webhook the vendor dropped.
Findings out to tickets and gates, verified status back into one governed record.
