Every enterprise vulnerability program runs on data it does not produce itself. Findings arrive from network scanners, web application scanners, static analysis engines, software composition tools, container scanners and mobile analyzers. Tickets flow to and from an ITSM platform. Pipeline events trigger scans from a handful of CI/CD systems. Each of those connections carries a credential, and each credential is a standing risk if it is stored carelessly, never tested, or scattered across point integrations that nobody owns.
The way most teams handle this is the problem. A connector gets wired up once during a project, the API token lands in a config file or a script, and the integration becomes invisible until it breaks. There is no single place to see what is connected, whether a credential still works, or who owns the secret. Rotating a token becomes an archaeology project. This article looks at what a governed connector hub does differently, why credential handling belongs at the platform layer rather than in scattered scripts, and how PMAP treats every external system as a first-class, lifecycle-managed object.
This is a deep dive into one part of a larger picture. If you want the full view of how PMAP unifies scanners, ticketing systems and pipelines, start with the unified security integration layer. This page focuses specifically on connector and credential management, the foundation that everything else sits on.
Why a Governed Connector Hub Beats One-Off Integrations
Enterprise vulnerability management requires data from many heterogeneous tools. That requirement is not optional. You cannot correlate, triage or remediate findings you never ingested, and no single scanner sees the whole attack surface. Network scanners miss application logic. Application scanners miss infrastructure. Static analysis sees source that runtime scanners cannot reach. The practical answer is to run several tools and bring their output together, which means several connections, several credentials and several operational lifecycles to manage.
When each of those connections is a one-off engineering effort, the cost compounds. Every new tool means custom plumbing, a new place to store a secret, and a new failure mode that only the person who built it understands. Six months later that person has moved on and the integration is a black box. Multiply that by the number of scanners, ticketing systems and pipelines a mature program runs, and integration sprawl becomes a real operational liability rather than a convenience.
A governed connector hub inverts this. Instead of bespoke plumbing per tool, every external system is configured, tested and operated through one consistent surface. In PMAP this is the single place where a security engineer configures, tests and operates every external system the platform speaks to. An operator browses a vendor marketplace, fills a credential form, runs a connection test, and saves. The connector is immediately live. From there a tabbed detail page exposes the full lifecycle, so the same engineer can edit credentials, toggle the connector on or off, schedule recurring imports, monitor health, and reach the controls that are specific to that connector type. The uniformity matters because it makes the connector estate legible. You can answer the question “what are we connected to and is it healthy” without consulting tribal knowledge.
The architectural choice underneath this is what makes it sustainable. PMAP uses a type-catalog-driven design, which lets operators add new connectors without frontend changes. The platform provides a uniform operational experience regardless of vendor, so a Qualys connector and a GitHub connector are managed with the same gestures even though their internals are completely different. That consistency is the point. It is what separates a connector hub from a folder full of integration scripts.
The 30-Vendor Marketplace Across 9 Categories
PMAP ships with a marketplace of 30 vendor types grouped into 9 categories. Operators browse these as tiles with a logo, a description, and a badge that indicates whether the connector supports live sync or manual import. A free-text search runs in memory over the catalog so an engineer can find a vendor by name without scrolling through every category. The point of the marketplace is discovery without documentation. You should be able to see what is available and start configuring it in the same view.
The nine categories map directly to the shape of a modern security toolchain:
- VM and infrastructure scanners cover Nessus, Tenable Security Center, Tenable.io, Qualys VMDR, Rapid7 InsightVM and Nuclei.
- DAST covers Acunetix, Invicti and Burp Suite Enterprise for dynamic web application testing.
- SAST covers SonarQube, Checkmarx SAST, Checkmarx One and Fortify for static analysis.
- SCA and supply-chain covers Snyk Open Source, Black Duck and Sonatype Lifecycle.
- ITSM and issue tracking covers Jira, ServiceNow and ManageEngine ServiceDesk Plus.
- CI/CD covers GitHub, GitLab, Jenkins, Azure DevOps, Bamboo and Bitbucket.
- Container covers Prisma Cloud.
- Mobile covers MobSF.
- Network discovery covers Nmap and Masscan.
This breadth is what lets a single program consolidate the categories of tooling it actually runs. It also explains why a governed hub matters more as the toolchain grows. Connecting one scanner is easy anywhere. Connecting a representative slice across nine categories, each with its own credential shape and operational quirks, is where one-off integration falls apart and a catalog-driven hub pays off.
One operational detail worth knowing is that Nmap and Masscan do not appear in the marketplace vendor grid. They are network discovery tools that work through file upload rather than a live API connection, so they are reached through the asset import flow rather than configured as polling connectors. The distinction reflects how those tools actually run. Treating a file-based network scan the same as a credentialed API connector would be a leaky abstraction, and PMAP avoids it.
Connector Archetypes and Why They Matter
Not every connector behaves the same way, and pretending they do produces a cluttered, confusing interface. PMAP organizes connectors into archetypes, and the archetype controls which capabilities and detail tabs an operator sees. There are four.
A Scanner connector runs remote scans and fetches their results. These are your Nessus, Tenable, Qualys, Rapid7 and DAST connectors. Their detail page exposes scan management and asset discovery because that is what a scanner does.
A Pull-only connector pulls project-level results on a schedule rather than launching scans on demand. Software composition tools and SonarQube fit here. Their detail page is leaner, centered on the schedule, because there is no remote scan wizard to drive.
An ITSM connector creates and updates tickets and synchronizes status. Jira, ServiceNow and ManageEngine are the three. Their detail page surfaces tickets, field mapping, webhook configuration, an event log and a sync log, because ticketing has its own operational surface that a scanner does not.
An Asset source connector enumerates repositories and pipelines and fans out CI events. The CI/CD vendors fit here. Their detail page exposes webhook configuration, auto-scan settings and a CI event log.
The reason archetypes matter to the operator is focus. The detail page renders only the tabs relevant to the connector type. An engineer opening a scanner connector sees Overview, Scans and Assets, and does not see ITSM field mapping or CI webhook controls that have nothing to do with a scanner. An engineer opening an ITSM connector sees Overview, Tickets, Field Mapping, Webhook, Events and Sync Log, and does not see a scan wizard. This is not cosmetic. Showing inapplicable controls is how operators make mistakes, and archetype-aware rendering removes that whole class of confusion. The connector tells the interface what it is, and the interface adapts.
Credential Security: Encrypted at Rest
This is the part that should drive a security buyer’s evaluation, because a connector hub is only as trustworthy as its credential handling. PMAP encrypts credentials at rest. All password, token and key fields are stored AES-encrypted in a dedicated encrypted_credentials column. The platform decrypts them on demand using a platform key only when a connector actually needs to make a vendor call. They are not kept in plaintext, and they are not casually exposed.
The behavior that matters most in practice is what happens when you list connectors. Credential field values are never returned in list responses. When the integrations table loads, it shows names, types, categories, status and timestamps, but the secrets themselves do not travel in that payload. They are returned only through explicit credential endpoints when a specific operation requires them. This is the right default. A list view is the most-requested, most-cached, most-logged surface in any admin console, and it is exactly the surface where you do not want secrets to appear. Keeping credentials out of list responses closes off a whole category of accidental exposure through logs, browser history and shoulder-surfing.
This approach aligns with the broad principle that secrets should be encrypted at rest and surfaced narrowly rather than broadly. The OWASP Secrets Management Cheat Sheet and NIST SP 800-57 on key management both treat least-exposure handling of credential material as a baseline expectation, not an advanced feature. A connector hub that returns tokens in every list call is failing that baseline regardless of how strong the encryption is at rest.
Test Before You Trust
Encryption protects a credential. It does not tell you whether the credential is correct or whether the connection works. For that, PMAP provides an inline connection test, and it runs before you commit a record.
When an operator fills the credential form in the marketplace and clicks the test button, PMAP attempts the connection and returns concrete diagnostics. It reports latency, the vendor version it reached, license information, and any warnings such as a scanner running in managed mode. On success it stamps a last_tested_at timestamp so the record carries proof that the credential worked and when. On failure, the error is surfaced directly and no integration record is created or modified. That last detail is what makes the test genuinely useful. A failed test does not leave behind a broken half-configured connector that someone has to clean up later. You either confirm connectivity and save a working connector, or you see exactly why it failed and fix the input before anything is persisted.
The same test is available after save, on the saved record, so an engineer can re-verify a connector at any time. This is how you catch a rotated vendor password, an expired token or a firewall change before it silently breaks your scheduled imports. Testing before you trust turns credential management from a hope into a verifiable fact.
A Schema-Driven Type Catalog for Dynamic Wizards
The reason PMAP can support 30 vendor types without 30 hand-built forms is that the configuration wizard is schema-driven. Each vendor type is described by a type definition that declares its authentication fields and its configuration fields. The marketplace wizard reads that definition and renders the correct form dynamically. A Jira connector asks for the fields Jira needs. A Qualys connector asks for the fields Qualys needs. Neither requires a frontend change to support.
This matters for two reasons. The first is consistency for the operator. Every connector is configured through the same wizard pattern, so learning to add one connector teaches you how to add all of them. The differences between vendors live in the data, not in the experience. The second reason is velocity for the platform. Because the catalog drives rendering, adding support for a new vendor is a matter of describing it in the catalog rather than rebuilding the configuration interface. This is the practical payoff of the type-catalog-driven architecture mentioned earlier. The connector estate can grow without the configuration surface accumulating special cases.
For a buyer evaluating long-term fit, the schema-driven design is a signal about how the platform scales with your toolchain. A hub that hardcodes each integration is a hub that gates new vendors behind engineering work. A catalog-driven hub treats new vendors as configuration, which is the difference between waiting a release cycle and adding a connector today.
Enable, Disable and Rotate Without Losing Config
Connectors are not always-on. A scanner goes into maintenance. A token needs rotating. A vendor contract lapses and you want to pause imports without throwing away the whole configuration. PMAP handles this with an active and inactive state rather than forcing a delete.
Toggling a connector inactive sets its is_active field to false, and that flag controls scheduler and poller inclusion. An inactive connector is excluded from the background scheduler and the ITSM ticket poller, so it stops doing work, but the record and its credentials are preserved. When you toggle it active again, it resumes with the same configuration intact. There is no reconfiguration, no re-entry of credentials, no rebuilding of field mappings. This is the difference between pausing and deleting, and it is the right model for connectors that come and go with operational cycles.
Credential rotation lives in the same place. The edit modal updates credentials in place on an existing connector, so when a vendor token rotates you change it on the record you already have rather than deleting and recreating the connector. Combined with the inline test, rotation becomes a controlled, verifiable operation. Update the credential, test it, confirm the green result, and the connector keeps running under the same identity. Regular credential rotation is a control that frameworks like CIS Controls v8 Control 3 on data protection expect, and a connector hub that makes rotation painless is a hub that makes the control achievable rather than aspirational.
Connection Health at a Glance
A connector that worked last month is not necessarily a connector that works now. Vendor credentials expire, permissions change, and network paths break. PMAP surfaces connection health so an operator can see the state of the estate without testing every connector by hand.
Two timestamps carry most of the signal. The last_tested_at field records when a credential was last confirmed working, and last_sync_at records when the connector last successfully exchanged data. On the integrations list, per-row badges show test and sync results so a stale or failing connector stands out. For ITSM connectors specifically, a permission-check panel verifies whether the integration account actually has the vendor-side permissions required to create tickets. That check is valuable because ticket creation fails for permission reasons that are easy to miss until the first bulk ticket run fails halfway through. Surfacing the permission state before that happens turns a runtime failure into a configuration step.
Health visibility is what lets a connector hub be operated rather than just configured. Configuration is a one-time act. Operation is continuous, and it depends on being able to see which connectors are healthy, which are stale, and which need attention, all from one view.
Orphan Adoption on Connector Creation
There is a subtle gap in most scanner integrations. You connect a scanner that already has a history of scans on the vendor side, and the integration only knows about scans that run after you connected it. The earlier scans are invisible to your platform even though they exist on the vendor.
PMAP closes this gap with orphan adoption. When a scanner connector is created, an asynchronous sweep runs immediately and matches pre-existing vendor scans to PMAP, adopting them without waiting for the next scheduler tick. The background scheduler, which ticks on its own cycle, is the safety net that catches anything the immediate sweep misses, but the immediate sweep means a freshly connected scanner is useful right away rather than only going forward. This is the kind of behavior that does not appear in a feature checklist but shows up the moment you connect a real scanner with real history. A connector hub that ignores the vendor’s existing state is a connector hub that starts every relationship by losing data.
Webhook Secret Management Across Connector Types
Some connectors do not just send requests to a vendor. They receive inbound calls from one. ITSM connectors receive webhook events when a ticket changes on the vendor side. CI/CD connectors receive webhook events when a pipeline runs. Those inbound channels need a shared secret, and that secret needs a lifecycle of its own.
PMAP manages webhook secrets from the connector detail page. For ITSM and CI/CD connectors, an operator can generate a secret, reveal it on demand, rotate it, register it on the vendor side, and use an auto-setup path that registers and verifies in one step. For ITSM connectors, a health endpoint verifies that the inbound pipeline actually works end to end, so an operator is not left guessing whether the vendor will reach the platform. The reveal-on-demand model is deliberate. A secret is displayed once on generation and revealed only when explicitly requested afterward, rather than being shown by default in the interface. That keeps the secret out of casual view while still making it retrievable when you genuinely need it for vendor-side configuration.
This is where credential security and inbound integration meet. An inbound webhook with a weak or unmanaged secret is an open door. The webhook secret tooling on the connector page is what keeps that door governed rather than propped open with a value nobody remembers setting.
Operational Realities: Demo Mode and Bulk Delete
Two smaller capabilities round out the lifecycle, and both reflect how connector estates are actually run rather than how they look in a diagram.
The first is demo mode. A platform administrator can preview connectors with canned data instead of live credentials, which is useful for demonstrating the platform without exposing real vendor connections. In PMAP this short-circuits connector resolution to demo data for Qualys and Rapid7, and it is visible in the marketplace only to a platform administrator when the demo mode platform flag is enabled. A regular user never sees the demo category regardless of the flag. The gating matters because demo data should never leak into a working operator’s view, and the access control ensures it does not.
The second is bulk connector delete. The list page supports multi-select with a confirmation dialog, so an operator can remove several stale connectors in one operation rather than deleting them one at a time. Estates accumulate dead connectors over time as tools are retired and projects end. Bulk delete is the housekeeping that keeps the list honest.
How PMAP Adds New Connectors Without Engineering
The thread running through everything above is the type-catalog-driven architecture. It is the reason the marketplace can list 30 vendors, the reason the configuration wizard renders the right form for each one, the reason archetypes route operators to the right controls, and the reason the platform can grow its connector coverage without rebuilding its interface.
This is the strategic difference between a connector hub and a pile of integration scripts. Scripts hardcode each vendor, so each new tool is a project. A catalog-driven hub describes each vendor as data, so each new tool is a configuration. For a team standing up an enterprise vulnerability program, that distinction determines whether your platform keeps pace with your toolchain or holds it back. The connector layer is the foundation the rest of the program stands on. Get the credential handling, the testing, the health visibility and the lifecycle right at that layer, and everything downstream becomes more trustworthy by default.
If you want to see this in practice, the most common first connector is an ITSM integration. Our step-by-step walkthrough on how to connect Jira and push findings as tickets shows the configuration, test and save flow end to end. For where ITSM and CI/CD connectors go next, see our deep dives on ITSM two-way sync with Jira and ServiceNow and pipeline-triggered scans with CI/CD and webhooks. For a closer look at the marketplace catalog and the credential security model specifically, see connector credential security and the 30-vendor marketplace.
Frequently Asked Questions
How are connector credentials stored in PMAP?
All password, token and key fields are AES-encrypted at rest in a dedicated encrypted_credentials column. The platform decrypts them on demand using a platform key only when a connector needs to make a vendor call. Credential values are never returned in list responses, so secrets do not travel in the integrations table payload. They are accessible only through explicit credential endpoints when a specific operation requires them.
Can I test a connector before saving it?
Yes. PMAP provides an inline connection test that runs before you commit a record. When you fill the credential form and click test, the platform returns latency, the vendor version it reached, license information and any warnings. On success it stamps a last-tested timestamp. On failure the error is shown directly and no integration record is created or modified, so a failed test never leaves behind a broken half-configured connector. The same test is also available on a saved connector so you can re-verify it at any time.
How many vendors and categories does PMAP support?
PMAP ships with a marketplace of 30 vendor types grouped into 9 categories: VM and infrastructure, DAST, SAST, SCA and supply-chain, ITSM and issue tracking, CI/CD, container, mobile, and network discovery. The marketplace renders each vendor as a tile with a logo, description and a sync or manual badge, with in-memory free-text search across the catalog.
What are connector archetypes and why do they matter?
Connectors fall into four archetypes: Scanner, Pull-only, ITSM and Asset source. The archetype controls which detail tabs an operator sees, so a scanner connector shows scan and asset controls while an ITSM connector shows tickets, field mapping and webhook controls. This keeps inapplicable controls off the screen, which removes a common source of operator error. The connector tells the interface what it is, and the interface renders only the relevant tabs.
Can I disable a connector without losing its configuration?
Yes. Toggling a connector inactive sets its active flag to false, which excludes it from the background scheduler and the ITSM ticket poller. The connector stops doing work, but the record and its credentials are preserved. Toggling it active again resumes the connector with its full configuration intact, so there is no reconfiguration or re-entry of credentials. This is how you pause imports during maintenance or rotate credentials without rebuilding the connector.
How does PMAP handle scans that already existed before I connected a scanner?
When a scanner connector is created, an asynchronous orphan-adoption sweep runs immediately and matches pre-existing vendor scans to PMAP, adopting them without waiting for the next scheduler tick. The five-minute background scheduler acts as the safety net for anything the immediate sweep misses. The result is that a newly connected scanner is useful right away rather than only tracking scans that run after the connection date.
How are inbound webhook secrets managed?
For ITSM and CI/CD connectors, the connector detail page lets an operator generate, reveal, rotate, register and auto-setup webhook secrets. ITSM connectors also expose a health endpoint that verifies the inbound pipeline works end to end. Secrets follow a reveal-on-demand model, shown once on generation and revealed only when explicitly requested afterward, so they stay out of casual view while remaining retrievable for vendor-side configuration.
