Skip to content
Fluid Attacks Development Portal

Repositories Synchronization

Schedulers

There are periodic and automatically triggered jobs (schedules) involved in the synchronization. They are the starting point for the automatic synchronization of repositories en masse. Bear in mind that there are discrete user actions that can trigger the process on a single repository, like requesting a reattack, but they are outside the scope of this section:

  1. clone_groups_roots: enqueues a cloning task for each active Git root in of all of the active groups.

    For the Git root to be taken into account, its associated credentials have to be valid and the version stored in the S3 mirror has to be different from the one in the git host server.

    Each cloning task includes the following steps: the cloning itself, refresh of the ToE surface for lines, rebase of vulnerabilities and finalizes enqueuing a machine execution.

    Period: each 2 hours, on working days.

  2. clone_groups_that_have_not_cloned: enqueues a cloning task on Git roots that haven’t been cloned in more than 3 days.

    No validation on its associated credentials or the S3 mirror is performed, as we want to force an update based on the time since the last synchronization.

    Period: twice per day, on working days.

  3. machine_queue_sast_sca: directly enqueues a machine execution for all active Git roots, with an available S3 mirror, in all active groups.

    It’s aimed to ensure that machine runs on all available repositories at least once per week.

    This machine execution covers the SAST and SCA techniques. CSPM and DAST techniques are covered by the schedules machine_queue_cspm and machine_queue_dast respectively, which target the registered root environments.

    Period: weekly, on saturdays.

  4. machine_queue_re_attacks: for each active group, finds all vulnerabilities that still have a requested reattack and enqueues a grouped machine execution for all roots containing these vulnerabilities.

    It’s aimed to ensure that machine processes all pending reattacks.

    Period: twice per day, on working days.

Batch Actions

Each step on the synchronization process can be enqueued directly and on-demand through Batch Actions (jobs) in predefined job queues. They can run on the specified Git roots, in the same group, and depending on the Action you need to provide the root ids or their associated nicknames. Please refer to its Action Additional Info field and json schema for more details.

In this section, we describe the Actions related to the synchronization:

  1. clone_roots: clones the specified Git roots of a group. It includes the sequential tasks for refreshing the ToE and rebase of vulnerabilities.

    Enqueueing the machine execution at the end is optional.

  2. move_roots: when a Git root is migrated from one group to another, a synchronization is triggered for both roots: the newly created and the now deactivated root.

  3. rebase: direct rebase of vulnerabilities. It doesn’t enqueue any machine execution.

  4. refresh_toe_inputs and refresh_toe_ports: process the related ToE. It doesn’t enqueue any additional Action.

  5. refresh_toe_lines: process the related ToE. It doesn’t enqueue any machine execution. For active Git roots, it also includes the rebase of vulnerabilities.