Deployment and data

02 What crosses the boundary

What crosses 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.

License: on activation, the activation key and an identifier generated for the instance go out; on the periodic check, every 4 minutes, the instance identifier, the installation identifier and a single-use number. No machine name or environment data goes with it. The license server sees the source IP address and records it in its access log. With a license imported as a file, there is no call to the license server.

Also outbound, by default: a download of the public EPSS (FIRST) and KEV (CISA) catalogs. Both files are downloaded in full from epss.empiricalsecurity.com (which hosts the FIRST file) and from www.cisa.gov and matched locally: no CVE, finding or data of yours goes with it. One installation setting turns the downloads off, and EPSS and KEV then come only from your GitLab.

Billing check: not a connection, but a file an installation administrator generates and you decide to hand to Dooper, by e-mail if you prefer. Today the administrator generates the file through the FFAST GraphQL API; the screen to generate it is on the way. The file carries counts and the reading details: the number of seats in the reading, the total number of people and the people per role, with roles held by one or two people suppressed; the month and day of the reading, the source of the number, what was read in GitLab (the top-level group or the instance), the band ceiling and the headroom below it; and the date the file was generated. No name, username, e-mail or GitLab person identifier goes in it. These are two different numbers: the seats and the total number of people. When the seat number comes from GitLab, the total number of people is a local reconstruction and may differ from it. The reading measures usage, not the invoice amount: the contracted band is what is billed, set by the 12-month forecast you declare, and the closing reading goes into sizing the renewal. If you contest the reading used to point out an overage at renewal, which you can do up to 90 days after the end of the contract year, you generate the pseudonymized list for that reading: one pseudonym per person, computed with a secret that stays in your installation and is not sent. The list is shown in a meeting, and Dooper keeps no copy.

FFAST transmits none of these outside the customer perimeter: findings, code snippets, repository names, contributor identifiers, metrics, reports.

04 Personal data

Personal data

The product processes operational metadata from your GitLab, such as commit authorship and remediation ownership. Because execution happens entirely in your environment, that processing is under your control: Dooper has no technical access to the installation or to the data. It receives only what you decide to hand over: the billing check file, with counts and the reading details. If you contest the reading used to point out an overage at renewal, the pseudonymized list for that reading is shown in a meeting, with no copy to Dooper.

For vendor assessment, architecture documentation, the permission matrix and test results are provided under a confidentiality agreement.