Integrations connect Tahr to repository providers and ticketing destinations used for setup and remediation. Configure connections here, then select them in an application's setup fields.
#Repository access
Repository access supports source-code analysis and workflows that need repository context. Public repositories may not need a connection; private repositories require a supported access method.
Available methods may include:
- GitHub App: install the app for the organization or repositories Tahr should browse.
- Bitbucket OAuth: authorize the workspace and repositories needed for assessment.
- GitLab OAuth: authorize the group or projects needed for assessment.
- Personal access token (PAT): use only when an app or OAuth connection is not suitable, with the narrowest repository permissions possible.
After connecting, browse or refresh the repository list, then select the correct workspace, namespace, organization, or project area. In the application, choose the repository URL and branch; leave the default branch unless another branch is in scope. If an application and API use different repositories, select the repository relevant to the assessment.
Set a default integration only when it is appropriate for most applications. A connection can be removed when it is no longer needed, but applications that rely on it may lose repository access and need another integration selected. Test access to the target repository after changing the provider, workspace, namespace, or permissions.
When a provider exposes more than one workspace, organization, namespace, or project, choose the one that owns the application repository rather than relying on a similarly named result. Refresh the repository list after granting access or changing a provider authorization. If the repository is not listed, confirm the app installation or OAuth scope includes it, then reconnect or update the authorization before selecting a different repository.
#Ticketing destinations
Ticketing destinations let Tahr create external work items for findings. Depending on your organization's configuration, destinations may include:
- Jira: provide the site and project details required by the connection.
- GitLab: provide the host or group/project details required by the destination.
- Azure DevOps: provide the organization and project details.
- Linear: provide the workspace and team details.
Other ticketing integrations shown for your organization can also be used.
Enter the provider's required project or team fields, then choose whether the destination applies to All apps or only Specific apps. Set a default destination only when it is the intended destination for most findings. Confirm labels, assignee behavior, and other visible field mappings with a test ticket before enabling broad use. GitLab destinations may need custom headers when the provider or network requires them; add only approved headers.
Use Specific apps when teams, projects, or data-handling rules differ. Use All apps only when every application should create work in the same provider area. Before enabling automatic ticket creation, confirm that the selected project or team accepts the issue type and required fields, and that the destination account can update an existing ticket as well as create one.
#Connection tests
Use Test connection after creating or changing a repository or ticketing connection. A passing test confirms the supplied account can reach the selected provider area, but it does not guarantee every repository or future ticket action. If it fails, check the provider URL, workspace or project selection, token scope, OAuth authorization, and whether the account can access the target resource.
For application setup, select the tested integration and verify that the intended repository, branch, project, or team is available. Re-test after rotating credentials or changing destination scope.
#Ticket status and sync
When an external issue changes but Tahr shows an old status, refresh the ticket status from the finding or ticket row. If refresh fails, confirm that the issue still exists and that the connection can access it, then update or reconnect the destination and test it again. Verify the destination project or team when changing an application's scope.
#Credential hygiene
Treat repository, OAuth, PAT, and ticketing credentials as sensitive. Prefer an app or OAuth connection with least privilege, limit PAT permissions to the required repositories or projects, remove unused connections, and rotate credentials according to your policy or immediately after exposure. Review the Security Notices for the complete integration and scope safeguards.
Never paste tokens, passwords, client secrets, or recovery codes into application context, testing instructions, comments, or finding notes.
When rotating a credential, update the connection, run its connection test, and confirm the applications or destinations that use it still work. Remove the old credential from the provider when the replacement is active.