A finding in a dashboard is a finding waiting
Waiting for someone to open the dashboard. Waiting to be copied into a ticket. Waiting for a security engineer to translate it for the team that will actually make the change.
Findings should arrive where the work happens, in a form the person doing the work can use.
SARIF into the pull request · Tickets with severity mapped · REST API and webhooks
Overview
Integrations are usually presented as a logo grid, which is the least informative way to describe them. The number of logos tells you nothing about whether a finding ends up in front of the person who can fix it.
That is the only question worth asking here, and most security programmes answer it badly. Findings live in a security tool. Engineering lives in a repository and a ticket system. Between them sits a person doing manual translation: reading a finding, deciding who owns it, creating a ticket, rewriting the description into terms the team will act on, and following up when nothing happens.
That translation layer is where remediation time actually goes. It is invisible in every business case, it scales linearly with finding volume, and it is the reason security backlogs behave differently from engineering backlogs.
AIPTx integrations exist to remove it. A finding is created once and delivered wherever it needs to go: as a pull request annotation, as a ticket with severity already mapped, as an alert, or as structured data into whatever you have built. The record is the same in every destination, because there is only one record.
How It Works
- Step 01
Into the pipeline
GitHub Actions: run security scans on every pull request and merge to main.
GitLab CI: native pipeline support with merge request integration.
Jenkins: security gates via plugin and webhook.
Quick Scans run 15–30 minutes, which is what makes a pull-request gate viable. Configure a severity threshold and a build fails on findings above it; everything else routes to a ticket rather than blocking the merge.
Gating narrowly is what keeps a gate credible. A pipeline check that blocks on findings the team disputes gets disabled, and a disabled gate is worse than no gate because it produces false assurance.
See Continuous Security Validation - Step 02
Into the editor
SARIF export puts findings directly into the IDE and the pull request. This is the integration that matters most and gets discussed least: the developer sees the issue in the file, on the line, while the branch is still open, which is when the fix is cheapest and the context is still in their head.
SARIF is an open format rather than a proprietary one, which is what lets a single export land in an editor, a code-scanning view and a review comment without a translation step between any of them.
It is also the shortest route a finding can take. Everything else on this page moves a finding to where somebody will see it. This one moves it to where the code already is.
- Step 03
Into the backlog
Jira: automated ticket creation with severity mapping to your priority scheme.
Linear: finding synchronisation with CVSS-based priority assignment.
No copy-paste, no reformatting, and no parallel security queue that engineering never opens. The ticket carries the finding's evidence and remediation guidance, so it arrives actionable rather than as a pointer to somewhere else.
See AI Recommendations - Step 04
Into the conversation
Slack: real-time alerts on findings, plus weekly security summaries.
Microsoft Teams: adaptive cards displaying vulnerability details.
Webhooks: custom endpoint routing for scan events.
Reports can also be scheduled for automated delivery by email or Slack, which is how an executive summary arrives monthly without anyone remembering to produce it.
See Smart Reporting
Into your own systems
- REST API
- Full access to scans, findings and reporting, for custom dashboards, internal reporting or your own workflow logic.
- CLI
- Installable via pip, npm or Homebrew. Authenticate with aiptx auth login or the AIPTX_API_KEY environment variable.
aiptx scan https://app.example.com --openapi ./spec.yaml
aiptx findings list --scan-id abc123
aiptx report generate --scan-id abc123 --format pdfComing soon
These are marked as coming soon and should not be presented as available.
- Docker
- Container image vulnerability scanning.
- AWS
- EC2, S3, Lambda and IAM configuration assessment.
- Azure
- VM, storage and Active Directory security scanning.
Capabilities
CI/CD
GitHub Actions, GitLab CI, Jenkins, with pull request and merge triggers and severity-threshold build gating.
Developer tooling
SARIF export into IDE and pull request.
Issue tracking
Jira with severity mapping; Linear with CVSS-based priority assignment.
Communication
Slack real-time alerts and weekly summaries; Microsoft Teams adaptive cards; webhooks for custom routing.
Reporting delivery
Scheduled automated delivery via email or Slack; time-limited shareable links with access controls.
API
REST API with full access to scans, findings and reports.
CLI
pip, npm and Homebrew distribution; scan, findings and report commands; API key authentication.
Export formats
PDF, HTML, JSON, CSV, SARIF.
Roadmap
Coming soonDocker container scanning; AWS EC2, S3, Lambda and IAM assessment; Azure VM, storage and directory scanning.
Benefits
- 01
The translation layer disappears.
Nobody rewrites a finding into a ticket, which removes the hidden cost that scales with finding volume.
- 02
Developers see issues in context.
SARIF in the pull request means the finding arrives with the code, at the moment the change is cheapest to make.
- 03
Severity arrives already mapped.
Jira and Linear receive findings in your priority scheme rather than in ours, so triage does not restart at the ticket.
- 04
The gate stays trusted.
A narrow blocking threshold with everything else routed to tickets keeps the pipeline check credible instead of making it an obstacle.
- 05
Alerts reach the right depth of audience.
Real-time for the people who act, weekly summaries for the people who need shape rather than detail.
- 06
Custom workflows are supported rather than fought.
Full REST API and webhook access means teams with their own tooling are not forced into someone else's.
- 07
One record everywhere.
The dashboard, the report, the ticket, the SARIF annotation and the API response are views of the same finding, so nothing drifts and nothing gets re-keyed.
- 08
Remediation starts when the finding appears.
Assignments, notifications and workflow automation mean validated findings enter the delivery process immediately rather than waiting for a separate coordination step.
One finding, four destinations, no manual step.
Illustrative example. Not a customer account.
A developer opens a pull request adding a new export endpoint to a customer-facing service.
- 01
In the pipeline. GitHub Actions triggers a Quick Scan against the branch environment. It completes in nineteen minutes. One finding: the endpoint accepts a caller-supplied account identifier without verifying entitlement. Severity high.
- 02
In the pull request. SARIF places the finding on the line in the diff. The developer sees it in the review interface without leaving it, alongside the remediation example showing the vulnerable handler and the corrected one.
- 03
In the backlog. Linear receives the finding with priority assigned from the CVSS score, so it exists as tracked work even if the fix is deferred past this pull request.
- 04
In the channel. Slack posts to the team channel: finding, severity, link. The security engineer sees it, confirms from the captured request and response that it is genuine, and adds nothing further, because nothing further is needed.
- 05
The gate. The threshold is set at critical, so the build does not fail. The team chose that deliberately: high findings are tracked, criticals block. The merge is not held up, and the finding is not lost.
- 06
The fix. The developer applies the change and pushes. The next scan on the branch re-runs the exploit. It fails. The finding moves to fixed, and the retest is recorded against it.
Total manual security effort: one confirmation, taking under two minutes.
What this illustrates.
No integration in that sequence was individually remarkable. What matters is that the finding travelled from detection to verified fix without anyone rewriting it, and that the record of the whole sequence exists without anyone assembling it.
FAQ
Frequently Asked Questions
Which CI/CD systems do you support?
GitHub Actions, GitLab CI and Jenkins, with scans on pull requests and merges and a severity threshold you set to fail a build, made practical by Quick Scans at 15–30 minutes.
How do findings reach developers?
SARIF export places them in the IDE and the pull request, on the line in the diff, with the remediation example attached.
Do you create tickets automatically?
Yes — Jira receives findings as tickets with severity mapping, and Linear synchronises findings with CVSS-based priority assignment.
Can we route findings somewhere you do not integrate with?
Yes, through webhooks for scan events and a REST API with full access to scans, findings and reports, which is how several teams build their own view instead of using the dashboard.
Do you scan container images?
Not yet — Docker container image scanning is marked as coming soon.
Do you assess cloud configuration?
Not yet — AWS EC2, S3, Lambda and IAM assessment and Azure VM, storage and directory scanning are both coming soon, though internet-facing cloud-hosted assets are already discoverable and testable as network and application targets.
Can we get scheduled reports?
Yes — automated delivery via email or Slack, plus time-limited shareable links with access controls for recipients outside the workspace.
Is there a CLI?
Yes, installable via pip, npm or Homebrew, authenticated with aiptx auth login or AIPTX_API_KEY, then aiptx scan, aiptx findings list and aiptx report generate.
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
One place where the answer lives
Findings with evidence, a risk score with its breakdown, and a trend line across assessments. All in one place, for a team rather than a role.
Four audiences, four reports, one assessment
Four report templates for four audiences, five export formats, and a trend line that means something because the methodology does not change.
The fix arrives with the finding
Every finding arrives with the fix: a summary, the vulnerable and secure code side by side, and references. Not a link to a generic advisory.
Connect it to where the work happens
Wire up your repository and the next pull request gets tested, with findings in the review and tickets in the backlog.
No credit card required · REST API and webhooks included