Integrations

Integrations in the sidebar has a catalogue and a list of what you have connected. A connector reads from a system you already run — an identity provider, a cloud account, a code host, an HR system — and turns what it finds into evidence, assets and test results.

Connect one

1. Browse the catalogue. Filter by category or auth type, or search. If the tool you use is not there, the catalogue has a Request an integration route — that list is how the next ones get picked.

2. Configure it. Give the connection a name — you may end up with two accounts of the same provider, and “AWS” will not be enough — then follow the setup for its auth type. OAuth connectors hand you off to the provider and come back; the rest take credentials you generate there.

3. Check the requested scopes before you approve them. They are listed on the configure screen, and they are read scopes.

4. Test the connection, then Sync now rather than waiting for the first scheduled run — it is the fastest way to find out you connected the wrong account.

Systems you host yourself

Most connectors talk to a cloud service. A few talk to a server your organization runs — Jira Data Center is one, and it is a separate catalogue entry from Jira Cloud because it connects differently.

1. Make sure Vendorica can reach the server. Vendorica connects over HTTPS from the internet, so Jira must be reachable from outside your network — usually published through a reverse proxy, with access restricted as your policy requires. A server reachable only on your internal network cannot be connected; nothing on this page changes that.

2. Use the address you open Jira at, including any path it lives under — https://jira.corp.example/jira, not just the host. It must be https.

3. Prefer a personal access token from a dedicated read-only account that can browse the projects you want evidence from. Tokens need Jira 8.14 or later; on an older server choose username and password instead.

4. If your server’s certificate comes from an internal CA, paste that CA certificate (the -----BEGIN CERTIFICATE----- block) into the form. Certificate checking is always on — there is no setting to skip it, and a private key pasted by mistake is refused rather than stored.

5. Check whether you need the egress allow-list — usually you do not. Vendorica refuses to contact private and internal addresses. If Jira’s hostname resolves to one, an administrator with Manage Integration Egress can lift that refusal for that hostname or range on the Egress allow-list card on the same page. The list does not make a server reachable, and a server with a public address needs no entry.

6. Test the connection. The result tells the cases apart: the server could not be reached or its address was refused, its certificate could not be verified, or it refused the credential — and, for a token refused by a server older than 8.14, says so.

What the allow-list never accepts

Loopback, link-local and cloud-metadata addresses, multicast and reserved ranges, ranges wider than a /8, and single-word hostnames. Those are never a server of yours; they are the platform’s own. A removed entry stops being honoured within 30 seconds.

Describe your Jira workflow

Jira’s evidence checks — vulnerability remediation SLAs and change approvals — run after every sync, for Jira Cloud and Jira Data Center alike, and by default assume Jira’s out-of-the-box vocabulary. If your workflow differs, record it in the connection’s optional Evidence fields: which issue types are vulnerabilities or changes, which field carries severity and how its values map to critical, high, medium and low, which statuses mean done, and whether an approval is a status, a label or a filled-in field. Optional Scope fields limit what the connection reads, and what the checks consider, to particular projects or a JQL filter. Blank fields keep Jira’s built-in meaning, and each result records which reading produced it. If Jira cannot be reached, the check is recorded as inconclusive rather than as a pass.

What you get

• Automated control tests. A test bound to a control reads the real configuration and records pass, fail, warning or inconclusive, with the output kept as dated evidence. See Working with controls.
• Asset inventory, ingested rather than typed — see Assets and asset groups.
• Entitlements for access reviews, pulled from the identity provider instead of a spreadsheet someone exported last month — see Access reviews.

Health, and the age of what you are looking at

Each connection has a Health panel and a Data currency reading, with a tolerated age policy: how stale the data may get before the connection is treated as failing.

Set it deliberately. The failure mode with connectors is not an error — it is silence: a connection whose credential expired keeps showing yesterday’s answer, and a control tested against stale data passes exactly as convincingly as one tested against live data.

Disconnecting keeps the evidence

Evidence already collected stays where it is, dated, because it was true when it was collected. What stops is new collection — so a control that was green on automation drifts to expiring soon and then expired rather than failing loudly. That is the correct behaviour and it is also easy to miss; check the control register after you disconnect anything.

Connectors are read-only, and the credentials are yours

A connector reads. It does not change configuration in the systems it connects to. And the credential belongs to your organization — you create it, you can revoke it, and revoking it stops collection rather than deleting anything.

Some third parties in the product are different: the AI providers, screening and background-check services are ones Vendorica holds the relationship with. The security-rating providers used by vendor monitoring are not — you credential those yourself, like any other connector here.