ASPM · Compliance Intelligence · GitLab-native

Priority, cost and evidence from the scanners your GitLab already runs.

FFAST reads the output of SAST, DAST, Container Scanning, Dependency Scanning and Secret Detection, ranks what matters by your business risk, computes the price of each cause from your team’s payroll and your business context, and links a finding to the regulatory control when its weakness (CWE) has a match.

Request a demo How it’s deployed

01 The data path

Follow one finding.

  1. 01 Scanners

    Three alerts. One problem.

    Dependency Scanning finds the same CVE in two manifests of the customer onboarding service. Container Scanning finds it again in the published image. In GitLab, that is three alerts.

    CVE-2025-24813 · tomcat-embed-core 10.1.34 · remote code execution via partial PUT

    dependency_scanning services/cadastro/pom.xml critical

    dependency_scanning services/documentos/pom.xml critical

    container_scanning api-cadastro:2.14 critical

  2. 02 Finding

    One root cause.

    FFAST normalizes the three reports and groups them by project and CVE: one upgrade fixes all three. The queue counts causes, not alerts.

    3 1

    cause: api-cadastro · CVE-2025-24813

    representative: the oldest detection, 47 days ago

  3. 03 CRISP

    Risk 83 out of 100.

    Technical severity is multiplied by your business context. Here the service is public, handles financial personal data (the product’s highest class), and the CVE is in CISA’s Known Exploited Vulnerabilities catalog.

    • critical severity 10
    • public internet × 2.0
    • financial personal data × 2.0
    • actively exploited (KEV) × 2.0
    • open for 47 days × 1.5
    • = 120

    83 / 100

  4. 04 Queue

    First in the queue.

    Remediation order comes from the score, not from CVSS. The clock is your own SLA policy: 3 days for critical.

    #1

    critical SLA · 3 days

    breached 44 days ago

  5. 05 CREX

    The price of this cause.

    Your team’s payroll and the hours to fix it, multiplied by the context of this cause: public service, financial personal data, active exploitation and 47 days open. The savings from fixing before deploy come from this same number.

    $316,875

    $8,450 80 h × $105.63/h

    × 37.5 the context of this cause

  6. 06 Control

    Posture on the right control.

    The weakness behind the cause (CWE) has a match in the knowledge base, so the cause is linked to the controls it breaks. Each control’s posture comes from scanner coverage and open findings: once the fix closes the cause, the control stops counting it.

    • ISO/IEC 27001:2022 A.8.8 Management of technical vulnerabilities
    • LGPD (Brazil) art. 46 Security measures
    • posture coverage Dependency and Container Scanning · 1 open cause

  1. CVE-2025-24813 · tomcat-embed-core 10.1.34 · remote code execution via partial PUT

    dependency_scanning services/cadastro/pom.xml critical

    dependency_scanning services/documentos/pom.xml critical

    container_scanning api-cadastro:2.14 critical

  2. 3 1

    cause: api-cadastro · CVE-2025-24813

    representative: the oldest detection, 47 days ago

    • critical severity 10
    • public internet × 2.0
    • financial personal data × 2.0
    • actively exploited (KEV) × 2.0
    • open for 47 days × 1.5
    • = 120

    83 / 100

  4. #1

    critical SLA · 3 days

    breached 44 days ago

  5. $316,875

    $8,450 80 h × $105.63/h

    × 37.5 the context of this cause

    • ISO/IEC 27001:2022 A.8.8 Management of technical vulnerabilities
    • LGPD (Brazil) art. 46 Security measures
    • posture coverage Dependency and Container Scanning · 1 open cause

Illustrative example. The factors, weights and formulas are the product’s own.

FFAST is not a scanner.

It does not repeat what your pipeline already does. It consumes the output of GitLab’s native scanners and answers the question that comes next: what to fix first, what it costs to fix it, and what that means under the standard you are audited against.

02 Four pillars

Four pillars

Each pillar states what goes in and what comes out. The weights are the product’s own; each project’s context is declared by you or presumed, and its source is on display.

CRISP

Contextual Risk Index for Security Prioritization

Orders the remediation queue by real risk, not nominal severity.

In

  • Technical severity of the finding
  • Network exposure of the project
  • Class of data the project handles
  • Observed exploitation (EPSS, KEV) or a leaked secret
  • Age of the open finding

Out

A 0–100 index per finding that sets the queue order.

CREX

Contextual Risk EXposure

The price, in currency, of each cause: your team’s payroll and the hours to fix it, multiplied by your business context. It is the number the CEO and the board understand.

In

  • Your team’s payroll by profile and the fixing hours by severity
  • The context your teams declare: project exposure, data type, exploitation (EPSS and KEV), age and industry
  • NIST and IBM, alongside and in smaller print, as market references

Out

The CREX of each cause and of the backlog: what it takes to fix while still in development and what it will cost if it reaches production. Shift-left savings are computed on the same number.

DORA

Delivery metrics

GitLab’s DORA, computed the way GitLab computes it, and the canonical DORA next to it.

In

  • GitLab’s own DORA, read from its API and shown without reinterpretation
  • Pipelines, deployments and incidents from your GitLab, for the canonical computation
  • Sliced by group, project and period

Out

The four metrics in both readings, side by side. In the canonical one, lead time runs from the first commit of the change to the production deploy, where GitLab starts at the merge; change failure rate counts a deploy that carries a declared incident or a signal of its own (failure, rollback, critical finding within 72 hours). The source of each signal is exposed.

GRC and DPO

Compliance intelligence

Tells the DPO and engineering which article of law each finding breaches, and where it gets fixed.

In

  • Open findings and scanner coverage in each project
  • A base of 137 frameworks and 2,867 controls, one per article, including LGPD, BACEN and CMN
  • The declared sector of each project: a sector rule only counts where it applies
  • Software license inventory

Out

For each finding, the obligation it breaches (for example, LGPD art. 46) and whether it is fixed in the pipeline or needs process and attestation. The same data in two views: the legal one, by law and article, with the article text and the affected systems; and the technical one, with the findings, the remediation task and dismissal with a reason. Risk acceptance with a deadline, control attestation, posture per framework and a PDF dossier of the breached obligations.

Coming next

  • The remediation instructions for each article, by sector and by layer: what changes in the pipeline and what changes in the organization
  • Data protection impact assessment (DPIA) built from the affected systems
  • Record of processing activities (RoPA)
  • Incident notification to the ANPD and data subject requests

03 Regulatory base

137

regulatory frameworks

2,867

controls in the knowledge base

3

declared cost models

5

GitLab scanners consumed

04 Runs inside your perimeter

Runs inside your perimeter

Not multi-tenant SaaS. One delivery, in your environment, against your database.

Deployment details

  • One container on your infrastructure. Data is created and stays on your side of the boundary.
  • FFAST sends no customer data outside your environment. Besides your own GitLab, the outbound connections are: the license check, every 4 minutes, with the instance and installation identifiers (the license server sees the source IP address and records it in its access log); and, by default, the download of the public EPSS and KEV catalogs, which can be turned off. With enrichment turned off and a file-based license, the only outbound connection is to your GitLab. The billing check file, which the customer decides to hand to Dooper, carries counts and the reading details (month and day, source, GitLab group read, ceiling and headroom) and the generation date; no person; the pseudonymized contest list is only shown in a meeting, with no copy.
  • FFAST transmits no finding, code snippet, repository name or contributor data outside your infrastructure.
  • Authentication through your own GitLab, self-hosted or SaaS.

05 What cannot be measured is declared, not invented

What cannot be measured is declared, not invented

A metric with no source signal is a pretty number and a wrong decision. When the environment does not provide the data, FFAST says so — and shows what is missing to start providing it. The same holds for cost: the financial number never appears without the model that produced it.

Want to see it running on your GitLab?

The conversation starts technical: 45 minutes on your group structure, the scanners already running and the size of the backlog.

Request a demo