Platform | InsightFortify

The core

Correlation, context and a score that explains itself

Correlate

One finding, many sources

Each result is fingerprinted on what it is (the rule or CVE, the package, the location), so the same issue from Trivy, the SBOM and a rescan of another branch becomes one finding with its sources listed.

Fixed findings close themselves on the next scan
Reopened findings keep their history

Context

What the scanner can’t know

Which services face the internet, which handle card data or PII, which run compensating controls, which code is test-only. You set it once per repository or cloud resource, and every finding on it inherits it.

Threat intel: CISA KEV and FIRST EPSS, re-synced every six hours
Runtime evidence from DAST and Falco

Prioritise

P1–P4, with an SLA each

A 0–10 score from named, signed factors. Priorities carry the SLA you set (7, 30, 90 days by default), and “actionable” means the priorities you choose to act on.

Every analyst decision recorded with the factors it saw
Snoozes expire; dismissals keep their reason

Code & supply chain

From the commit to the container

Connect a GitHub or GitLab organisation, or push results from CI. Each repository is scanned for vulnerable dependencies, insecure code, secrets across its full history and misconfigured infrastructure as code. Container images are scanned and tied back to the repository that builds them.

SCA — Trivy; dev-only and transitive scope lower the score
SAST — Opengrep with your rule packs, as SARIF
Secrets — Gitleaks across the whole history, plus your own patterns
IaC — Checkov on Terraform, CloudFormation, Kubernetes, Dockerfiles
SBOM — Syft CycloneDX, searchable by component and version
CI gate — pass or fail on the priorities you choose

SBOMs

The SBOM and component inventory: every package across repositories and images, its versions and known vulnerabilities

API inventory

Applications & APIs

Test what is running, not only what is written

Dynamic testing with OWASP ZAP confirms what static tools can only suspect, and a finding confirmed at runtime is scored higher. Nothing is scanned until a security lead verifies the target is the organisation’s to test, with a written attestation kept in the audit trail.

DAST — baseline and full scans on a schedule
API inventory — endpoints from code, OpenAPI specs and observed traffic
Shadow APIs — served but not in any spec, raised as OWASP API9 findings
Authentication — which documented endpoints require it, and which do not

Cloud, identities & runtime

CNAPP without a second product

Cloud posture, entitlements and runtime detections go into the same queue, are scored the same way, and are joined to the code findings to form attack paths.

CSPM

Posture

Prowler checks across AWS, Azure and Google Cloud through read-only access you grant, or uploaded results. Resources inventoried, public ones flagged, and you mark which hold sensitive data.

CIEM

Identities

Effective permissions of every user and role, folded from all their policies. Administrators, escalation routes such as iam:PassRole, blast radius, and a least-privilege policy from what was actually used.

Paths

Attack paths

Internet → vulnerable workload → over-privileged identity → sensitive data, computed in PostgreSQL and ranked as a whole. Fix any one hop and the path closes.

CWPP

Runtime

Falco detections via falcosidekick, tied to the vulnerabilities in the running image. Response policies hand isolate or stop actions to a responder you run.

A cloud account: its open findings, inventoried resources with exposure and sensitive-data flags, and recent scans — **Cloud account.** Findings, resources and scans; mark a bucket sensitive and paths re-evaluate.

Runtime: Falco detections to triage, response policies, and the live event stream — **Runtime.** A shell in a container whose image has open P1/P2 vulnerabilities ranks above one in a clean image.

Compliance

Which requirements are failing, and why

Cloud and IaC findings carry the benchmark requirements they violate. The compliance view groups open findings by framework and requirement, worst first, so the audit-prep conversation starts from the evidence.

We show failures, not a percentage passed. Not every control can be checked automatically, and a clean dashboard that implies otherwise misleads auditors and boards.

Compliance

Architecture

Deliberately boring infrastructure

A security product should be easy to run and easy to audit. InsightFortify is one API service, a worker pool, PostgreSQL and Redis. No graph database, no streaming platform, no proprietary scanning engine to trust blindly.

  sources                     InsightFortify                     people
 GitHub / GitLab  ─┐    ┌──────────────────────────┐
 CI pipelines     ─┤    │ API (FastAPI)            │ ──▶  console (React)
 Web apps / APIs  ─┼──▶ │  normalise · correlate   │ ──▶  CI gate decision
 AWS accounts     ─┤    │  score · paths · SLA     │ ──▶  REST API · webhooks
 Falco            ─┘    └──────┬───────────┬───────┘
                               │           │
                     ┌─────────▼──┐   ┌────▼──────────────┐
                     │ PostgreSQL │   │ Redis queue       │
                     │ + RLS      │   │ → scanner workers │
                     └────────────┘   └───────────────────┘
  workers: trivy · opengrep · gitleaks · syft · checkov · zap · prowler

Runs in your account — containers on ECS, EKS or any Kubernetes; code never leaves
Row-level security — tenant isolation enforced by PostgreSQL itself
Single sign-on — OIDC/SAML, with roles for leads, analysts, developers and auditors
Secrets by reference — aws-sm://, env:// — never stored as values
Bring your model — AI explanations and fixes through your own provider, and switch them off per organisation
REST API — everything in the console is an API call you can script

Every surface, one risk model