A vulnerability management platform is only as trustworthy as the secrets it holds. To consolidate findings from many vendors, PMAP has to store the keys to your scanners, your ITSM systems and your CI/CD pipelines in one place. That concentration of access is exactly what a security reviewer should interrogate before any platform touches production credentials.
This article walks through how PMAP protects connector credentials end to end. It covers encryption at rest, decrypt-on-demand behavior, safe connection testing, webhook secret rotation, least-privilege vendor accounts and the things PMAP deliberately never does with your secrets. Every claim here maps to the integration domain that runs these connectors. If you are evaluating PMAP as part of a vendor risk review, this is the credential security model you can verify against.
For the broader picture of how all of these connectors fit together, see the security integration layer pillar. This article goes one level deeper on the credential dimension of that layer.
Why Connector Credentials Are a Prime Target
PMAP’s integration domain is a universal connector hub. It manages the full lifecycle of every external system the platform speaks to. That includes scanner connectors across VM, DAST, SAST, SCA, network discovery and mobile, plus ITSM and ticketing platforms and CI/CD pipelines. A single integrations record stores the credentials and configuration for each connection, and the service layer dispatches vendor-specific logic through a registry of connector archetypes.
That design is what makes the platform useful. It is also what makes the credential store a high-value target. A single Nessus service account can enumerate your entire asset estate. A Jira API token can read and write tickets across projects. A GitHub app credential can reach source code and pipeline configuration. When one platform holds all of those keys, the bar for protecting them has to be higher than the bar for any individual tool.
Three properties matter most when you assess a connector credential store. First, can an attacker who reaches the database read the secrets in plaintext. Second, can a credential leak back to a user through an ordinary API response that was never meant to expose it. Third, can the account behind a connector do more than it needs to. PMAP addresses each of these, and the rest of this article takes them in turn. The OWASP Secrets Management Cheat Sheet frames these same concerns as encryption at rest, least exposure and rotation, which is a useful checklist to hold PMAP against.
Encryption at Rest: The encrypted_credentials Column
Every credential field that PMAP needs to authenticate to a vendor is encrypted before it is written to the database. In the Integration data model, all password, token and key fields live in a single column named encrypted_credentials. It is a JSONB map of every authentication field for that connector, and it is AES-encrypted at rest. Nothing in that column sits in plaintext.
This is the structural point a security reviewer cares about most. The credential is not protected only by database permissions or network controls. It is encrypted as data, so a snapshot of the database, a backup file or a leaked storage volume does not hand an attacker usable scanner and ITSM secrets. The encryption boundary travels with the data rather than depending on the perimeter around it. NIST SP 800-57 makes the case for treating key management as a first-class control, and storing all credential material behind one encrypted column is the kind of consolidation that makes key handling tractable.
Because every auth field for a connector lands in the same encrypted map, the protection is uniform across vendor types. A Qualys password, a Tenable access key, a ServiceNow token and a GitHub app secret all go through the same encryption path. There is no connector that quietly stores its secret in a softer location. That consistency matters when you have 30+ vendor types across 9 categories, because a single weak storage path anywhere in the catalog would undermine the whole store.
Decrypt on Demand With the Platform Key
Encryption at rest is only half of the story. The platform still has to use the credential to talk to the vendor, which means it has to decrypt it at some point. PMAP keeps that point as late and as narrow as possible. Credentials are decrypted on demand using the platform key, through a single internal path that resolves all credentials for a connector when an operation genuinely needs them.
The practical effect is that plaintext credentials exist only transiently in memory, at the moment a scan launch, a ticket creation or a connection test actually runs. They are not decrypted and cached in broad scope, and they are not decrypted to populate ordinary list or detail responses. The platform key is the single root of trust for this decryption, which aligns with the key management discipline NIST SP 800-57 describes. Protect that one key well and the entire credential store inherits that protection.
This decrypt-on-demand model also draws a clean line for auditors. Credential use is tied to specific operations rather than spread across the request path. If you want to reason about when a secret is in plaintext, you reason about a small set of vendor operations rather than the whole application.
Write-Only Legacy api_key Handling
The data model carries one legacy field worth calling out, because transparency about it is part of the security story. The Integration connection group includes an api_key field that is marked legacy and write-only. Write-only means the value can be set when you configure a connector but is not read back out through the API afterward.
Write-only handling is the correct posture for a credential field. You can supply a secret, but the platform does not echo it back to a client that already holds a session, which removes an easy path for a secret to leak back to a user or a logging layer. The field is legacy because the modern path stores all credential material in the encrypted JSONB map described above. Keeping the older field write-only rather than readable means there is no soft spot left behind by the migration.
Testing a Connection Without Leaking Secrets
One of the most common ways credentials leak in integration tooling is the connection test. A naive design asks the user to type a secret, sends it somewhere to be validated, and in doing so logs it, stores it prematurely or returns it in a response. PMAP’s inline connection test is built to avoid that trap.
PMAP supports testing credentials before a record is ever saved, with a dedicated inline test endpoint, and testing again after a connector exists, against the saved record. The pre-save test lets an operator confirm a credential works without persisting anything, so a typo or a wrong account never creates a half-configured integration sitting in the database. The test returns useful diagnostics rather than the secret itself. It reports latency, the vendor version, license information and warnings such as a Managed Scanner mode notice.
The “test before trust” sequence matters for two reasons. The first is operational. An operator gets immediate, specific feedback instead of saving a connector and discovering later that it never authenticated. The second is security. Because the test returns diagnostics and warnings rather than the credential, the validation step does not become a leak channel. You learn that the connection works and what the vendor reports about it, and you learn nothing that would let you exfiltrate the secret you just supplied. When a saved connector is tested successfully, the platform stamps a last-tested timestamp on the record so operators can see, at a glance, when each connection was last proven to work.
This pattern shows up across the connector catalog rather than for one privileged vendor. The same inline test is available whether you are wiring up a VM scanner, a DAST tool or an ITSM platform, which means the safe validation path is the default path, not an exception you have to remember to use.
Webhook Secrets and How They Are Stored
Credentials are not the only secret a connector holds. Inbound webhooks need shared secrets too, because that secret is what lets PMAP verify that an incoming event genuinely came from the vendor and not from an attacker spraying the public endpoint. PMAP treats webhook secrets with the same care it gives connector credentials.
For ITSM integrations, PMAP can generate, reveal, register and auto-set-up the vendor-side webhook. The secret that backs that webhook is stored as part of the connector configuration rather than left in plaintext on a sticky note in someone’s runbook. On the inbound side, that secret is what every incoming hook is checked against. Jira receivers verify a token, GitHub receivers verify an HMAC-SHA256 signature, and the other vendors verify their own token or signature scheme. The webhook secret is the anchor for all of that verification, so storing and rotating it carefully is not optional.
The lifecycle endpoints around the webhook secret are deliberate. Generation creates the secret, registration installs it on the vendor side, and an auto-setup flow can register and verify in one motion so an operator can confirm the inbound pipeline works end to end. The same discipline that governs connector credentials, namely controlled creation and controlled exposure, governs the webhook secret too.
Rotating and Revealing a Webhook Secret
Rotation is where a webhook secret either stays healthy or quietly decays. PMAP exposes an explicit regenerate operation that rotates the webhook secret, and a separate reveal operation that decrypts and returns the current secret only when an operator deliberately asks for it.
The split between regenerate and reveal is the important detail. Reveal is a deliberate, on-demand action rather than a value that rides along in every webhook detail response. The secret is decrypted and shown because an operator explicitly requested it, typically to paste it into a vendor configuration, and not because they happened to open a settings page. That keeps the secret out of routine responses and confines its plaintext appearance to an intentional reveal. Regenerate, meanwhile, lets you rotate on a schedule or in response to a suspected exposure without tearing down and rebuilding the integration. NIST SP 800-57 treats periodic key rotation as a core part of key management, and a one-call regenerate makes that practice cheap enough to actually follow.
Reveal-on-demand and regenerate together give you the two motions secret hygiene needs. You can retrieve the current value when you genuinely need it, and you can replace it whenever policy or suspicion says you should, all without exposing the secret to anyone who simply browses the connector.
Least-Privilege Vendor Accounts and Permission Checks
Encryption protects a credential at rest, but it does nothing about how much that credential can do. A scanner service account with domain-admin reach is a liability no matter how well its password is encrypted. The strongest connector posture pairs encrypted storage with a least-privilege account on the vendor side, and PMAP gives you tooling to enforce that.
For ITSM integrations, PMAP exposes a permissions check that verifies the integration account has the required vendor permissions. Instead of granting the account broad rights “to be safe” and hoping nothing is over-provisioned, an operator can scope the account narrowly, run the check and confirm it has exactly what ticket creation and status sync need and nothing more. That turns least privilege from an aspiration into something you can validate before going live.
The connection test reinforces this from another angle. Beyond confirming that authentication works, the test surfaces license information and warnings about the connector’s state, such as a Managed Scanner mode notice. Those signals tell an operator whether the account and its environment are configured the way they expect, which is part of provisioning an account that does its job without over-reaching. CIS Controls v8 places data protection and account management among its foundational controls, and a connector account that is both narrowly scoped and verifiable is exactly the kind of control those frameworks ask for.
Least privilege also limits blast radius. If a connector credential were ever exposed despite the encryption around it, an account scoped to read scan results and write tickets is a far smaller problem than an account that can administer the vendor platform. Encryption reduces the chance of exposure, and least privilege reduces the cost if exposure ever happens. You want both.
What PMAP Never Does With Vendor Severity or Secrets
A credible security model is defined as much by what a platform refuses to do as by what it implements. PMAP draws two firm lines worth naming explicitly.
The first line is about secrets in responses. Credentials are not returned in list payloads. When PMAP renders the integrations list or a connector detail view, it surfaces metadata such as the connector name, type, last-tested and last-synced timestamps, and it does not decrypt and ship the underlying secret along with it. This is the reveal-on-demand principle applied consistently. A secret is decrypted only for a specific operation that needs it or for a deliberate reveal action, never as a side effect of viewing a connector. That single rule closes off a whole class of accidental leaks through ordinary application traffic.
The second line is about trust in vendor data. PMAP never uses vendor severity directly. Each connector produces a normalized finding through its own mapper, and that normalized severity flows through a threshold filter and an optional rule-engine override before PMAP treats it as authoritative. The platform does not blindly inherit whatever rating a scanner emitted. While this is a data-governance behavior more than a credential one, it reflects the same principle that runs through PMAP’s connector design. External input is verified and normalized rather than trusted on arrival, whether that input is a finding severity or an inbound webhook signature.
Together these two refusals describe a platform that keeps secrets out of routine traffic and keeps unverified vendor claims out of authoritative state. Both are the kind of behavior a vendor risk review should be able to confirm rather than take on faith.
A Practical Checklist for Connector Hardening
If you are hardening PMAP connectors in your own environment, the platform’s behavior suggests a short, concrete checklist. Each item maps to a control PMAP already implements, so this is a configuration discipline rather than a wish list.
Start with the account. Provision each connector with a least-privilege vendor account, then run the ITSM permissions check to confirm it has exactly the access ticket operations require. Resist the urge to over-grant.
Test before you trust. Use the inline connection test before saving a new connector so a bad credential never persists, and re-test saved connectors after any vendor-side change so you catch a rotated password or a revoked token early. The last-tested timestamp gives you an audit trail of when each connection was last proven.
Treat the webhook secret as a rotating credential. Generate it through the platform, register it on the vendor, and rotate it with the regenerate operation on a schedule or after any suspected exposure. Use reveal only when you genuinely need to copy the value, and prefer constant-time, signed verification on the inbound side so an attacker cannot forge events. PMAP’s inbound receivers already enforce signature and token verification, and a production instance rejects unsigned hooks unless you have explicitly allowed them, which is a posture you should keep in place.
Finally, lean on what the platform refuses to expose. Because credentials never appear in list payloads and secrets are revealed only on deliberate request, your hardening job is mostly about provisioning narrow accounts and rotating secrets on a cadence. The storage layer is already doing the heavy lifting. For the operational steps of standing up and managing these connectors day to day, the connector management workflow walks through the setup procedure in full.
How Credential Security Fits the Integration Layer
Connector credential security is not a bolt-on feature in PMAP. It is a property of the integration domain itself, the universal connector hub that every external system flows through. The encrypted credential column, the decrypt-on-demand path, the safe connection test, the webhook secret lifecycle and the least-privilege tooling are all parts of one layer rather than separate add-ons.
That is the point worth carrying away. When a single platform consolidates scanners, ITSM systems and CI/CD pipelines, the security of that consolidation lives or dies on how it handles the secrets behind every connection. PMAP encrypts those secrets at rest, decrypts them only when an operation needs them, keeps them out of routine responses, gives you a safe way to validate connections and lets you rotate the secrets that need rotating. The security integration layer pillar covers how this hub fits alongside scan orchestration, asset sync and ticketing. This article is the credential-security chapter of that story.
If you want the full connector picture in one document, including the ITSM and CI/CD security model, read the ITSM and CI/CD integration platform datasheet. See how PMAP encrypts and isolates every connector credential before you trust it with production access.
Frequently Asked Questions
How does PMAP store scanner and ITSM credentials?
Every password, token and key field is stored in a single encrypted_credentials column on the integration record. It is a JSONB map of all authentication fields for that connector, AES-encrypted at rest. Nothing in that column is held in plaintext, so a database snapshot or backup does not expose usable secrets.
When are credentials decrypted?
Credentials are decrypted on demand using the platform key, through a single internal path that resolves them only when an operation genuinely needs them, such as launching a scan, creating a ticket or running a connection test. Plaintext credentials exist transiently in memory at that moment and are not decrypted to populate ordinary list or detail responses.
Can I test a connection without saving the credential first?
Yes. PMAP supports an inline connection test before any record is saved, so you can confirm a credential works without persisting a half-configured connector. The test returns diagnostics such as latency, vendor version, license info and warnings, and it does not return the secret itself. You can also re-test a saved connector at any time.
Are credentials ever returned in API responses?
No. Credentials are not returned in list payloads or connector detail views. Those responses carry metadata such as name, type and last-tested and last-synced timestamps. A secret is only decrypted for a specific operation that needs it or for a deliberate reveal action, never as a side effect of viewing a connector.
How do I rotate a webhook secret?
PMAP exposes an explicit regenerate operation that rotates the webhook secret without rebuilding the integration, plus a separate reveal operation that decrypts and returns the current secret only when you deliberately request it. You can rotate on a schedule or after a suspected exposure, then re-register the new secret on the vendor side.
How do I keep connector accounts least-privilege?
Provision each connector with a narrowly scoped vendor account, then use the ITSM permissions check to confirm the account has exactly the permissions ticket operations require and nothing more. Combined with encrypted storage, a least-privilege account limits the blast radius if a credential is ever exposed.
Does PMAP trust the severity a scanner reports?
No. PMAP never uses vendor severity directly. Each connector produces a normalized finding through its own mapper, and that severity flows through a threshold filter and an optional rule-engine override before PMAP treats it as authoritative. External input is verified and normalized rather than trusted on arrival.
