Integrations
GitLab
Cloud

GitLab Cloud Integration

GitLab Cloud integration with Flyingduck allows you to display an inventory of Projects within the organization and identify misconfigurations. It also lists out inventory of libraries, identify associated vulnerabilities, and detect hard-coded sensitive information in the code for each commit that is performed. Additionally, you can perform Static Application Security Testing (SAST), which scans for security vulnerabilities in the source code.

This is an overview of integrating Flyingduck with your GitLab projects. To connect GitLab and receive detailed insights at every commit, follow the steps below:

Basic Requirements -->

Access the Integration

  1. Sign in to the Flyingduck portal as an administrator.
  2. Navigate to Administration → Integrations.
  3. Locate GitLab and click Integrate.

GitLab Integration

App Integration

Scan Configuration

Choose how you want Flyingduck to scan your GitLab Projects:

  • Direct cloud access
  • Self-hosted Runner

Select Cloud Mode if you want your code to be scanned directly in Flyingduck’s cloud platform. In this mode, the projects code is accessed by Flyingduck to perform the scans, and the results are displayed securely in the Flyingduck dashboard. scan configuration

With cloud mode you will get defualt PR scan feature. we will provide flyingduck's PR checks during the pull request. if we find any issues with the changes in your PR we fail the check.

Selecting Cloud Mode will take you to the PR Scan Configuration section. We provide the flexibility to choose whether to enable default PR scans or not. Based on your preference, select the appropriate option during setup.

If you enable PR scans for the entire organization, all integrated projects will have PR scanning enabled by default. Otherwise, no projects will have PR scans enabled initially.

You can always modify the PR scan configuration later, even after integration. Additionally, it is possible to trigger PR scans only for specific projects by selecting “Disable” during setup and configuring PR scan settings individually for each projects afterwards.

After selecting your preferred option, click Continue to proceed. PR configuration

Integrate with GitLab

To begin the integration, click the Connect GitLab button. This action redirects you to GitLab’s authentication page. For a seamless flow, make sure you are already logged in to your GitLab account before starting. PR configuration Once redirected, GitLab will display a permissions request screen for the Flyingduck Code Scanner application. Review the access permissions and click Authorize flyingduck-code-scanner to approve the integration. After authorization, GitLab will redirect you back to Flyingduck, and the connection will be successfully established. Authorize

Upon authorization, the system redirects back to Flyingduck and displays all GitLab groups associated with the authenticated account. Only one group can be integrated at a time. Select the required group and choose Next to proceed.

PR configuration After a group is selected, the interface displays all available projects associated with that group. Any number of projects can be selected from the list. The selected projects are then integrated with Flyingduck. PR configuration After the integration is completed successfully, an "Integration Successful" confirmation message is displayed on the interface. Select Continue to proceed to the next step. PR configuration

Branch Configuration

Branches configuration allows you to manage and customize monitored bitbucket branches for automated scanning.

You can configure branches into two main stages: Production and Release. Branches such as Release, Staging, or Testing can be included in the Release stage. All other branches will be considered feature branches by default.

PR configuration

This configuration allows you to prioritize important branches and gain better visibility into your development workflow. Flyingduck will scan the configured branches and track all unique issues found. With this setup, you can monitor how many issues are present at each stage and how many are resolved before reaching production.

You can configure continuous scanning for your projects in two ways:

  • Enable for all branches – scans all branches continuously.
  • Scan for active branches – scans only the branches you specify.

Select the option that best fits your workflow, then click Continue. After saving, a confirmation message saying "Branches saved successfully" will appear.

Branch configuration

Jira Integration (Optional)

Flyingduck can be integrated with Jira to streamline issue tracking by automatically creating and linking issues discovered during scans to your Jira project boards. This ensures efficient management and resolution of vulnerabilities.

Setup Steps:

  1. Enter your Jira domain (e.g., https://your-org.atlassian.net).
  2. Enter the email ID associated with your Jira API token.
  3. Enter your Jira API token.
  4. Click Test Authentication to verify the connection, or Skip to configure it later.

jira integration

Once successfully authenticated, Flyingduck will seamlessly link detected issues to your Jira boards, allowing you to monitor, prioritize, and resolve them directly within Jira.

CI/CD Workflow Integration (Optional)

Flyingduck can be integrated into your CI/CD pipelines to automatically scan code during pipeline execution. This ensures that security issues are detected early in the development process, preventing potential vulnerabilities from reaching production.

Setup Instructions:

  1. Add the Flyingduck scanner to your CI/CD configuration file.
  2. Configure the scanner to run before your build step.
  3. Optionally, set the scanner to fail the build if any security issues are detected.

workflow

API Key configuration -->Workflow configuration -->

Webhook Configuration

To enable continuous scanning, configure a webhook in GitLab. A webhook can be applied either at the Group level or at the individual project level:

  • Group-level webhook → applies automatically to all projects within the group.
  • Project-level webhook → applies only to the selected project.

Recommendation: Configure at the Group level for centralized management and to automatically include all projects under that group.

  1. Navigate to either:

    • Group Settings → Webhooks (applies to all projects within the group) or
    • Project Settings → Webhooks (applies only to that specific project)

  2. Create a new webhook and use the following details:

FieldValue
URLhttps://api.flyingduck.io/listeners/v1/gitlab
Secret TokenPaste the generated FD_API_KEY from Flyingduck
SSL VerificationEnabled
  1. Under Trigger Events, enable:
  • Push events
  • Merge request events
  • Issue events
  • Project events
  • Subgroup events (only visible at group-level webhook)
  1. Save the webhook.

Behavior After Setup

  • Every new push, merge request, or repository event triggers Flyingduck to perform a scan.
  • If configured at the Group level, all repositories under that group will automatically use this webhook.

Runner App Integration

Scan Configuration

Choose how you want Flyingduck to scan your GitLab projects:

  • Direct cloud access
  • Self-hosted Runner

scan configuration

choose Runner Mode if you prefer to set up a dedicated VM and execute the scans within your own environment.

Runner mode gives you the flexibility to choose how Flyingduck scans your Gitlab projects. You can launch a VM on either a public cloud or on-premise infrastructure and configure it as a dedicated runner. This enables unlimited on-demand or scheduled scans or continuous automated scans, optimizes pipeline efficiency, and offers significant cost savings.

Select your preferred environment for runner deployment—AWS, Azure, or your own local VM.

Runner configuration

Select VM Environment

Runner Mode: AWS Setup

To configure your self-hosted Flyingduck runner using AWS, follow these steps:

1. Retrieve Your API Key

Your runner requires an API key for configuration.

  • Copy the displayed API key from the "Your API Key" section.
  • Use the copy button for convenience.

2. Launch Self-Hosted Runner for AWS

Set up the necessary IAM role and infrastructure using AWS CloudFormation:

  • Click the "Launch Stack" button to automatically open the AWS Console and create the Flyingduck role ARN.
  • Once the stack is launched, AWS will generate a new role ARN for the runner.

3. Add Flyingduck Role ARN

  • Pass the created ARN in the input field provided.

This authenticates your AWS environment for Flyingduck runner operations.

4. Continue Setup

  • Click Continue to proceed to the next step.
  • If you need to revise, use the Back button.

aws

Tip:
Ensure your AWS account has permissions to launch CloudFormation stacks and create IAM roles.

Integrate with GitLab

To begin the integration, click the Connect GitLab button. This action redirects you to GitLab’s authentication page. For a seamless flow, make sure you are already logged in to your GitLab account before starting. PR configuration Once redirected, GitLab will display a permissions request screen for the Flyingduck Code Scanner application. Review the access permissions and click Authorize flyingduck-code-scanner to approve the integration. After authorization, GitLab will redirect you back to Flyingduck, and the connection will be successfully established. Authorize Upon authorization, the system redirects back to Flyingduck and displays all GitLab groups associated with the authenticated account. Only one group can be integrated at a time. Select the required group and choose Next to proceed.

PR configuration After a group is selected, the interface displays all available projects associated with that group. Any number of projects can be selected from the list. The selected projects are then integrated with Flyingduck. PR configuration After the integration is completed successfully, an "Integration Successful" confirmation message is displayed on the interface. Select Continue to proceed to the next step. PR configuration

Branch Configuration

Branches configuration allows you to manage and customize monitored bitbucket branches for automated scanning.

You can configure branches into two main stages: Production and Release. Branches such as Release, Staging, or Testing can be included in the Release stage. All other branches will be considered feature branches by default.

PR configuration

This configuration allows you to prioritize important branches and gain better visibility into your development workflow. Flyingduck will scan the configured branches and track all unique issues found. With this setup, you can monitor how many issues are present at each stage and how many are resolved before reaching production.

You can configure continuous scanning for your projects in two ways:

  • Enable for all branches – scans all branches continuously.
  • Scan for active branches – scans only the branches you specify.

Select the option that best fits your workflow, then click Continue. After saving, a confirmation message saying "Branches saved successfully" will appear.

Branch configuration

Jira Integration (Optional)

Flyingduck can be integrated with Jira to streamline issue tracking by automatically creating and linking issues discovered during scans to your Jira project boards. This ensures efficient management and resolution of vulnerabilities.

Setup Steps:

  1. Enter your Jira domain (e.g., https://your-org.atlassian.net).
  2. Enter the email ID associated with your Jira API token.
  3. Enter your Jira API token.
  4. Click Test Authentication to verify the connection, or Skip to configure it later.

jira integration

Once successfully authenticated, Flyingduck will seamlessly link detected issues to your Jira boards, allowing you to monitor, prioritize, and resolve them directly within Jira.

CI/CD Workflow Integration (Optional)

Flyingduck can be integrated into your CI/CD pipelines to automatically scan code during pipeline execution. This ensures that security issues are detected early in the development process, preventing potential vulnerabilities from reaching production.

Setup Instructions:

  1. Add the Flyingduck scanner to your CI/CD configuration file.
  2. Configure the scanner to run before your build step.
  3. Optionally, set the scanner to fail the build if any security issues are detected.

workflow

API Key configuration -->Workflow configuration -->

Webhook Configuration

To enable continuous scanning, configure a webhook in GitLab. A webhook can be applied either at the Group level or at the individual project level:

  • Group-level webhook → applies automatically to all projects within the group.
  • Project-level webhook → applies only to the selected project.

Recommendation: Configure at the Group level for centralized management and to automatically include all projects under that group.

  1. Navigate to either:

    • Group Settings → Webhooks (applies to all projects within the group) or
    • Project Settings → Webhooks (applies only to that specific project)

  2. Create a new webhook and use the following details:

FieldValue
URLhttps://api.flyingduck.io/listeners/v1/gitlab
Secret TokenPaste the generated FD_API_KEY from Flyingduck
SSL VerificationEnabled
  1. Under Trigger Events, enable:
  • Push events
  • Merge request events
  • Issue events
  • Project events
  • Subgroup events (only visible at group-level webhook)
  1. Save the webhook.

Behavior After Setup

  • Every new push, merge request, or repository event triggers Flyingduck to perform a scan.
  • If configured at the Group level, all repositories under that group will automatically use this webhook.

CLI Integration

This integration provides a simple way to scan your codebase without doing any UI configuration.

Steps to Integrate:

  1. Copy Your Flyingduck API Key:
    Retrieve your API key from the Flyingduck portal. This is essential for authentication during scanning.

  2. Clone Your projects:
    Open your terminal and run: git clone <your-repository-url>

    Navigate into the cloned project directory: cd <your-repo-folder>

  3. Run the Docker Command:
    Execute the following command to start the scan:

    docker run -e FD_API_KEY=<your-api-key> -v ${PWD}:/src --entrypoint /bin/bash flyingduckio/duckdefender:latest -c "duckdefender code --all"

    Replace <your-api-key> with the actual API key copied earlier.

  4. View Scan Results:
    The HEAD commit of the project is scanned. Results, including potential security issues, will be displayed directly in the Flyingduck portal dashboard.

For advanced configurations and additional flags, visit the Flyingduck CLI documentation (opens in a new tab).

This streamlined guide aims to get you scanning quickly with Flyingduck, leveraging Docker and your API key for effortless security integration.

Workflow Integration

Integrate Flyingduck seamlessly into your CI/CD pipelines to automate security scanning and ensure vulnerabilities are caught early.

Flyingduck scans your code on every commit, pull request, or build event within your existing CI/CD workflows.

Before committing any changes, there is an additional step to take, which involves adding the API key to the project.

API Key configuration

To enable CI/CD pipeline authentication with Flyingduck across multiple projects, store the API key as a Group-level CI/CD variable. This ensures that all projects in the selected group can use the same key without manual configuration.

Step 1: Generate Flyingduck API Key

  1. Log in to the Flyingduck Portal.
  2. Create a new API key (or copy an existing one).

Store this key securely — it will be required for authentication during scans.

Step 2: Add API Key to GitLab Group Variables

  1. In GitLab, go to: Groups → Select your group
  2. From the left sidebar, navigate to: Settings → CI/CD
  3. Locate the Variables section and click Add Variable
  4. Configure the fields as follows:
FieldValue
KeyFD_API_KEY
ValuePaste the Flyingduck API key
TypeVariable
Environment Scope* (default — applies to all projects/environments)
ProtectOptional — enable to restrict usage to protected branches (ex: main, release/*)
MaskRecommended — hides key from CI logs
Expand Variable Reference✅ Enable this (important)

Why enable "Expand variable reference"? This ensures that $FD_API_KEY is correctly interpreted as a variable when used inside scripts. Without enabling this, GitLab may treat $ literally and not as a reference to a variable.

✅ After saving, the variable becomes available to all pipelines of all projects within that group.

Yaml file Configuration

Create a .gitlab-ci.yml file at the root level of your project and paste the pipeline configuration shown below. You may modify the branch list as needed — the pipeline will run only for the branches you specify.

.gitlab-ci.yml
# Version: '2.1.2'
image: docker:stable
 
services:
  - docker:dind
 
variables:
  DOCKER_TAG: "flyingduckio/duckdefender:latest"
  FD_API_KEY: "$FD_API_KEY"
 
stages:
  - build_and_run
 
 
.duckdefender:
  stage: build_and_run
  script:
    # Pull the Docker image
    - docker pull $DOCKER_TAG
 
    # Run the Docker container
    - docker run -e FD_API_KEY="$FD_API_KEY" -e CI_COMMIT_SHA="$CI_COMMIT_SHA" -e CI_COMMIT_BRANCH="$CI_COMMIT_BRANCH" -e CI_COMMIT_BEFORE_SHA="$CI_COMMIT_BEFORE_SHA" -e CI_COMMIT_AUTHOR="$CI_COMMIT_AUTHOR" -v $CI_PROJECT_DIR:/src "$DOCKER_TAG"
 
 
 
# ✅ Run pipeline on multiple branches
run_duckdefender:
  extends: .duckdefender
  only:
    - main
    - dev
    - qa
    - staging
    - /^release-.*$/

Alternatively, instead of creating the file manually, you can configure it through the Pipeline Editor by navigating to:

Project → Build → Pipeline Editor

and pasting the same configuration there.

After adding the YAML file and configuring the API key, commit the changes. Depending on the branch you've committed to, if it's included in the YAML file, a code scan will be conducted and the data will be sent to the FlyingDuck portal for viewing.

repeat the same procedure to the other projects

  • Results and detected issues are surfaced in the Flyingduck portal, enabling quick review and remediation.

Benefits:

  • Continuous security checks without slowing down development.
  • Detects vulnerabilities before code merges or deployment.
  • Works with popular CI/CD tools such as GitLab CI.

Click Continue after setting up to proceed with monitoring your pipeline scans in the portal.

GitLabOnprem