Docs

Getting started

From an empty organisation to a prioritised queue: repositories, CI, web targets, cloud, runtime and AI agents. Every step is also a REST call.

1. Deploy

InsightFortify is an API service, a worker pool, PostgreSQL and Redis, shipped as container images. It runs on ECS, EKS or any Kubernetes in your account. Sign-in uses your identity provider over OIDC or SAML. Credentials are always stored as secret references (aws-sm://, azure-kv://, env://), never as values.

Roles: security lead (policy, targets, accounts), security analyst (triage, scans), developer (their repositories’ findings) and auditor (read-only).

2. Connect repositories

  1. Add a GitHub, GitLab, Bitbucket or Azure DevOps connection under Settings → Connections. The token is sealed and read by the worker only when a scan runs.
  2. Add repositories and set their context: internet-facing, criticality, data classes (PCI, PII, PHI) and compensating controls. Every finding on the repository inherits this context.
  3. Scan now, or set a schedule. Each scan runs Trivy, Opengrep, Gitleaks (full history), Syft, Checkov and the AI analyser.

3. Gate your CI pipelines

Create an API key, then send the scanner output from any CI system. The response says whether the build passes under your gate policy.

trivy fs --format json --list-all-pkgs -o trivy.json .
curl -sf "$FORTIFY_URL/api/ci/gitleaks-config" -H "Authorization: Bearer $FORTIFY_API_KEY" > .gitleaks.toml
gitleaks detect -c .gitleaks.toml --report-format json --report-path leaks.json --exit-code 0
jq -n --slurpfile t trivy.json --slurpfile g leaks.json \
  '{repository: env.GITHUB_REPOSITORY, branch: env.GITHUB_REF_NAME, commit: env.GITHUB_SHA,
    outputs: {trivy: $t[0], gitleaks: $g[0]}}' |
curl -sf -H "Authorization: Bearer $FORTIFY_API_KEY" -H 'content-type: application/json' \
  -d @- "$FORTIFY_URL/api/ci/scan" | jq -e '.data.gate.result == "pass"'

Accepted outputs: trivy, opengrep/semgrep/sarif, gitleaks, syft/cyclonedx, checkov, zap, prowler. Add image: "name:tag" when the outputs come from an image scan.

4. Web apps & APIs

  1. Add a web target with its base URL and, optionally, an OpenAPI spec and credentials as a secret reference.
  2. A security lead verifies it with a written attestation that the target is the organisation’s to test. The attestation goes into the audit trail. Unverified targets cannot be scanned.
  3. Run a baseline, full or api ZAP scan. Endpoints that are served but missing from the spec are raised as shadow-API findings.

5. Connect a cloud account

For AWS, create a read-only role in the account (SecurityAudit and ViewOnlyAccess), trusted by the InsightFortify task role and protected by an external ID. Register the account with the role ARN and the external ID as a secret reference. Azure (Reader) and Google Cloud (Viewer, Security Reviewer) use a service principal or service-account key, also by reference. You can also upload Prowler output and an IAM export instead of granting access.

Then mark which resources hold sensitive data. Attack paths end at those resources, and marking one re-scores the findings and re-computes the paths. Identity analysis (CIEM) currently covers AWS.

6. Stream runtime detections

Point falcosidekick’s webhook output at POST /api/runtime/falco with an API key. Events are tied to the image they came from and correlated with its open P1/P2 vulnerabilities. Response policies notify, or hand isolate, stop or label to a responder you run, such as Falco Talon or a Lambda. InsightFortify never acts on a cluster itself.

7. Put guardrails on AI agents

Repository scans already inventory models, agents and MCP servers. Add policies (deny_tool, require_approval, deny_host, max_calls_per_hour) under AI → Agents. Your agent host calls POST /api/agents/guardrails/check before each tool and reports what it ran to POST /api/agents/events.

8. Tune the policy

SettingDefaultWhat it decides
SLA daysP1 7 · P2 30 · P3 90 · P4 180Due dates and breach reporting
Actionable prioritiesP1, P2What counts as “actionable” on the dashboard
CI gateP1The worst priority a new finding may have before the build fails
AI fix suggestionsOnRemediation steps and a patch from your deployment’s model provider
Send code to the modelOffOff: the model sees the finding, the advisory and the file name, never the code
Secret historyOnScan the full git history for secrets, not just the latest tree
Secret patterns—Your own token formats, added to the default rules in the worker and in CI

API reference

Findings/api/findings, triage actions: confirm, dismiss, snooze, reopen, assign
Inventory/api/repositories, /api/artifacts, /api/components, /api/sboms
Scans & CI/api/scans, POST /api/ci/scan, /api/ci/gitleaks-config
DAST & APIs/api/web-targets (/{id}/verify, /{id}/scan), /api/apis
AI/api/ai/assets, /api/agents, /api/agents/policies, /api/agents/guardrails/check
Cloud/api/cloud/accounts, /resources, /identities, /paths, /compliance
RuntimePOST /api/runtime/falco, /api/runtime/events, /api/runtime/policies
Dashboard/api/dashboard: funnel, trend, MTTR by priority and team, SLA

Questions? Talk to us.