```
Access tokens are obtained by exchanging a **Personal Access Token (PAT)** through the CybeDefend identity provider.
***
## Obtaining an Access Token (PAT → JWT)
The exchange is performed against the region-specific authentication domain:
| Region | Auth URL |
| ------ | -------------------------------- |
| EU | `https://auth-eu.cybedefend.com` |
| US | `https://auth-us.cybedefend.com` |
The token exchange requires the **CLI application ID** (`appId`). Only the CLI client is authorized to exchange a PAT for an access token — other clients (VS Code, IntelliJ) use a browser-based OAuth flow and have separate app IDs.
### Step 1 — Retrieve the CLI Application ID
Fetch the current app IDs for your region:
```bash theme={null}
# EU
curl https://api-eu.cybedefend.com/client-apps
# US
curl https://api-us.cybedefend.com/client-apps
```
Example response:
```json theme={null}
{
"cli": {
"appId": "fm90ay05zohu8fk2q45ms"
},
"vscode": {
"appId": "r84p1y100lf9hgvoey40c"
},
"intellij": {
"appId": "t40evldybv8uh97gsu7u1"
}
}
```
The CLI `appId` to use:
| Region | CLI `appId` |
| ------ | ----------------------- |
| EU | `fm90ay05zohu8fk2q45ms` |
| US | `7o6r9cvvi8um0kisvn7hm` |
These values are provided as a reference. Always verify against the live `/client-apps` endpoint before using them — the app ID may change between releases.
***
### Step 2 — Exchange Your PAT for an Access Token
Send a `POST` request to the `/oidc/token` endpoint of your region's auth domain, using the `urn:ietf:params:oauth:grant-type:token-exchange` grant type:
```bash EU theme={null}
curl -X POST https://auth-eu.cybedefend.com/oidc/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "client_id=fm90ay05zohu8fk2q45ms" \
-d "subject_token=YOUR_PAT" \
-d "subject_token_type=urn:logto:token-type:personal_access_token" \
-d "resource=https://api-eu.cybedefend.com"
```
```bash US theme={null}
curl -X POST https://auth-us.cybedefend.com/oidc/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "client_id=7o6r9cvvi8um0kisvn7hm" \
-d "subject_token=YOUR_PAT" \
-d "subject_token_type=urn:logto:token-type:personal_access_token" \
-d "resource=https://api-us.cybedefend.com"
```
Example response:
```json theme={null}
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid profile email"
}
```
***
### Step 3 — Call the API
Use the `access_token` from the response as a Bearer token in all subsequent requests:
```bash theme={null}
curl https://api-eu.cybedefend.com/organizations \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
```
Access tokens expire after 10 minutes. Repeat the exchange in Step 2 to obtain a fresh token.
***
## API Key — Deprecated
**API Keys are fully deprecated and no longer functional.** The `X-API-Key` header and all API key-based authentication have been removed. Please use Personal Access Tokens (PAT) as described above.
# Azure DevOps Server Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/azure-devops-server-setup
Use the CybeDefend CLI to integrate local scans into an on-prem Azure DevOps Server pipeline.
Run **CybeDefend** scans in your on-prem **Azure DevOps Server** pipeline, maintaining code on your own infrastructure while benefiting from automated security checks.
## Prerequisites
* **Personal Access Token (PAT)**: [Create one](/latest/code-scanning/local-code-scanning/introduction-api-key) in your CybeDefend profile and store it as `CYBEDEFEND_PAT` in Azure DevOps.
* **Agent Permissions**: Ensure your self-hosted agent can install or run the CybeDefend CLI.
* **Azure DevOps Access**: Sufficient rights to modify your pipeline definition.
Make sure the agent’s OS matches one of our supported CLI binaries (Windows, Linux, or macOS).
***
## Example azure-pipelines.yml
```yaml theme={null}
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: self
- script: |
curl -L https://github.com/CybeDefend/cybedefend-cli/releases/download/v1.0.0/cybedefend-linux-amd64 -o cybedefend
chmod +x cybedefend
sudo mv cybedefend /usr/local/bin/
displayName: 'Install CybeDefend CLI'
- script: |
cybedefend scan --dir . \
--ci \
--project-id $(CYBEDEFEND_PROJECT_ID)
displayName: 'Run CybeDefend Scan'
env:
CYBEDEFEND_PAT: $(CYBEDEFEND_PAT)
```
### Explanation
1. **checkout: self**\
Ensures your code is present on the build agent.
2. **Download & Install**\
Grabs the CLI binary, grants permissions, and moves it to `/usr/local/bin`.
3. **Run the Scan**\
The `--ci` flag keeps the output minimal. We rely on environment variables for the API key and project ID.
***
## Viewing Scan Results
1. **CLI Output**\
The console output shows a summary of detected issues.
2. **CLI “results”**\
If you want more detail in the pipeline logs, add a step:
```yaml theme={null}
- script: |
cybedefend results --project-id $(CYBEDEFEND_PROJECT_ID) --all --output sarif
displayName: 'Fetch Results in SARIF'
```
3. **CybeDefend Dashboard**\
Login to your CybeDefend account to see a full vulnerability breakdown.
Large repos can take extra time to upload. Ensure your pipeline has enough timeout for the scan process.
For advanced gating, fail the job if a certain severity is found. Combine --ci with parsing the CLI exit codes or vulnerability count from the JSON output.
# Bamboo Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/bamboo-setup
Use CybeDefend local scanning in your Atlassian Bamboo pipeline, either via Docker or binary installation.
**Bamboo** (from Atlassian) can run **CybeDefend** local scans to keep your code private. Whether you’re using Docker tasks or an executable on the agent, you’ll upload only the minimal data to CybeDefend for analysis.
## Prerequisites
* **Personal Access Token (PAT)**: Create one via [Personal Access Tokens (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key) and store it in **Plan Variables** (e.g. `CYBEDEFEND_PAT`).
* **Branch Target**: We advise scanning only your main branch to prevent mixing partial or experimental features.
Make sure your build agent has sufficient disk space, since the CLI zips your code locally before upload.
***
## Option 1: Docker-Based Task
If your Bamboo agent supports Docker:
1. **Add a “Source Code Checkout” Task**\
Ensures your repository is cloned into the workspace.
2. **Docker Task**
* **Command**: “Run a Docker container”
* **Image**: `cybedefend/local-scanner:latest`
* **Container Command**:
```bash theme={null}
cybedefend scan . \
--project-id ${bamboo.CYBEDEFEND_PROJECT_ID} \
--ci
```
3. **Save & Run**\
On the first run, if the project doesn’t exist yet in CybeDefend, it will be created automatically.
Under Plan Configuration > Repositories, limit builds to main or your default branch for consistent, consolidated vulnerability data.
***
## Option 2: Executable Capability
1. **Download Binary**\
Place the `cybedefend` CLI on the Bamboo agent(s). Mark it executable (`chmod +x cybedefend`).
2. **Agent Capability**
* In Bamboo, go to **Build Resources → Agents**.
* Select the agent, add an **Executable** capability (e.g. label: “CybeDefend CLI,” path: `/usr/local/bin/cybedefend`).
3. **Plan → Tasks**
* Add a **Command** task.
* Under **Executable**, choose “CybeDefend CLI.”
* **Argument field**:
```bash theme={null}
scan . --project-id ${bamboo.CYBEDEFEND_PROJECT_ID} --ci
```
If your code is large, consider ignoring extraneous directories to speed up scanning (e.g., node\_modules, vendor, or build artifacts).
***
## Checking Results
* **Bamboo Logs**: Check logs for a summary.
* **Extra Command**:
```bash theme={null}
cybedefend results --project-id ${bamboo.CYBEDEFEND_PROJECT_ID} --output html
```
* **CybeDefend Dashboard**: Full details on vulnerabilities, severity, and recommended fixes.
If you plan to gate releases, parse the CLI exit code or use --fail-on if we offer that feature for gating merges.
You can also define global variables for CYBEDEFEND\_PAT to reuse across multiple plans or projects.
# Bitbucket Pipeline Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/bitbucket-pipeline-setup
Run the CybeDefend CLI in Bitbucket Pipelines to securely upload and scan your repository code.
Use **Bitbucket Pipelines** to automate local scanning with the CybeDefend CLI. This approach is ideal if you want to keep direct repository access closed and rely on your pipeline to handle code uploads.
## Prerequisites
* **Personal Access Token (PAT)**: [Create it](/latest/code-scanning/local-code-scanning/introduction-api-key) and store in Bitbucket's **Repository Settings → Pipelines → Repository Variables** (e.g., `CYBEDEFEND_PAT`).
* **Bitbucket Pipelines**: Enable pipelines in your repository.
***
## Example bitbucket-pipelines.yml
```yaml theme={null}
image: ubuntu:latest
pipelines:
default:
- step:
name: CybeDefend Local Scan
caches:
- apt
script:
- apt-get update && apt-get install -y curl
- curl -L https://github.com/CybeDefend/cybedefend-cli/releases/download/v1.0.0/cybedefend-linux-amd64 -o cybedefend
- chmod +x cybedefend
- mv cybedefend /usr/local/bin/
- cybedefend scan --dir . --ci --project-id $CYBEDEFEND_PROJECT_ID
```
### Explanation
1. **image**\
`ubuntu:latest` is sufficient for installing cURL and the CLI.
2. **Install CLI**\
Similar approach as other platforms.
3. **Run the Scan**\
Use environment variables `$CYBEDEFEND_PAT` and `$CYBEDEFEND_PROJECT_ID` defined in Bitbucket's pipeline settings.
You can add advanced steps, such as storing results in artifacts or gating merges based on severity thresholds.
***
## Where to Check Results
1. **Pipeline Logs**: The CLI’s console output shows a summary.
2. **Local Results**: Optionally fetch `sarif` or `html` outputs in subsequent steps:
```bash theme={null}
cybedefend results --project-id $CYBEDEFEND_PROJECT_ID --output html --filename bitbucket-scan.html
```
3. **CybeDefend Dashboard**: Provides a deeper analysis of all vulnerabilities discovered.
Bitbucket Pipelines may have build minute limitations. Ensure your scans complete within your pipeline’s allotted time.
For huge codebases, consider partial scans or artifact caching to reduce pipeline duration.
# CircleCI Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/circleci-setup
Implement CybeDefend local scanning in your CircleCI pipeline without granting direct repo access.
**CircleCI** pipelines can run **CybeDefend** local scans by either installing the CLI or using Docker. This approach ensures your code is scanned **within** your pipeline, and only relevant data is uploaded to CybeDefend.
## Prerequisites
1. **Personal Access Token (PAT)**\
Create one via [Personal Access Tokens (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key). Store it in **Project Settings → Environment Variables** (e.g. `CYBEDEFEND_PAT`).
2. **Branch Filters**\
We recommend scanning only the main (or production) branch to avoid mixing partial results.
***
## Docker Example
**.circleci/config.yml**:
```yaml theme={null}
version: 2.1
jobs:
cybedefend-scan:
docker:
- image: cybedefend/local-scanner:latest
steps:
- checkout:
path: my-app
- run:
name: "Run CybeDefend scan"
command: |
cybedefend scan my-app \
--project-id $CYBEDEFEND_PROJECT_ID \
--ci
workflows:
local-security-workflow:
jobs:
- cybedefend-scan:
filters:
branches:
only:
- main
```
### Explanation
* **docker**: We use the prebuilt `cybedefend/local-scanner:latest` image.
* **checkout**: CircleCI’s built-in step to fetch code into `my-app`.
* **cybedefend scan**: Zips and uploads your code, referencing environment variables for the key and project ID.
You can also run cybedefend results in a follow-up step to retrieve a SARIF or HTML report.
***
## Alternative: CLI Binary
If you prefer your own Docker or machine executor:
```yaml theme={null}
version: 2.1
jobs:
cybedefend-scan:
docker:
- image: ubuntu:latest
steps:
- checkout
- run:
name: Install CybeDefend CLI
command: |
curl -L https://github.com/CybeDefend/cybedefend-cli/releases/download/v1.0.0/cybedefend-linux-amd64 -o cybedefend
chmod +x cybedefend
mv cybedefend /usr/local/bin/
- run:
name: Run Local Scan
command: |
cybedefend scan --dir . \
--project-id $CYBEDEFEND_PROJECT_ID \
--ci
```
Large codebases can require extra CPU/RAM. If you hit resource limits, upgrade your CircleCI plan or use a larger resource class.
For advanced gating, parse the CLI exit code or scan summary to fail the job on critical issues.
# GitHub Action Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/github-action-setup
Integrate CybeDefend local scans into your GitHub Actions workflow using the official CybeDefend Action.
By default, CybeDefend can scan GitHub repos in the cloud. If you prefer **not** to grant direct GitHub access, you can run local scans in your **GitHub Actions** pipeline, uploading code to CybeDefend yourself.
The easiest way to achieve this is by using the official **CybeDefend GitHub Action**.
## Prerequisites
* **Personal Access Token (PAT)**: [Create and store](/latest/code-scanning/local-code-scanning/introduction-api-key) it in your repository's **Settings → Secrets** → **Actions** (e.g., `CYBEDEFEND_PAT`).
* **Project ID**: You should also store your CybeDefend Project ID as a secret (e.g., `CYBEDEFEND_PROJECT_ID`).
The `api_key` input is deprecated. Use `token` with a Personal Access Token (PAT) instead.
***
## Using the CybeDefend Action
The [CybeDefend Action](https://github.com/CybeDefend/cybedefend-action) runs security scans easily in your CI/CD pipelines using the official CybeDefend CLI, powered by Docker (`ghcr.io/cybedefend/cybedefend-cli:latest`).
### Inputs
| Name | Description | Required | Default |
| ------------ | --------------------------- | -------- | ------- |
| `token` | Personal Access Token (PAT) | ✅ | |
| `project_id` | Project ID for the scan | ✅ | |
### Example Workflow: `.github/workflows/cybedefend-scan.yml`
Add the following steps to your workflow file:
```yaml theme={null}
name: CybeDefend Security Scan
on:
push:
branches:
- main # Or your desired branch
jobs:
cybedefend_scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3 # Or a later version
- name: Run CybeDefend Security Scan
uses: CybeDefend/cybedefend-action@v1
with:
token: ${{ secrets.CYBEDEFEND_PAT }}
project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
```
This workflow checks out your code and then runs the CybeDefend action, which handles the scanning process using the provided API key and project ID.
***
## Checking Your Results
* **Action Logs**: The job logs in GitHub Actions show a brief summary of vulnerabilities discovered during the scan.
* **CybeDefend Dashboard**: Log in to your CybeDefend account to view full vulnerability details, manage issues, and track historical scan data for your project.
Consider restricting scanning to your main development branch (e.g., `main` or `develop`). Use scans on feature branches if you want to catch new issues before they are merged.
# GitLab Self-Managed Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/gitlab-self-managed-setup
Integrate the CybeDefend CLI into a GitLab Self-Managed CI/CD pipeline for secure local code scanning.
This guide shows you how to run **CybeDefend local scans** within a **GitLab Self-Managed** environment. It’s ideal if you want to keep your code in-house and still benefit from automated security checks.
## Prerequisites
1. **Personal Access Token (PAT)**\
Ensure you've already created a PAT in the CybeDefend dashboard. If not, see [Personal Access Tokens (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key).
2. **CybeDefend CLI**\
You can either install the CLI directly in your job container or use a Docker image containing the CLI.
The --ci flag in CybeDefend’s CLI disables colors and fancy formatting, providing minimal, script-friendly output.
***
## Example .gitlab-ci.yml
```yaml theme={null}
stages:
- security-scan
security_scan_job:
image: ubuntu:latest
stage: security-scan
script:
- apt-get update && apt-get install -y curl
- curl -L https://github.com/CybeDefend/cybedefend-cli/releases/download/v1.0.0/cybedefend-linux-amd64 -o cybedefend
- chmod +x cybedefend
- mv cybedefend /usr/local/bin/
- cybedefend scan --dir . --ci --project-id $CYBEDEFEND_PROJECT_ID
only:
- main
```
### Key Points
* **Use the "security-scan" stage** or any custom stage relevant to your pipeline.
* **Install CLI**: Basic `curl` commands to grab the binary.
* **Run the scan**: Provide `--dir .` to scan current working directory.
* **Env Variables**: `$CYBEDEFEND_PAT` and `$CYBEDEFEND_PROJECT_ID` are stored in GitLab's CI/CD Variables.
If you prefer Docker-based scanning, create or pull an image with cybedefend pre-installed, then run the scan inside a container in your pipeline.
***
## Viewing Results
After the job completes, you can:
* **Check the CLI output** for immediate details.
* **Use the CLI ‘results’ command** to fetch a more comprehensive vulnerability listing:
```bash theme={null}
cybedefend results --project-id $CYBEDEFEND_PROJECT_ID --all --output html
```
* **Visit CybeDefend Dashboard** to see a full breakdown of vulnerabilities found during each pipeline run.
For large codebases, consider caching dependencies to speed up builds – your security scans will remain unaffected as long as you keep scanning the final code or artifact.
# Jenkins Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/jenkins-setup
Integrate CybeDefend’s local scanning into a Jenkins pipeline without exposing your code externally.
**Jenkins** is a widely used CI/CD tool that you can host on-prem or in the cloud. By installing the **CybeDefend CLI** on your Jenkins agent, you can securely run scans locally and upload the results to CybeDefend.
## Requirements
1. **Personal Access Token (PAT)**\
Follow [Personal Access Tokens (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key) to generate and store a PAT in Jenkins credentials (e.g., `CYBEDEFEND_PAT`).
2. **Operating System**\
Jenkins agent must be on a supported OS (Linux x86\_64, Windows, macOS). For Linux, ensure `glibc >= 2.27`.
3. **Sufficient Resources**\
At least 2–4 GB RAM, plus the recommended disk space for your repo.
By default, we recommend scanning the main (or master) branch to avoid mixing partial results across multiple branches.
***
## Option 1: Docker-Based Scanning
If your Jenkins agent supports Docker, run the **CybeDefend** scanner image:
1. **Create a New Jenkins Project**
* Choose **Pipeline** or **Freestyle** with a Docker step.
2. **Configure Docker**\
Make sure your agent can run containers.
3. **Build Step**:
```bash theme={null}
docker run --rm \
-v $WORKSPACE:/app \
-w /app \
-e CYBEDEFEND_PAT=$CYBEDEFEND_PAT \
cybedefend/local-scanner:latest \
cybedefend scan . --project-id $CYBEDEFEND_PROJECT_ID --ci
```
### Explanation
* **-v \$WORKSPACE:/app**: Mount your code from Jenkins into `/app`.
* **cybedefend/local-scanner:latest**: Our Docker image containing the CLI.
* **--ci**: Outputs minimal logs for a clean pipeline.
We suggest setting Branch Specifier to main or master in your Jenkins job, so scans remain consistent.
***
## Option 2: Installing the Binary Directly
1. **Download the Binary**\
In a shell build step:
```bash theme={null}
curl -L https://github.com/CybeDefend/cybedefend-cli/releases/download/v1.0.0/cybedefend-linux-amd64 -o cybedefend
chmod +x cybedefend
sudo mv cybedefend /usr/local/bin/
```
2. **Run the Scan**
```bash theme={null}
cybedefend scan . \
--project-id $CYBEDEFEND_PROJECT_ID \
--ci
```
If this is your first time scanning the repo, a new project is created in CybeDefend. On subsequent scans, results are appended under the same Project ID.
***
## Checking Results
* **Jenkins Console Output**: Quick summary of discovered vulnerabilities.
* **CybeDefend “results” command**: Add a new step to fetch more detailed results in JSON, HTML, or SARIF.
* **CybeDefend Dashboard**: Provides an in-depth view, charts, and historical vulnerability data.
For large repos, scanning may take a few minutes. Adjust Timeout settings accordingly.
Consider gating a release by parsing CLI output or exit codes, failing the build if high-severity issues remain.
# TeamCity Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/ci-cd-integrations/teamcity-setup
Quickly integrate local scanning with CybeDefend in a TeamCity pipeline using our Docker image.
Use **Docker** to run CybeDefend local scans in your TeamCity pipeline, keeping your code in-house while uploading only the needed data for security analysis.
## Prerequisites
* **Personal Access Token (PAT)**: [Create one](/latest/code-scanning/local-code-scanning/introduction-api-key) in your CybeDefend profile and store it as `CYBEDEFEND_PAT` in TeamCity parameters.
* **Agent Permissions**: Ensure your self-hosted agent can install or run the CybeDefend CLI.
* **TeamCity Access**: Sufficient rights to modify your pipeline definition.
***
## Best Practices
* **Scan the main branch only**\
By default, all scan results unify under a single “main” or “master” branch in CybeDefend. Limiting scans to your default branch prevents mixing partial results from feature branches.
* **Use Docker**\
This container-based approach simplifies environment setup, avoiding any installation overhead.
***
## Example TeamCity Configuration (YAML)
If you’re using a YAML-based approach or the TeamCity DSL, a **script** build step might look like:
```yaml theme={null}
jobs:
local_security_scan:
steps:
- type: script
name: CybeDefend Local Scan
docker-image: cybedefend/local-scanner:latest
script-content: >-
cybedefend scan ./ --ci
--project-id %CYBEDEFEND_PROJECT_ID%
```
### Explanation
* **docker-image**: Points to a Docker image (e.g., cybedefend/local-scanner) that already has the CybeDefend CLI installed.
* **script-content**: Runs `cybedefend scan`, zipping your current directory (`./`) and securely uploading it to CybeDefend.
* **--ci**: Outputs minimal logs for a cleaner CI experience.
* **Environment Variables**: `%CYBEDEFEND_PAT%` and `%CYBEDEFEND_PROJECT_ID%` are typically stored in **TeamCity** → **Project Settings** → **Parameters**, masking sensitive data.
If this is your first time scanning the repo, CybeDefend will automatically create a new project (assuming the Project ID is valid or left empty to be generated). Subsequent scans append results to the same project.
***
## Verifying Results
1. **Console Output**\
After the step finishes, TeamCity logs display a summary of any critical or high-severity issues.
2. **Further Exploration**\
Add a subsequent step to fetch results in JSON, HTML, or SARIF formats:
```bash theme={null}
cybedefend results --project-id %CYBEDEFEND_PROJECT_ID% --output sarif --all
```
3. **CybeDefend Dashboard**\
Visit your CybeDefend account to see the complete vulnerability list, including severity breakdowns and recommended fixes.
For large codebases, scanning can take a few minutes. Make sure your TeamCity job does not have overly strict timeouts.
You can restrict scanning to main by adjusting your TeamCity triggers. This avoids mixing partial or experimental features in your final security reports.
# CLI Options for Local Scanner
Source: https://docs.cybedefend.com/latest/code-scanning/local-code-scanning/cli-options
Quickly install and use the CybeDefend CLI to scan your code locally, fetch results, and integrate secure checks into CI/CD.
The **CybeDefend CLI** provides an efficient way to run local code scans and view results on our platform. It supports **Linux, macOS, and Windows** and is easily integrated into **CI/CD pipelines** or used in **offline** environments.
## Usage
```bash theme={null}
cybedefend [command] [flags]
```
```bash theme={null}
CybeDefend CLI is a CLI tool to interact with the CybeDefend API.
Usage:
cybedefend [command]
Available Commands:
completion Generate the autocompletion script for the specified shell
help Help about any command
login Authenticate with CybeDefend (OAuth browser flow or PAT)
logout Clear stored credentials
results Get scan results
scan Start a new scan
version Show the version of cybedefend
Flags:
--api-url string API URL (default "https://api-us.cybedefend.com")
--region string Platform region: us or eu (default "us")
--ci CI mode
--config string Config file (default is $HOME/.cybedefend/config.yaml) (optional)
--debug Debug mode
-h, --help help for cybedefend
Use "cybedefend [command] --help" for more information about a command.
```
## Installation
You can install the CybeDefend CLI using one of the following methods:
### 1. Pre-built Binaries
**Supported Platforms:**
* **macOS**: `cybedefend-darwin-amd64` (Intel) or `cybedefend-darwin-arm64` (Apple Silicon M1/M2)
* **Linux**: `cybedefend-linux-amd64` (64-bit) or `cybedefend-linux-386` (32-bit)
* **Windows**: `cybedefend-windows-amd64.exe` (64-bit) or `cybedefend-windows-386.exe` (32-bit)
**Installation Steps:**
1. **Download** the latest release for your platform from the [GitHub Releases page](https://github.com/CybeDefend/cybedefend-cli/releases)
2. **Make Executable** (Linux/macOS):
```bash theme={null}
chmod +x cybedefend-
```
3. **Move to PATH**:
```bash theme={null}
sudo mv cybedefend- /usr/local/bin/cybedefend
```
4. **Verify Installation**:
```bash theme={null}
cybedefend version
```
### 2. Build from Source
```bash theme={null}
# Ensure you have Go installed
git clone https://github.com/CybeDefend/cybedefend-cli.git
cd cybedefend-cli
go build -o cybedefend
# Move the binary to your PATH
sudo mv cybedefend /usr/local/bin/
cybedefend version
```
### 3. Docker Image
A pre-built Docker image is available on GitHub Container Registry:
```bash theme={null}
docker pull ghcr.io/cybedefend/cybedefend-cli:latest
# Example usage:
docker run --rm -v $(pwd):/app -w /app \
-e CYBEDEFEND_PAT=$CYBEDEFEND_PAT \
-e CYBEDEFEND_PROJECT_ID=$CYBEDEFEND_PROJECT_ID \
ghcr.io/cybedefend/cybedefend-cli:latest scan --dir . --ci
```
***
## Authentication
The CLI supports two authentication modes. Both store credentials in `~/.cybedefend/credentials.json` and are picked up automatically by subsequent commands.
### OAuth Browser Flow (recommended for local use)
```bash theme={null}
cybedefend login --region eu
```
Opens the CybeDefend login page in your default browser. After completing authentication, the CLI stores your session automatically. Access tokens are refreshed transparently when they expire.
### PAT-Based Login (recommended for CI/CD)
```bash theme={null}
cybedefend login --pat YOUR_PAT --region eu
```
Validates your Personal Access Token and saves it locally. All subsequent commands use it automatically.
```bash theme={null}
# One-time login
cybedefend login --pat YOUR_PAT --region eu
# From now on, no credentials needed per-command
cybedefend scan --dir .
cybedefend results --project-id YOUR_PROJECT_ID
```
### Environment Variable (no login step)
For CI/CD environments, skip `cybedefend login` entirely and set the PAT as an environment variable:
```bash theme={null}
export CYBEDEFEND_PAT=your_pat_here
```
### Credential Priority Order
1. `--pat` flag (highest priority)
2. `CYBEDEFEND_PAT` environment variable
3. `pat` field in config file
4. Stored credentials from `cybedefend login`
### Logout
```bash theme={null}
cybedefend logout
```
Deletes `~/.cybedefend/credentials.json` and clears the stored session.
**Deprecated**: The `--api-key` flag has been removed. API Keys are no longer supported.
***
## Configuration
**Config File** (`config.yaml` in `./`, `$HOME/.cybedefend`, or `/etc/cybedefend`):
```yaml theme={null}
api_url: "https://api-us.cybedefend.com" # Default if not overridden
pat: "your-personal-access-token" # PAT from Profile → Personal Access Tokens
project_id: "your-project-id"
# Optional: choose region (us/eu)
# region: "eu"
```
**Environment Variables:**
* `CYBEDEFEND_API_URL` - API base URL
* `CYBEDEFEND_REGION` - Platform region (`us` or `eu`). Ignored if `CYBEDEFEND_API_URL` is set
* `CYBEDEFEND_PAT` - Personal Access Token (PAT) for authentication
* `CYBEDEFEND_PROJECT_ID` - Default project ID
**Command-Line Flags** (override config and env vars):
* `--region` - Platform region (`us` or `eu`). Selects `https://api-us.cybedefend.com` or `https://api-eu.cybedefend.com`
* `--api-url` - API base URL (manual override; takes precedence over `--region`)
* `--project-id` - Project ID
> **Deprecated**: The `--api-key` flag and `CYBEDEFEND_API_KEY` environment variable have been removed. Use `CYBEDEFEND_PAT` with a Personal Access Token instead.
***
## Commands
### 1. `scan`
```bash theme={null}
cybedefend scan [flags]
```
Starts a new scan by uploading a directory or a pre-zipped file to the CybeDefend platform. By default, the command waits for the scan to complete and displays a summary of findings.
**Flags:**
* `--dir, -d` - Directory to scan (will be zipped before uploading). Cannot be used with `--file`
* `--file, -f` - Pre-zipped file to scan. Cannot be used with `--dir`
* `--project-id` - Project ID for the scan (required if not set in config/env)
* `--region` - Platform region: `us` (default) or `eu`
* `--api-url` - Manual API URL override (takes precedence over `--region`)
* `--wait, -w` - Wait for scan completion before exiting (default: `true`)
* `--interval` - Polling interval in seconds when waiting (default: `5`)
* `--break-on-fail` - Exit with error code if scan fails (default: `false`)
* `--break-on-severity` - Exit with error code if vulnerabilities of specified severity or higher are found. Values: `critical`, `high`, `medium`, `low`
* `--ci` - CI/CD-friendly output (no colors, ASCII art, or extra formatting)
#### Examples
```bash theme={null}
# Scan a directory, wait for completion, and show summary (default behavior)
# Assumes PAT is set via `cybedefend login` or CYBEDEFEND_PAT env var
cybedefend scan --dir ./my-app --project-id your-project-id
# Scan a pre-zipped file (PAT must be configured via login or env var)
cybedefend scan --file ./my-app.zip --project-id your-project-id
# Start a scan but don't wait for completion
cybedefend scan --dir ./my-app --project-id your-project-id --wait=false
# Scan, wait, and fail the CI job if the scan process itself fails
cybedefend scan --dir ./my-app --project-id your-project-id --break-on-fail
# Scan, wait, and fail the CI job if any CRITICAL vulnerabilities are found
cybedefend scan --dir ./my-app --project-id your-project-id --break-on-severity critical
# Scan, wait, and fail the CI job if any MEDIUM or higher vulnerabilities are found
cybedefend scan --dir ./my-app --project-id your-project-id --break-on-severity medium
# Select the EU region
cybedefend scan --dir ./my-app --region eu
# Manually override the API URL
cybedefend scan --dir ./my-app --api-url https://api-eu.cybedefend.com
# Change polling interval to 10 seconds
cybedefend scan --dir ./my-app --interval 10
# CI-friendly mode
cybedefend scan --dir ./my-app --ci
```
### 2. `results`
```bash theme={null}
cybedefend results [flags]
```
Retrieves scan results for a project and writes them to a file. By default it fetches **every** scan type (`--type all`) in JSON, across all pages, and saves to `results.json` in the current directory.
**Flags:**
| Flag | Default | What it does |
| ---------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--project-id` | from config / env | Project to fetch results for. Required if not set in the config file or `CYBEDEFEND_PROJECT_ID` |
| `--type, -t` | `all` | Scan type: `sast`, `sca`, `iac`, `secret`, `cicd`, `container`, or `all` |
| `--status` | `to_verify,confirmed` | Comma-separated triage states to include: `to_verify`, `confirmed`, `resolved`, `ignored` |
| `--branch, -b` | all branches | Only return findings on this branch |
| `--all, -a` | `true` | Fetch every page. Pass `--all=false` to fetch a single page |
| `--page, -p` | `1` | Page to fetch. Ignored unless you pass `--all=false` |
| `--grouped, -g` | `false` | Group findings by rule / CVE instead of listing every occurrence. JSON output only |
| `--scores` | `false` | Add the CVE identifier and the risk scores (priority, CVSS 4.0, EPSS, exploitability) to the output. Applies to the per-occurrence output; grouped output always carries the scores the platform computed |
| `--output, -o` | `json` | Output format: `json`, `html`, `sarif`, or `markdown` |
| `--filename, -f` | `results.json` | Output file name |
| `--filepath` | `.` | Directory to write the file to |
| `--ci` | `false` | CI/CD-friendly output (no colors or extra formatting) |
With `--type all` the JSON output keeps one array per scan type (`sast`, `sca`, `iac`, `secret`, `cicd`, `container`); the `html`, `sarif` and `markdown` reports flatten them into a single list. `--grouped` needs a single scan type — it has no effect while `--type` is `all`.
#### Choosing which triage states to export
`--status` decides which triage states end up in the file. The default, `to_verify,confirmed`, is the set of findings that still need attention: what you have already resolved or ignored stays out.
| Value | Meaning |
| ----------- | -------------------------------------- |
| `to_verify` | Not triaged yet |
| `confirmed` | Triaged and accepted as a real finding |
| `resolved` | Fixed |
| `ignored` | Deliberately dismissed |
Any other value is rejected before a request is sent. `not_exploitable` is a state you will see in the platform, but the API does not accept it as a filter value, so you cannot ask for it here.
**Your exports get smaller, and that is the fix.** Earlier CLI versions sent this filter in a spelling the API silently discarded, so every export contained every state — resolved and ignored findings included. The filter now reaches the API. If a pipeline of yours counts rows in `results.json` or feeds them into a ticketing system, expect fewer rows and adjust the threshold.
```bash theme={null}
# Before: the default export returned every state, whatever you asked for
cybedefend results --project-id $PROJECT_ID --type sca
# After: ask for the extra states explicitly to get a comparable volume
cybedefend results --project-id $PROJECT_ID --type sca \
--status to_verify,confirmed,resolved,ignored
```
Findings in the `not_exploitable` state were part of the old over-delivered export and cannot be requested back, so even the four-state filter above returns slightly fewer rows than the old default.
Every finding in a JSON export carries its own state in `currentState`, so a file is self-describing and you can re-filter it afterwards without another call:
```json theme={null}
{
"id": "6f1c…",
"path": "src/auth/session.ts",
"branch": "main",
"currentState": "to_verify",
"vulnerability": { "name": "…", "severity": "…" }
}
```
`currentState` is present in the JSON output only — the `html`, `sarif` and `markdown` reports do not show the triage state. `--status` is also not applied to `--grouped --type container`, which returns grouped images through a separate endpoint.
`--status` is a recent addition. If your CLI answers `unknown flag: --status`, upgrade the binary from the [releases page](https://github.com/CybeDefend/cybedefend-cli/releases).
#### Examples
```bash theme={null}
# Every scan type, findings that still need attention (the default)
cybedefend results --project-id your-project-id
# Only what you have dismissed, to audit your own triage decisions
cybedefend results --project-id your-project-id --type sca --status ignored,resolved
# Everything the API will filter on, for a full snapshot
cybedefend results --project-id your-project-id --status to_verify,confirmed,resolved,ignored
# SAST findings on one branch, as SARIF, for code scanning upload
cybedefend results --project-id your-project-id --type sast --branch main \
--output sarif --filename results.sarif
# SCA findings with the CVE identifiers and risk scores
cybedefend results --project-id your-project-id --type sca --scores
# SCA findings grouped by CVE instead of one row per occurrence
cybedefend results --project-id your-project-id --type sca --grouped
# A single page instead of the whole project
cybedefend results --project-id your-project-id --type sast --all=false --page 2
```
### 3. `version`
Displays the CLI version:
```bash theme={null}
cybedefend version
```
### 4. `completion`
Generates shell autocompletion for bash, zsh, etc.:
```bash theme={null}
cybedefend completion [shell]
```
***
## CI/CD Integration
Combine the `scan` and `results` commands in your pipelines. The `scan` command's `--wait`, `--break-on-fail`, and `--break-on-severity` flags are particularly useful for controlling pipeline flow based on scan outcomes.
For example, in GitHub Actions:
```yaml theme={null}
- name: Install CybeDefend CLI # Or use the Docker image method
run: |
# Download commands...
curl -L https://github.com/CybeDefend/cybedefend-cli/releases/latest/download/cybedefend-linux-amd64 -o cybedefend
chmod +x cybedefend
sudo mv cybedefend /usr/local/bin/
- name: Run security scan and break on High severity
env:
CYBEDEFEND_PAT: ${{ secrets.CYBEDEFEND_PAT }}
run: cybedefend scan --dir ./ --ci \
--project-id ${{ secrets.CYBEDEFEND_PROJECT_ID }} \
--break-on-severity high # Fail build if High or Critical vulns found
# Optionally, fetch detailed results artifact if needed, e.g., for reporting
# This step might only run if the previous one succeeded, depending on workflow setup
- name: Fetch Detailed Results as SARIF
env:
CYBEDEFEND_PAT: ${{ secrets.CYBEDEFEND_PAT }}
run: cybedefend results --project-id ${{ secrets.CYBEDEFEND_PROJECT_ID }} \
--output sarif --filename results.sarif --ci
# - name: Upload SARIF results (Example using GitHub action)
# uses: github/codeql-action/upload-sarif@v2
# with:
# sarif_file: results.sarif
```
Use `--ci` for minimal logs during the scan. The `--break-on-*` flags allow automatic build failure based on your security policies. You can still use `cybedefend results` to fetch detailed reports if the scan passes the break conditions or if you need the data regardless.
***
**Related:** [Code Repository Scanning](/latest/code-scanning/scanning-options/code-repository-scanning) · [CI/CD Integrations](/latest/code-scanning/ci-cd-integrations/github-action-setup) · [GitHub CLI Repository](https://github.com/CybeDefend/cybedefend-cli)
# Personal Access Tokens (PAT)
Source: https://docs.cybedefend.com/latest/code-scanning/local-code-scanning/introduction-api-key
Create and use Personal Access Tokens to authenticate the CybeDefend CLI.
A **Personal Access Token (PAT)** lets you authenticate the CybeDefend CLI without going through the browser. It is the recommended authentication method for CI/CD pipelines and scripted environments.
***
## Create a Personal Access Token
1. Log in to the CybeDefend web interface
2. Navigate to **Profile → Personal Access Tokens**
3. Click **+ Create New Token**, give it a name (e.g., "CLI Token")
4. Copy and store the token securely — it is shown only once
![Create Personal Access Token]()
Store your PAT in a secure secrets manager or as an encrypted CI/CD secret. Never commit it to source control.
***
## Authenticate the CLI with Your PAT
```bash theme={null}
cybedefend login --pat YOUR_PAT --region eu
```
Your credentials are saved to `~/.cybedefend/credentials.json`. Subsequent commands (scan, results…) use them automatically — no need to pass `--pat` every time.
Once logged in, the `--region` flag is remembered automatically. You can simply run `cybedefend scan --dir .` for all future commands.
***
## Authenticate via OAuth (interactive)
For local development, you can also log in through your browser:
```bash theme={null}
cybedefend login --region eu
```
This opens the CybeDefend login page in your default browser. After completing authentication, the CLI stores your session automatically. Access tokens are refreshed transparently when they expire.
***
## Use a PAT Without Logging In
For CI/CD environments where persistent sessions are not practical, you can pass the PAT directly via environment variable — no `cybedefend login` step needed:
```bash theme={null}
export CYBEDEFEND_PAT=your_pat_here
cybedefend scan --dir . --project-id YOUR_PROJECT_ID
```
Or inline for a single command:
```bash theme={null}
CYBEDEFEND_PAT=${{ secrets.CYBEDEFEND_PAT }} cybedefend scan --dir . --project-id YOUR_PROJECT_ID
```
## Credential Priority Order
When running any command, credentials are resolved in this order:
1. `--pat` flag (highest priority)
2. `CYBEDEFEND_PAT` environment variable
3. `pat` field in config file (`config.yml`)
4. Stored credentials from `cybedefend login`
## Logout
```bash theme={null}
cybedefend logout
```
Deletes `~/.cybedefend/credentials.json` and clears the stored session.
***
## Next Steps
* [CLI Options for Local Scanner](/latest/code-scanning/local-code-scanning/cli-options)
* [Mac Setup](/latest/code-scanning/local-code-scanning/mac-setup)
* [Windows Setup](/latest/code-scanning/local-code-scanning/windows-setup)
* [Linux Setup](/latest/code-scanning/local-code-scanning/linux-setup)
# Linux Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/local-code-scanning/linux-setup
Install the CybeDefend CLI on various Linux distributions for local or CI-based security scans.
CybeDefend’s CLI offers support for a wide range of Linux distributions. Install the CLI, provide your API key, and scan code right from your terminal or Docker-based environments.
## Requirements
* **Linux** (32-bit or 64-bit).
* [Personal Access Token (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key) from your CybeDefend account.
* Basic terminal knowledge.
***
## Installation Steps
1. **Download the Binary**\
From [Releases](https://github.com/CybeDefend/cybedefend-cli/releases), pick `cybedefend-linux-amd64` (64-bit) or `cybedefend-linux-386` (32-bit).
2. **Make Executable**
```bash theme={null}
chmod +x cybedefend-linux-amd64
```
3. **Move to PATH**
```bash theme={null}
sudo mv cybedefend-linux-amd64 /usr/local/bin/cybedefend
```
4. **Test**
```bash theme={null}
cybedefend version
```
If you’re running Alpine or a musl-based distro, ensure compatibility or build from source using go build.
***
## Scanning Your Project
1. **Authenticate (one-time setup)**
```bash theme={null}
cybedefend login --pat YOUR_PAT --region eu
```
2. **In Terminal**
```bash theme={null}
cd ~/my-app
cybedefend scan --dir . --project-id YOUR_PROJECT_ID
```
3. **Check Results**
```bash theme={null}
cybedefend results --project-id YOUR_PROJECT_ID --all --output json
```
If you run scans inside Docker, mount your source directory as a volume and pass your PAT via the CYBEDEFEND\_PAT environment variable.
This process easily integrates into Jenkins, GitLab CI, or GitHub Actions running on Linux hosts.
# Mac Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/local-code-scanning/mac-setup
Install and run the CybeDefend CLI on macOS for secure local code scanning.
This guide walks you through installing the **CybeDefend CLI** on macOS, ensuring you can quickly scan projects locally.
## Requirements
* **macOS** (Intel or Apple Silicon).
* [Personal Access Token (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key) from your CybeDefend account.
* Optional: Homebrew or direct binary installation.
***
## Installation Methods
### 1. Homebrew (Recommended)
```bash theme={null}
brew tap cybedefend/cli
brew install cybedefend
```
Check version:
```bash theme={null}
cybedefend version
```
### 2. Direct Download
1. **Download**: `cybedefend-darwin-amd64` (for Intel) or `cybedefend-darwin-arm64` (for M1/M2) from [Releases](https://github.com/CybeDefend/cybedefend-cli/releases).
2. **Make Executable**:
```bash theme={null}
chmod +x cybedefend-darwin-*
```
3. **Move to /usr/local/bin**:
```bash theme={null}
sudo mv cybedefend-darwin-* /usr/local/bin/cybedefend
```
4. **Verify**:
```bash theme={null}
cybedefend --help
```
If you encounter a macOS Gatekeeper prompt, right-click the binary in Finder → Open, or remove quarantine attributes with xattr -d com.apple.quarantine cybedefend-darwin-\*.
***
## Scanning on macOS
1. **Navigate to Your Code**
```bash theme={null}
cd ~/Projects/my-app
```
2. **Authenticate (one-time setup)**
```bash theme={null}
cybedefend login --pat YOUR_PAT --region eu
```
3. **Run a Scan**
```bash theme={null}
cybedefend scan --dir . --project-id YOUR_PROJECT_ID
```
4. **Check Results**
```bash theme={null}
cybedefend results --project-id YOUR_PROJECT_ID --all
```
You can also store your PAT in the CYBEDEFEND\_PAT environment variable to avoid typing it each time:
```bash theme={null}
export CYBEDEFEND_PAT=your_pat_here
```
# Windows Setup for Local Code Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/local-code-scanning/windows-setup
Install and run the CybeDefend CLI on Windows for straightforward local code scanning.
If you’re on Windows, you can install the **CybeDefend CLI** as an `.exe` file. Quickly run security scans from PowerShell, Command Prompt, or within CI runners like GitHub Actions (Windows-based).
## Requirements
* **Windows 10 or 11** (32-bit or 64-bit).
* [Personal Access Token (PAT)](/latest/code-scanning/local-code-scanning/introduction-api-key) from your CybeDefend account.
* Optional: Integration with your CI pipeline.
***
## Installation Steps
1. **Download**\
Grab `cybedefend-windows-amd64.exe` (64-bit) or `cybedefend-windows-386.exe` (32-bit) from [Releases](https://github.com/CybeDefend/cybedefend-cli/releases).
2. **Rename (Optional)**\
Rename to `cybedefend.exe` for easier usage.
3. **Add to PATH**\
Place it in a folder included in your PATH, or just call it from its current location.
On Windows, some security tools may flag new executables. Ensure cybedefend.exe is unblocked in your antivirus or firewall settings.
***
## Running a Scan
1. **Open PowerShell or CMD**\
Navigate to your project directory:
```powershell theme={null}
cd C:\Users\YourName\Projects\my-app
```
2. **Authenticate (one-time setup)**
```powershell theme={null}
cybedefend.exe login --pat YOUR_PAT --region eu
```
3. **Initiate Scan**
```powershell theme={null}
cybedefend.exe scan --dir . --project-id YOUR_PROJECT_ID
```
4. **View Results**
```powershell theme={null}
cybedefend.exe results --project-id YOUR_PROJECT_ID --output sarif
```
If you see a SmartScreen prompt, confirm the binary’s source to proceed with the installation.
You can also store your PAT in the **CYBEDEFEND\_PAT** environment variable:
```powershell theme={null}
$env:CYBEDEFEND_PAT = "your_pat_here"
```
Using **--ci** can simplify output if you're parsing logs in a Windows-based CI system.
# How to Launch a Scan on a C/C++ Project
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-c-cpp
Integrate CybeDefend with your C/C++ toolchain and lock dependencies, typically via conan.lock.
CybeDefend supports scanning C/C++ code for vulnerabilities in your source files and **conan.lock** for dependency management. By committing this lockfile to your repository, you enhance security scanning and ensure consistent builds.
## Recommended Steps
1. **Adopt Conan (or Another Manager)**\
If you rely on external libraries, use a package manager like **Conan** that can produce `conan.lock`.
2. **Generate & Commit conan.lock**
* Ensure you have a Conan profile set up: `conan profile detect` (if needed)
* Run `conan lock create . --lockfile-out=conan.lock` to produce the lockfile.
* Run `conan install` to install dependencies using your lockfile.
* Commit `conan.lock` so everyone uses the exact same library versions.
3. **Keep a Clean Codebase**\
Add any `.deps/` or build artifacts to `.gitignore` so that only the lockfile and source are tracked.
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
## Generating a Conan Lockfile
For Conan 2.x projects, use the following command in your project directory:
```bash theme={null}
conan lock create . --lockfile-out=conan.lock
```
For older Conan 1.x projects, use:
```bash theme={null}
conan lock create conanfile.py --lockfile=conan.lock
```
## Supported Files for C/C++
| File Examples |
| ----------------------------------------------------------------------------- |
| `conan.lock`, `CMakeLists.txt`, `.cpp`, `.h`, `conanfile.py`, `conanfile.txt` |
CybeDefend can detect vulnerabilities in known C/C++ libraries if your lockfile references them. Without a lockfile, your scanning might be incomplete or prone to version ambiguity.
Always re-run conan lock create after updating library versions, and commit the new lockfile to keep CybeDefend scanning accurate.
# How to Launch a Scan on a PHP/Composer Project
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-composer
Best practices for configuring Composer projects to be scanned by CybeDefend, with an emphasis on lockfiles.
If your PHP application uses **Composer**, CybeDefend can detect vulnerabilities in your `composer.json` and `composer.lock` files. However, you'll get the **best** results if you have a lockfile with pinned dependencies.
## Recommended Steps
1. **Install Dependencies with Composer**\
Run one of these commands to generate a `composer.lock` file:
```bash theme={null}
# Standard install
composer install
# If you encounter platform requirement issues
composer install --ignore-platform-reqs
# If you want to just generate the lockfile without installing
composer update --no-scripts --ignore-platform-reqs --lock
```
2. **Commit the Lockfile**\
Always commit `composer.lock` to your repository. This ensures that the entire team, and CybeDefend, see the exact dependency versions.
3. **Keep Your Lockfile Updated**\
When you want to update dependencies, use `composer update` or `composer require` and commit the updated lockfile.
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
## Troubleshooting Lockfile Generation
If you encounter issues generating a lockfile, try these approaches:
```bash theme={null}
# Update dependencies while ignoring platform requirements
composer update --no-interaction --no-scripts --ignore-platform-reqs
# Force lockfile regeneration
composer update --no-interaction --no-scripts --ignore-platform-reqs --lock
```
While CybeDefend can scan projects with only a composer.json file, we strongly recommend generating and committing the composer.lock file for more accurate vulnerability detection.
## Supported Files for PHP/Composer
| File Examples |
| -------------------------------- |
| `composer.json`, `composer.lock` |
Never edit your composer.lock file manually. Always let Composer handle this file to ensure proper dependency resolution.
If you're using development dependencies, be aware that these are also included in the security scanning. Consider carefully which packages you include, even as development dependencies.
# How to Launch a Scan on a .NET Project
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-dotnet
Use lockfiles like packages.lock.json in your .NET build for better SCA detection with CybeDefend.
**.NET** projects often rely on NuGet packages. By generating a `packages.lock.json` file, you create a stable snapshot of all dependencies—critical for accurate CybeDefend SCA scanning.
## Recommended Steps
1. **Enable Lockfiles in .csproj**
You can enable lockfiles in any of these ways:
**Option A**: Add to your `.csproj` file:
```xml theme={null}
true
true
```
**Option B**: For all projects, create a `Directory.Build.props` file in your solution root:
```xml theme={null}
true
```
2. **Run dotnet restore**\
This generates a `packages.lock.json` file for each project.
```bash theme={null}
dotnet restore --use-lock-file
```
3. **Commit packages.lock.json**\
Never edit this file manually. Let `dotnet restore` handle updates.
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
## Lockfile Commands
* **Generate**: `dotnet restore --use-lock-file`
* **Locked Restore**: `dotnet restore --locked-mode`
* **Update**: Change versions in `.csproj` or `Directory.Packages.props`, then run `dotnet restore --force` to update the lockfile.
## Using Central Package Management
For larger solutions with many projects, use NuGet's Central Package Management:
1. Create a `Directory.Packages.props` file in your solution root:
```xml theme={null}
true
```
2. In your project files, reference packages without versions:
```xml theme={null}
```
## Supported Files for .NET
| File Examples |
| ------------------------------------------------------------------------- |
| `.deps.json`, `packages.lock.json`, `Directory.Packages.props`, `.csproj` |
If your lockfile is missing, SCA scanning might only detect partial or incorrect versions of NuGet packages. Lockfiles ensure precise dependency resolution.
Use Directory.Packages.props (NuGet central package management) for an even cleaner approach to pinned versions across multiple projects.
# How to Launch a Scan on Java/Scala/Kotlin
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-java-scala-kotlin
Optimize SCA scanning by using Gradle lockfiles and pinned versions for Java, Scala, or Kotlin builds.
For **Gradle-based** projects in Java, Scala, or Kotlin, generating a `gradle.lockfile` ensures consistent dependencies that CybeDefend can accurately scan. SBT-based Scala projects can also pin versions in `.sbt.lock` or a centralized method.
## Gradle Lockfiles
1. **Enable Gradle Locking**\
You can enable dependency locking in one of two ways:
**Option A**: In your `gradle.properties`, set:
```properties theme={null}
systemProp.gradle.useLocks=true
systemProp.gradle.dependencyVerification=strict
```
**Option B**: Modify your `build.gradle` file to add:
```groovy theme={null}
configurations.all {
resolutionStrategy.activateDependencyLocking()
}
```
Or for Kotlin DSL projects (`build.gradle.kts`):
```kotlin theme={null}
configurations.all {
resolutionStrategy.activateDependencyLocking()
}
```
2. **Generate Lockfiles**\
Run one of these commands:
```bash theme={null}
./gradlew dependencies --write-locks
```
or
```bash theme={null}
./gradlew resolveAndLockAll
```
This creates lockfiles in the `gradle/dependency-locks` directory.
3. **Commit**\
Check in the lockfiles so that your entire team and CybeDefend sees fixed dependency versions.
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
## SBT Lock for Scala
1. **Add the sbt-lock Plugin**\
In your `project/plugins.sbt`, add:
```scala theme={null}
addSbtPlugin("software.purpledragon" % "sbt-dependency-lock" % "1.5.1")
```
2. **Generate the Lockfile**\
Run:
```bash theme={null}
sbt dependencyLockWrite
```
This creates a `build.sbt.lock` or `dependencies.sbt.lock` file.
3. **Commit the Lockfile**\
Add this file to your repository to maintain pinned Scala library versions.
## Supported Files
| Lang | File Examples |
| ---------- | ----------------------------------------------------------------------- |
| **Java** | `gradle.lockfile`, `pom.xml`, `.jar`, `.war`, `.ear` |
| **Scala** | `build.sbt`, `plugins.sbt`, `.sbt.lock`, `dependencies.scala`, `.scala` |
| **Kotlin** | `gradle.lockfile`, `.kts` files (Gradle Kotlin DSL) |
Some older build tools or frameworks may require additional steps. The primary goal is to produce a stable lock or pinned version set for each submodule.
For multi-module Gradle projects, run ./gradlew :module:dependencies --write-locks for each module to ensure all dependencies are properly locked.
# How to Launch a Scan on a Maven Project
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-maven
Best practices for configuring Maven to be scanned by CybeDefend, with an emphasis on lockfile-like mechanisms.
If your Java application uses **Maven**, CybeDefend can detect vulnerabilities in your pom.xml, `.jar`, `.war`, or `.ear` files. However, you'll get the **best** results if you explicitly pin or lock dependencies to stable versions.
## Recommended Steps
1. **Pin Versions in pom.xml**\
Make sure each dependency in `` includes a specific version number:
```xml theme={null}
org.example
example-library
1.2.3
```
2. **Use a Lockfile-Like Approach**\
While Maven doesn't have an official universal lockfile, certain plugins or pinned version strategies replicate the effect.
* **Dependency Management**: Use `` in your parent pom to centralize version definitions.
* **Versions Maven Plugin**: Tools like `versions:lock-snapshots` or `versions:use-releases` can help freeze your dependencies.
* **Maven Enforcer**: Consider using the enforcer plugin to ban dependency version ranges.
3. **Generate Flattened POM**\
The Maven Flatten Plugin creates a simplified POM with all versions resolved:
```xml theme={null}
org.codehaus.mojo
flatten-maven-plugin
1.3.0
resolveCiFriendliesOnly
flatten
```
4. **Store pom.xml in Repo**\
This ensures that the entire team, and CybeDefend, see the exact dependency versions.
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
For advanced usage, some teams generate `.flattened-pom.xml` or use ephemeral lock plugins. The key is to produce a stable, pinned set of dependencies that CybeDefend can accurately scan.
## Supported Files for Java/Maven
| File Examples |
| ------------------------------------------------------- |
| `pom.xml`, `.jar`, `.war`, `.ear`, `.flattened-pom.xml` |
Remember to re-run Maven and commit any updated metadata or flattened POM files if your plugin of choice modifies them.
Once your Maven project is ready, create a new project in CybeDefend referencing this codebase. SCA scanning will detect vulnerabilities in pinned dependencies more accurately.
# How to Launch a Scan on a Node Project
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-by-project-type/how-to-launch-scan-node
Use package-lock.json, yarn.lock, or pnpm-lock.yaml to improve security scanning for Node apps in CybeDefend.
Node.js offers various package managers—npm, Yarn, PNPM, Bun—that produce lockfiles. CybeDefend's SCA scanner relies on these files to accurately identify your app's dependencies.
## Lockfile Examples
1. **npm**: `package-lock.json` or `npm-shrinkwrap.json`
2. **Yarn**: `yarn.lock`
3. **PNPM**: `pnpm-lock.yaml`, `pnpm-lock.yml`
4. **Bun**: `bun.lock`, `bun.lockb`
5. **Deno**: `deno.lock`
## Why You Should Use Lockfiles
Using a **lockfile** is critical for secure and predictable builds. A lockfile contains a **fixed version** and a **hash** for each dependency and sub-dependency in your project.
1. **Supply Chain Protection**\
Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
2. **Predictable Builds**\
Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
3. **Performance Gains**\
With dependency versions locked, build tools skip the usual resolution step, making builds faster.
Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.
## Recommended Steps
1. **Install Dependencies**\
e.g., `npm install`, `yarn install`, `pnpm install`, or `bun install`.
2. **Commit the Generated Lockfile**\
This ensures your entire dev team and CybeDefend use identical dependencies.
3. **Avoid Manual Edits**\
Let the package manager handle the lockfile; do not modify it by hand.
## Deno Projects
For **Deno** projects, you can generate a lockfile with:
```bash theme={null}
deno cache --lock=deno.lock --lock-write your_script.ts
```
After generating the lockfile, commit it to your repository for CybeDefend to scan.
## Supported Files for Node
| File Examples |
| ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `npm-shrinkwrap.json`, `yarn.lock`, `pnpm-lock.yaml`, `bun.lock`, `bun.lockb`, `deno.lock`, `libman.json`, `package.json`, `package-lock.json` |
Pin or lock versions in dependencies rather than devDependencies if you want to ensure full coverage for production packages.
# Code Repository Scanning
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-options/code-repository-scanning
Discover how the CybeDefend Engine unifies results from multiple scanners.
CybeDefend offers a **multi-layered security** solution across your codebase, infrastructure, and third-party dependencies. We combine:
1. **CybeDefend Engine** – Aggregates and cross-references results from multiple open-source and proprietary scanners, minimizing duplicates and noise.
![CybeDefend Multi-Layer Security]()
***
## Why Use CybeDefend?
* **Unified Scanning**: The CybeDefend Engine merges findings from different tools into a single, concise view.
* **Reduced Noise**: Duplicate or overlapping vulnerabilities are identified and consolidated, preventing alert overload.
***
## 1. Static Application Security Testing (SAST)
**SAST** inspects your **source code** to catch vulnerabilities early in the development process. CybeDefend unifies open-source scanners (e.g., **Semgrep**) under the **CybeDefend Engine**.
### Supported Languages
| Language | Primary Scanners |
| -------------- | ------------------------------------ |
| **Go** | CybeDefend Engine & Rules + Opengrep |
| **Python** | CybeDefend Engine & Rules + Opengrep |
| **Java** | CybeDefend Engine & Rules + Opengrep |
| **JavaScript** | CybeDefend Engine & Rules + Opengrep |
| **C** | CybeDefend Engine & Rules + Opengrep |
| **C++** | CybeDefend Engine & Rules + Opengrep |
| **C#** | CybeDefend Engine & Rules + Opengrep |
| **PHP** | CybeDefend Engine & Rules + Opengrep |
| **Ruby** | CybeDefend Engine & Rules + Opengrep |
| **Rust** | CybeDefend Engine & Rules |
**Rust** is not supported by Opengrep — CybeDefend covers it with its own dedicated security rules, run by the CybeDefend Engine.
![IAC Security Analysis]()
***
## 2. Infrastructure as Code (IAC) Security
IAC scanning ensures that **cloud** and **container** configurations adhere to best practices. The **CybeDefend Engine** works with scanners like **Checkov**, **Trivy**, and **KICS** to identify misconfigurations. Unlike SAST, enabling AI Mode for IAC does **not** provide line-level dataflow (which is primarily for code), but the Engine still handles **intelligent vulnerability matching** and deduplication.
### Supported Technologies
| Category | IAC Types | Scanning Tools |
| ------------------------ | -------------------------------------------------------------- | ---------------------------------------- |
| **Cloud Configurations** | Terraform, CloudFormation, AWS CDK, Azure RM, Helm, Kubernetes | CybeDefend Engine + Checkov, KICS, Trivy |
| **Serverless Security** | AWS Lambda, Azure Functions | CybeDefend Engine + Checkov, KICS |
| **Container Security** | Dockerfiles, Docker Compose | CybeDefend Engine + Trivy, KICS |
| **OpenAPI / gRPC** | .json, .yaml, .proto | CybeDefend Engine + KICS |
![IAC Security Analysis]()
IAC misconfigurations can lead to severe breaches. The CybeDefend Engine identifies issues in your code, saving you from manually piecing together results from multiple scanners.
***
## 3. Software Composition Analysis (SCA)
SCA detects vulnerabilities in **third-party libraries** and **open-source dependencies**. CybeDefend uses the **CybeDefend Engine** combined with **[Google OSV](https://osv.dev)** — the open-source vulnerability database maintained by Google — to identify known flaws in your dependencies. Rather than relying on a single feed, OSV **continuously aggregates and normalizes** advisories from **35+ language ecosystems and OS/distribution security trackers** into one source of truth. GitHub Advisories (GHSA) is one of the many databases OSV consolidates, so earlier coverage is fully retained — and considerably expanded.
### SCA Scanning Tools
| Engine | External Advisory Source |
| --------------------- | ------------------------------------------- |
| **CybeDefend Engine** | **Google OSV** ([osv.dev](https://osv.dev)) |
### Vulnerability Data Sources (Google OSV)
CybeDefend draws its SCA intelligence from **[Google OSV](https://osv.dev)** (Open Source Vulnerabilities), an open, distributed database that **aggregates and normalizes** advisories from across the open-source world into a single schema. This spans **language package registries** (npm, PyPI, Maven, NuGet, Go, crates.io, RubyGems, Packagist, Hex, and more) and **OS / distribution and container-image feeds** (Debian, Ubuntu, Alpine, Red Hat, SUSE, Rocky Linux, Chainguard, Wolfi, and many others) — with GitHub Advisories (GHSA) folded in as just one of the contributing sources.
**These sources are aggregated continuously and grow every day.** New advisories — and entirely new ecosystems — are added to OSV constantly, and CybeDefend ingests them on an ongoing basis, so your scans always reflect the latest known vulnerabilities with no action on your side. The counts below are a **snapshot from [osv.dev](https://osv.dev), July 2026** — over **767,000** advisories across **38 sources** — and only trend upward. Check [osv.dev](https://osv.dev) for live figures.
| Ecosystem | Advisories | Ecosystem | Advisories |
| ----------- | ---------: | ---------------------------- | ---------: |
| AlmaLinux | 5,242 | Alpaquita | 11,478 |
| Alpine | 4,350 | Android | 3,403 |
| Azure Linux | 12,016 | BellSoft Hardened Containers | 572 |
| Bitnami | 8,264 | Chainguard | 9,229 |
| CleanStart | 1,652 | crates.io | 2,561 |
| Debian | 59,722 | Echo | 6,669 |
| GIT | 93,379 | GitHub Actions | 54 |
| Go | 8,148 | Hackage | 32 |
| Hex | 182 | Julia | 989 |
| Linux | 25,415 | Mageia | 6,011 |
| Maven | 6,690 | MinimOS | 86,925 |
| npm | 222,154 | NuGet | 1,770 |
| openEuler | 7,186 | openSUSE | 13,449 |
| OSS-Fuzz | 3,958 | Packagist | 6,664 |
| PyPI | 22,362 | Red Hat | 21,177 |
| Rocky Linux | 3,619 | Root | 17,380 |
| RubyGems | 4,550 | SUSE | 21,326 |
| SwiftURL | 58 | TuxCare | 5,651 |
| Ubuntu | 57,187 | Wolfi | 6,451 |
*The counts above reflect the **advisory data** OSV provides. Which ecosystems CybeDefend **parses from your project** — for dependency detection, license lookup, and exploitable paths — is listed under [Feature Support by Ecosystem](#feature-support-by-ecosystem) below.*
### Files & Package Managers
Below is a non-exhaustive list of **key files** we inspect:
| Language/Framework | File Examples |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Node** | `npm-shrinkwrap.json`, `yarn.lock`, `pnpm-lock.yaml`, `pnpm-lock.yml`, `bun.lock`, `deno.lock`, `libman.json`, `package.json`, `package-lock.json` |
| **Java** | `gradle.lockfile`, `build.gradle`, `pom.xml` |
| **Swift** | `Package.resolved`, `Podfile.lock` |
| **.NET (NuGet)** | `packages.lock.json`, `Packages.props`, `.csproj`, `.vbproj`, `.fsproj`, `.nuspec` |
| **Kotlin** | `gradle.lockfile` |
| **Elixir** | `mix.lock` |
| **C/C++** | `conan.lock` |
| **Scala** | `build.sbt`, `plugins.sbt`, `dependencies.scala`, `libraries.scala`, `.sbt.lock` |
| **Clojure** | `deps.edn` |
| **Generic** | `composer.json`, `requirements.txt`, `Pipfile`, `Pipfile.lock`, `poetry.lock`, `pyproject.toml`, `Gemfile`, `Gemfile.lock`, `Cargo.toml`, `Cargo.lock`, `go.mod`, `pubspec.yaml`, `pubspec.lock`, `packages.config`, `Package.swift`, `rebar.config`, `rebar3.config`, `rebar.lock`, `rebar3.lock`, `.gemspec`, `.yml`, `.yaml` |
Files like `bun.lockb` (binary Bun lockfile), `.jar` / `.war` / `.ear` (Java archives), and `.deps.json` (.NET build output) are **not supported** for SCA parsing. Use their text-based equivalents instead (`bun.lock`, `pom.xml` / `build.gradle`, `packages.lock.json`).
### Feature Support by Ecosystem
Not all ecosystems support every SCA feature. The table below shows which features are available for each ecosystem:
| Ecosystem | Dependency Detection | License Lookup | Exploitable Path |
| ---------------------------------- | :------------------: | :------------: | :--------------: |
| **npm / Yarn / pnpm / Bun / Deno** | ✅ | ✅ | ✅ |
| **pip / Poetry / Pipenv** | ✅ | ✅ | ✅ |
| **Maven / Gradle** (Java, Kotlin) | ✅ | ✅ | ✅ |
| **Scala** | ✅ | ✅ | ✅ |
| **Go modules** | ✅ | ✅ | ✅ |
| **NuGet** (.NET) | ✅ | ✅ | ✅ |
| **Composer** (PHP) | ✅ | ✅ | ✅ |
| **Cargo** (Rust) | ✅ | ✅ | ✅ |
| **Swift PM / CocoaPods** | ✅ | ✅ | ✅ |
| **Pub** (Dart/Flutter) | ✅ | ✅ | ✅ |
| **Hex** (Elixir/Erlang) | ✅ | ✅ | ✅ |
| **RubyGems** (Ruby) | ✅ | ✅ | ✅ |
| **Clojure** (Clojars) | ✅ | ✅ | ✅ |
| **Conan** (C/C++) | ✅ | ✅ | ✅ |
| **GitHub Actions** | ✅ | ✅ | ✅ |
| **Rebar** (Erlang) | ✅ | ✅ | ✅ |
If you use special file names or custom project layouts, you can configure file-patterns in the CybeDefend dashboard to ensure they are recognized and scanned.
***
## 4. Secret Scanning
**Secret scanning** detects hardcoded secrets — API keys, tokens, passwords, private keys, and other credentials — exposed in your source code. CybeDefend runs **Gitleaks** under the **CybeDefend Engine** to surface these findings alongside your SAST, SCA, and IaC results in a single view.
### Secret Scanning Tools
| Engine | Scanning Tool |
| --------------------- | ------------- |
| **CybeDefend Engine** | Gitleaks |
***
**Related:** [Scan Parameters](/latest/code-scanning/scanning-options/scan-parameters) · [Create a Project](/latest/get-started/project-management/create-project) · [Cybe Analysis](/latest/agent-ai-integration/cybe-analysis-detail)
# .cybeignore Exclusion File
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-options/cybedefend-ignore-file
Exclude files from SAST reports with a .cybeignore file using gitignore syntax
## Overview
The `.cybeignore` file lets you exclude specific files or directories from SAST vulnerability reports. It uses the same syntax as `.gitignore`, so it is familiar and easy to use.
To suppress a single finding on one precise line instead of a whole file, use an [inline `cybedefend-ignore` comment](/latest/code-scanning/scanning-options/inline-ignore-comments).
## How It Works
Create a `.cybeignore` file in your project's root directory to define exclusion patterns. Vulnerabilities found in matching files are automatically filtered from scan results.
## Where CybeDefend Looks
The scanner reads the **first** file it finds, in this order:
| Order | Path | Status |
| ----- | -------------------- | ------------------------------------- |
| 1 | `.cybeignore` | **Recommended** |
| 2 | `.cybedefend` | Deprecated — still read |
| 3 | `.cybedefend/ignore` | Use when `.cybedefend` is a directory |
**`.cybedefend` is deprecated.** It still works and nothing breaks today, but it collides with the `.cybedefend/` directory that [VibeDefend](/latest/agent-ai-integration/vibedefend) creates for `config.json` — a single path cannot be both a file and a directory. Rename your file to `.cybeignore`; the contents do not change.
If your repository is linked with VibeDefend, you already have a `.cybedefend/` **directory**. You have two options, and they behave identically:
* Put your patterns in `.cybeignore` at the project root (recommended), or
* Put them in `.cybedefend/ignore`, alongside `config.json`.
## Usage
### Creating a .cybeignore File
Create a file named `.cybeignore` in your project root:
```bash theme={null}
# Ignore test files
**/test/**
**/tests/**
**/*_test.py
**/*_test.go
# Ignore dependencies
node_modules/
vendor/
.venv/
# Ignore specific directories
**/examples/**
**/demo/**
# Ignore by extension
*.min.js
*.log
```
### Migrating from .cybedefend
Renaming the file is the whole migration — the syntax is unchanged:
```bash theme={null}
git mv .cybedefend .cybeignore
```
If you use VibeDefend and the root path is taken by the `.cybedefend/` directory, move your patterns inside it instead:
```bash theme={null}
mv my-patterns.txt .cybedefend/ignore
```
### Supported Patterns
The syntax is identical to `.gitignore`:
| Pattern | Description | Example |
| ------------ | ----------------------- | --------------------- |
| `file.txt` | Ignore specific file | `secrets.txt` |
| `*.ext` | Ignore by extension | `*.log` |
| `dir/` | Ignore directory | `node_modules/` |
| `**/pattern` | Recursive matching | `**/bad/**` |
| `!file.txt` | Negation (don't ignore) | `!important.log` |
| `#comment` | Comment line | `# This is a comment` |
Negation is the tool for excluding a whole class while keeping one member of it under review:
```bash theme={null}
# Exclude every spec file…
**/*.spec.ts
# …except this one, which carries a credential whose origin is still unconfirmed
!services/export/redact-secrets.spec.ts
```
## Scope
`.cybeignore` filters every finding produced by the SAST/IaC scanner binary:
| Scan type | Filtered by `.cybeignore`? |
| ---------- | -------------------------- |
| SAST | Yes |
| IaC | Yes |
| **Secret** | **Yes** |
| CI/CD | Yes |
| SCA | No — separate scanner |
| Container | No — separate scanner |
**Excluding a file also hides its secret findings.** Gitleaks runs as a second pass inside the same scanner and shares the same exclusion list, so a path you exclude here stops being reported for hardcoded credentials too — including credentials a *later* commit adds to that file.
This matters most for the patterns people reach for first. `**/*.spec.ts` or `tests/` will silence Gitleaks across your whole test suite, which is exactly where fixture credentials — and the occasional real one pasted in by mistake — tend to live.
When only a few findings in a file are false positives, prefer [inline `cybedefend-ignore` comments](/latest/code-scanning/scanning-options/inline-ignore-comments) over listing the whole file here: the exclusion stays scoped to the lines you reviewed, and the rest of the file keeps being scanned.
## Common Use Cases
### Ignore Test Code
```
# .cybeignore
**/test/**
**/tests/**
**/__tests__/**
*.spec.js
*.test.js
**/*_test.py
```
### Ignore Third-Party Code
```
# .cybeignore
node_modules/
vendor/
third_party/
.venv/
```
### Ignore Demo/Example Code
```
# .cybeignore
**/examples/**
**/demo/**
**/samples/**
docs/code-examples/**
```
### Ignore Configuration Templates
```
# .cybeignore
*.example.yml
*.template.json
config/sample_*.py
```
## Best Practices
Use `.cybeignore` responsibly. Don't ignore real vulnerabilities in production code.
### Exclude Files, Not Findings You Dislike
A file-level exclusion is right when the **whole file** is out of scope for SAST — a test fixture, a vendored dependency, a demo. When a finding is a false positive but the file also holds production code, use an [inline `cybedefend-ignore` comment](/latest/code-scanning/scanning-options/inline-ignore-comments) instead, so the rest of the file stays under review.
### Document Your Exclusions
Always add comments explaining why files are excluded:
```
# .cybeignore
# DEPENDENCIES
# Third-party code managed by maintainers
node_modules/
vendor/
# TEST CODE
# Tests intentionally contain unsafe code for testing
**/test/**
# KNOWN FALSE POSITIVES
# Ticket #123: Custom validation used
src/legacy/auth_handler.py
```
### Include in Code Reviews
* Add `.cybeignore` to your repository
* Review changes in pull requests
* Regularly audit exclusion patterns
### Verify What You Wrote
`.cybeignore` uses the gitignore engine, so git itself can check your patterns before you commit them:
```bash theme={null}
git ls-files | git -c core.excludesFile=.cybeignore check-ignore --no-index --stdin
```
Every path it prints is a file that will drop out of your SAST results. If a production file appears in that list, your pattern is too broad.
### Monitor Impact
Check scan logs to see which file was loaded and how many vulnerabilities were filtered:
```
[IgnoreFilter] loaded exclusion patterns from .cybeignore
Filtered out 12 vulnerabilities based on .cybeignore patterns
After filtering: 45 vulnerabilities to report
```
## Troubleshooting
### Patterns Not Matching
* Use `**/` for recursive matching: `**/bad/**`
* Ensure correct path separators (always `/`)
* Check that `.cybeignore` is in the project root
* Review scan logs for path details
### File Not Found
* Verify `.cybeignore` is included in your repository — it must be committed, not gitignored
* Check file permissions
* Ensure the file is at the project root level
* If you have a `.cybedefend/` **directory**, the legacy root file cannot exist; use `.cybeignore` or `.cybedefend/ignore`
### Nothing Is Being Filtered
Look for the loader line in your scan logs. `[IgnoreFilter] no .cybeignore file found` means no candidate was readable at all — most often the file was never committed, or it sits in a subdirectory rather than the project root.
## Example Configuration
Here's a comprehensive example:
```
# .cybeignore
# ============================================
# THIRD-PARTY DEPENDENCIES
# ============================================
node_modules/
vendor/
.venv/
third_party/
# ============================================
# TEST CODE
# ============================================
**/test/**
**/tests/**
**/__tests__/**
**/*_test.py
**/*_test.go
*.spec.js
*.test.js
# ============================================
# EXAMPLES & DOCUMENTATION
# ============================================
**/examples/**
**/demo/**
docs/vulnerable_examples/**
# ============================================
# BUILD ARTIFACTS
# ============================================
dist/
build/
*.min.js
*.bundle.js
# ============================================
# CONFIGURATION TEMPLATES
# ============================================
*.example.yml
*.template.json
config/sample_*.py
```
The `.cybeignore` file is processed during scanning. Excluded vulnerabilities won't appear in your reports or affect your project metrics.
# Inline Ignore Comments
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-options/inline-ignore-comments
Suppress a single finding directly in your source code with a cybedefend-ignore comment
## Overview
The `cybedefend-ignore` directive lets you silence a specific finding by adding a comment in your source code, on the vulnerable line or on the line directly above it. It is the right tool for confirmed false positives: the directive lives next to the code, is reviewed in pull requests, and keeps the finding silenced on every subsequent scan.
Use the [`.cybeignore` exclusion file](/latest/code-scanning/scanning-options/cybedefend-ignore-file) when you want to exclude whole files or directories. Use an inline comment when you want to exclude one precise line.
## Supported Scanners
The directive is applied to every finding produced by the code scanners:
| Scanner type | Rule ID |
| ------------ | ---------------------------------------------------- |
| SAST | Rule identifier shown on the finding in the platform |
| IaC | Rule identifier shown on the finding in the platform |
| Secrets | Rule identifier shown on the finding in the platform |
Use the rule identifier displayed on the finding when writing a scoped directive.
SCA, container and AI-BOM findings are not attached to a source line and cannot be suppressed with an inline comment.
## Syntax
The directive is matched as a plain token, so it works with any comment style: `//`, `#`, `/* */`, ``, `--`, etc. Matching is case-insensitive.
```
cybedefend-ignore
cybedefend-ignore:
cybedefend-ignore[]:
cybedefend-ignore[,]:
```
| Form | Effect |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `cybedefend-ignore` | Blanket ignore: suppresses every finding reported on that line, whatever the rule |
| `cybedefend-ignore[RULE]` | Scoped ignore: suppresses only findings from the listed rule(s). Other rules on the same line are still reported |
| `: reason` | Optional free text. Always add one so reviewers know why the finding is a false positive |
## Placement
The scanner checks two lines for each finding: the vulnerable line itself and the line directly above it.
### On the same line
```javascript theme={null}
const query = `SELECT * FROM users WHERE id = ${id}`; // cybedefend-ignore: id is validated as an integer upstream
```
### On the line above
```python theme={null}
# cybedefend-ignore[]: table name comes from a static allowlist
cursor.execute(f"SELECT * FROM {table} WHERE id = %s", (user_id,))
```
Only the line directly above is checked. A directive two lines above the finding, or a directive followed by a blank line, has no effect.
## Examples by Language
### JavaScript / TypeScript
```javascript theme={null}
// cybedefend-ignore: content is escaped by the template engine
res.send(renderedHtml);
```
### Python
```python theme={null}
subprocess.run(cmd, shell=True) # cybedefend-ignore[]: cmd is a hard-coded constant
```
### Go
```go theme={null}
// cybedefend-ignore: file path is built from an internal enum, not user input
data, err := os.ReadFile(path)
```
### Terraform (IaC)
```hcl theme={null}
resource "aws_s3_bucket" "public_assets" {
bucket = "my-public-assets"
# cybedefend-ignore[]: this bucket intentionally serves public static assets
acl = "public-read"
}
```
### YAML / Kubernetes (IaC)
```yaml theme={null}
containers:
- name: app
# cybedefend-ignore: dev-only manifest, never deployed to production
securityContext:
privileged: true
```
### Secrets
```javascript theme={null}
// cybedefend-ignore[]: sample value used in unit tests
const API_KEY = "test-0000000000000000000000000000";
```
## Behaviour
* **Every scan type**: the directive is honoured on both full scans and diff scans.
* **Persistent**: because the directive is committed with the code, the finding stays suppressed on all later scans until the comment is removed.
* **Silent**: suppressed findings do not appear in the platform, in reports, or in project metrics.
* **Safe by default**: if the scanner cannot read the source file, the finding is kept and reported.
Scan logs record how many findings were dropped:
```
Ignoring vulnerability in src/db/query.js (inline cybedefend-ignore directive)
Filtered out 3 vulnerabilities via inline cybedefend-ignore directives
After filtering: 42 vulnerabilities to report
```
## Best Practices
Prefer a scoped directive (`cybedefend-ignore[RULE]`) over a blanket one. A blanket ignore also hides any new rule that later fires on the same line.
* **Always give a reason.** A bare `cybedefend-ignore` tells a reviewer nothing. Explain why the finding does not apply.
* **Review in pull requests.** Treat a new ignore directive like a security decision. Reviewers should be able to verify the justification.
* **Audit periodically.** Search your codebase for `cybedefend-ignore` and remove directives that no longer apply.
* **Do not use it to hide real issues.** For findings that are true positives but accepted, mark them as such in the platform instead so they remain visible.
## Other Ignore Comments
Ignore comments from other security tools have no effect on CybeDefend scans. Only `cybedefend-ignore` is honoured, so suppressions are consistent across all scanner types.
## Troubleshooting
### The finding is still reported
* Check that the comment is on the vulnerable line or the line directly above it.
* If you used a scoped form, verify the rule ID matches exactly the one shown on the finding.
* Confirm the change was committed and included in the scanned branch.
### Another finding disappeared unexpectedly
A blanket `cybedefend-ignore` suppresses every rule on that line. Switch to the scoped form to keep other findings visible.
# Scan Project Parameters
Source: https://docs.cybedefend.com/latest/code-scanning/scanning-options/scan-parameters
Configure your scan settings: choose scanner types, enable fast scanning, and set vulnerability severity levels.
In CybeDefend, you can customize your scans by adjusting key parameters in **Project Settings** → **Scanning**. This guide covers the essential scan configuration options.
![Scan Settings Overview]()
***
## Scanner Types
CybeDefend supports multiple security scanning methods. Enable the scanners that match your project needs:
### SAST (Static Application Security Testing)
Analyzes source code for security vulnerabilities before runtime.
### SCA (Software Composition Analysis)
Inspects open-source dependencies and libraries for known vulnerabilities.
### IaC (Infrastructure as Code)
Detects misconfigurations in infrastructure definitions (Terraform, Kubernetes, Docker, etc.).
### Container
Scans container images for vulnerabilities in base images, packages, and configurations.
![Scanning Methods]()
We recommend **enabling all scanners** for comprehensive security coverage across your entire stack.
***
## Vulnerability Severity Levels
Select which **severity levels** to include in your scan results:
* **Critical**: Immediate security risks requiring urgent action
* **High**: Serious vulnerabilities that should be prioritized
* **Medium**: Moderate security issues to address
* **Low**: Minor vulnerabilities or potential improvements
![Vulnerability Severity Choice]()
Unchecked severity levels will not appear in your results, allowing you to focus on the most critical findings.
This setting filters scan results only—it does not impact scanning time or depth.
***
## AI-Powered Features
For advanced vulnerability analysis and remediation, CybeDefend offers AI agent features that can be enabled in project settings:
* **Cybe Analysis**: Intelligent false positive detection and vulnerability triage
* **Cybe AutoFix**: Automated fix generation with pull/merge requests
* **Cybe Security Champion**: Interactive security guidance and chatbot
Learn more about configuring AI features in the [Agent & AI Integration](/latest/agent-ai-integration/cybe-analysis-detail) section.
***
## Saving Your Configuration
After adjusting scan parameters:
1. **Save your settings** in the project configuration
2. **Trigger a new scan** manually or wait for automatic scanning
3. **Review results** in your project dashboard
Balance **scan coverage** and **speed** based on your development stage. Use fast scanning for rapid iterations, and comprehensive scanning for releases.
# Container Image Scanning
Source: https://docs.cybedefend.com/latest/container-scanning/container-image-scanning
Scan container images for vulnerabilities from public registries or private repositories to secure your containerized applications.
CybeDefend's **Container Image Scanning** provides comprehensive security analysis for your Docker containers and images. Whether you're using public images from Docker Hub or private images from your organization's registry, our scanning engine identifies vulnerabilities in your container layers and dependencies.
![Container Image Scanning]()
## Scanning Options
### Public Container Images
Scan any publicly available container image from popular registries:
* **Docker Hub**: Pull and scan any public image directly by name
* **Public Registries**: Access images from GCR, ECR, and other public repositories
* **Official Images**: Scan official language runtime images, database images, and more
* **Community Images**: Analyze community-maintained containers for security issues
### Private Container Images
Securely scan your organization's private container images:
* **Private Registries**: Connect to your private Docker registries with authentication
* **Secure Access**: Use API keys, tokens, service accounts, or cross-account IAM roles (e.g. AWS ECR) — no secret leaves your control
* **Organization Credentials**: Define registry credentials once at the organization level and link them to the projects allowed to use them
* **Organization Images**: Scan custom-built images from your CI/CD pipelines
* **Multi-Registry Support**: Connect multiple private registries simultaneously
## How Container Scanning Works
1. **Image Selection**\
Choose to scan either a public image by name or connect to your private registry to select specific images.
2. **Layer Analysis**\
Our scanner analyzes each layer of your container image, examining:
* Base operating system vulnerabilities
* Installed packages and libraries
* Application dependencies
* Configuration files
3. **Vulnerability Detection**\
Identify security issues across multiple categories:
* **CVE Vulnerabilities**: Known security vulnerabilities in packages
* **Malware Detection**: Scan for malicious code or suspicious files
* **Secrets Scanning**: Detect exposed API keys, passwords, or tokens
* **Configuration Issues**: Identify misconfigurations and security weaknesses
4. **Results & Reporting**\
Get detailed reports with:
* Vulnerability severity levels (Critical, High, Medium, Low)
* Affected packages and versions
* Remediation recommendations
* Layer-by-layer breakdown
## Scanning Process
Choose between public image scanning or connect to your private registry
Enter the image name and tag for public images, or browse your private registry
Set scanning parameters and select vulnerability types to detect
Our engine pulls and analyzes the container image layers
Access comprehensive vulnerability reports and remediation guidance
## Benefits
Identify vulnerabilities before deploying containers to production environments.
Understand which layer introduced specific vulnerabilities for targeted fixes.
Seamlessly connect to multiple public and private container registries.
Meet security compliance requirements for containerized applications.
***
**Related:** [Dockerfile Scanning](/latest/container-scanning/dockerfile-security-scanning) · [Registry Integrations](/latest/container-scanning/registry-integrations/docker-hub) · [Create a Project](/latest/get-started/project-management/create-project)
# Dockerfile Security Scanning
Source: https://docs.cybedefend.com/latest/container-scanning/dockerfile-security-scanning
Detect vulnerabilities and security issues in Dockerfile configurations and container image builds during code scanning.
CybeDefend's **Dockerfile Security Scanning** analyzes your Dockerfile configurations for security vulnerabilities, misconfigurations, and best practice violations. This scanning is automatically integrated into your regular code scanning process, ensuring container security is part of your development workflow.
## How It Works
When CybeDefend scans your codebase, it automatically detects Dockerfile files and performs comprehensive security analysis alongside your source code scanning. This integrated approach ensures both your application code and container configurations are secure.
### Automatic Detection
CybeDefend automatically identifies and scans:
* `Dockerfile` files in your repository
* Multi-stage build configurations
* Docker Compose files with build contexts
* Custom Dockerfile variants (e.g., `Dockerfile.prod`, `Dockerfile.dev`)
### Security Analysis
The scanner examines multiple aspects of your Dockerfile:
1. **Base Image Security**
* Identifies vulnerable base images
* Recommends secure alternatives
* Checks for outdated image versions
2. **Configuration Issues**
* Detects insecure configurations
* Identifies privilege escalation risks
* Finds exposed sensitive data
3. **Best Practice Violations**
* Running containers as root user
* Missing health checks
* Inefficient layer management
## Types of Issues Detected
Detection of base images with known CVEs and security vulnerabilities
Hard-coded passwords, API keys, or sensitive data in Dockerfile instructions
Containers running as root or with unnecessary elevated privileges
Exposed ports and insecure network configurations
## Integration with Code Scanning
Dockerfile scanning is seamlessly integrated into your regular code scanning workflow:
### Automatic Inclusion
* No additional configuration required
* Scans run alongside SAST, SCA, and IaC analysis
* Results appear in the same vulnerability dashboard
### Scan Triggers
* **Repository Scans**: Includes all Dockerfiles in the repository
* **CI/CD Integration**: Scans Dockerfiles in pull requests and commits
* **Manual Scans**: On-demand analysis of container configurations
### Results Integration
* Dockerfile issues appear with other security findings
* Severity levels aligned with overall vulnerability scoring
* Remediation guidance provided for each issue
Dockerfile security scanning is automatically enabled when you scan repositories containing Docker configurations. No additional setup is required beyond your regular code scanning configuration.
***
**Related:** [Container Image Scanning](/latest/container-scanning/container-image-scanning) · [IaC Security](/latest/code-scanning/scanning-options/code-repository-scanning) · [Scan Parameters](/latest/code-scanning/scanning-options/scan-parameters)
# Amazon ECR
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/amazon-ecr
Scan container images stored in Amazon Elastic Container Registry, using a cross-account IAM role or static AWS keys.
**Amazon Elastic Container Registry (ECR)** is AWS's managed Docker container registry. CybeDefend connects to ECR to list your repositories, browse image tags, and scan images for vulnerabilities.
CybeDefend supports two authentication modes:
CybeDefend assumes a **cross-account IAM role** in your AWS account. No AWS secret is ever shared — access is granted by a role you fully control and can revoke at any time.
Provide a long-lived IAM **access key ID** and **secret access key**. Simpler to set up, but the secret is stored by CybeDefend and must be rotated manually.
ECR credentials are managed at the **organization level** and linked to one or more projects. Only the projects a credential is linked to can browse its images and start scans. See [Organization credentials & project linking](#organization-credentials--project-linking).
## Option 1 — IAM role (recommended)
With this mode, CybeDefend never holds an AWS secret. You create an IAM **role** in your own AWS account whose trust policy allows **only** CybeDefend's AWS principal to assume it, gated by a unique **External ID**. At scan time, CybeDefend assumes that role, exchanges it for a **short-lived ECR token**, and hands only that token to the scanner — your AWS credentials never reach the scanning engine.
### How it works
CybeDefend issues a unique **External ID** and produces two ready-to-paste JSON policies: a **trust policy** (who may assume the role) and a **permission policy** (read-only ECR access).
You create an IAM role with that trust policy and attach the permission policy. The role lives entirely in your account.
To list images or run a scan, CybeDefend calls `sts:AssumeRole` (passing the External ID) to obtain **temporary** credentials, then calls `ecr:GetAuthorizationToken` to get a short-lived Docker login. Only that registry token is injected into the scanner pod.
### Setup
Start from your project's **Container Registries → AWS ECR** integration, pick **IAM role**, choose the **AWS region** of your registry, and click **Generate setup instructions**. CybeDefend returns the External ID, the trusted principal, and the two policies referenced below.
Keep the setup window open until you save. Each click on **Generate setup instructions** mints a **new External ID** — a role you already created in AWS will be refused until you update its trust policy with the new value.
AWS Console → **IAM** → **Roles** → **Create role** → select **Custom trust policy**, paste the trust policy JSON below, then click **Next**.
```json Trust policy (example) theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ""
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "cybedefend--"
}
}
}
]
}
```
The `Principal.AWS` value is **CybeDefend's AWS service account** (a single, shared principal). The `sts:ExternalId` condition is mandatory — it is what prevents another tenant from assuming your role (the *confused-deputy* protection). Use the exact values from the setup window.
On **Add permissions**, select nothing and click **Next**. Give the role a name (e.g. `cybedefend-ecr-scan`) and click **Create role**.
Open the role you just created → **Permissions** tab → **Add permissions** → **Create inline policy** → **JSON** tab. Paste the permission policy below, name it (e.g. `cybedefend-ecr-pull`), then create it.
```json Permission policy theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EcrAuthToken",
"Effect": "Allow",
"Action": "ecr:GetAuthorizationToken",
"Resource": "*"
},
{
"Sid": "EcrPullAndDescribe",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability",
"ecr:DescribeRepositories",
"ecr:DescribeImages"
],
"Resource": "*"
}
]
}
```
These are **read-only** ECR permissions — enough to list repositories, inspect images, and pull layers for scanning. CybeDefend never needs write access.
From the role's summary page, copy its **ARN** (e.g. `arn:aws:iam::123456789012:role/cybedefend-ecr-scan`) and paste it back into CybeDefend, then click **Save**. CybeDefend immediately verifies it can assume the role and reach ECR before storing the integration.
The 12-digit AWS account ID and the registry URL (`.dkr.ecr..amazonaws.com`) are derived automatically from the role ARN and region — you don't enter them yourself in IAM-role mode.
## Option 2 — Static AWS keys
If you prefer (or can't use cross-account roles), provide a long-lived IAM access key. CybeDefend encrypts the secret at rest and verifies it against AWS STS before storing it.
| Field | Description | Example |
| ------------------------------ | --------------------------------------- | ------------------------------------------ |
| **AWS Account ID (12 digits)** | Your 12-digit AWS account ID | `123456789012` |
| **AWS Region** | Region where your ECR registry lives | `us-east-1` |
| **Access Key ID** | AWS IAM access key ID | `AKIAIOSFODNN7EXAMPLE` |
| **Secret Access Key** | AWS IAM secret access key | `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` |
| **Description** | Optional description for the credential | `Production ECR registry` |
AWS Console → **IAM** → **Users** → **Create user**.
Attach `AmazonEC2ContainerRegistryReadOnly` — it grants exactly the ECR read/pull access CybeDefend needs.
**Security credentials** → **Create access key** → select **Application running outside AWS**.
Copy the **Access Key ID** and **Secret Access Key** and paste them into CybeDefend along with the account ID and region.
The Secret Access Key is shown only once in AWS. Copy it immediately before closing the dialog. Static keys are long-lived — rotate them regularly (every 90 days is the AWS recommendation).
## Organization credentials & project linking
ECR credentials are stored once per **organization** and then **linked** to the projects allowed to use them:
An organization admin adds the credential (IAM role or static keys) a single time, under the organization.
The same credential is linked to one or more projects. Only **linked** projects can list images and start scans with it.
Updating the credential (or switching from static keys to an IAM role) rotates it for every linked project at once.
Deleting the credential removes it everywhere; deleting a project only drops that project's link — the org credential stays.
## Security best practices
Cross-account roles avoid sharing any secret and can be revoked instantly by deleting the role or its trust.
Never remove the `sts:ExternalId` condition from the trust policy — it is what scopes the role to your tenant.
Grant only the read-only ECR actions above (or `AmazonEC2ContainerRegistryReadOnly` for static keys). Write access is never required.
If you use static keys, rotate them on a schedule and store them only in AWS — CybeDefend already encrypts them at rest.
## Troubleshooting
* Confirm the trust policy's `Principal.AWS` matches the **trusted principal** shown in the setup window.
* Confirm the `sts:ExternalId` in the trust policy is **exactly** the External ID CybeDefend generated. Regenerating the instructions creates a new External ID — update the role's trust policy if you did.
* Make sure the role still exists and the region matches your registry.
* The ARN must look like `arn:aws:iam::<12-digit-account>:role/`.
* Verify you copied the role's ARN (not the user's or the policy's) from the role summary page.
* Verify the Access Key ID and Secret Access Key are correct and still active.
* Ensure the IAM user has the `AmazonEC2ContainerRegistryReadOnly` permissions.
* Pass the image as `repository:tag` **without** the registry host — the host is derived from the credential and is prepended automatically.
* Ensure the credential can `ecr:DescribeRepositories` / `ecr:DescribeImages` for that repository.
* ECR repositories are region-specific. The region on the credential must match the registry that holds your images.
***
**Related:** [Container Image Scanning](/latest/container-scanning/container-image-scanning) · [Registry Integrations](/latest/container-scanning/registry-integrations/docker-hub) · [ECR API reference](/latest/api-reference/endpoint/ecr-container-registry/prepare-an-iam-role-based-ecr-integration)
# Azure Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/azure-container-registry
Scan container images stored in Azure Container Registry.
**Azure Container Registry (ACR)** is Microsoft Azure's managed Docker registry service. CybeDefend integrates with ACR to scan your container images using Service Principal authentication.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------------------ | ------------------------------------------------ | -------------------------------------- |
| **Login Server** | Your ACR login server URL | `myregistry.azurecr.io` |
| **Service Principal App ID** | Application (client) ID of the service principal | `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
| **Service Principal Password** | Service principal password/secret | `*****` |
| **Description** | Optional description for the registry | `Production ACR registry` |
## How to Get Azure Container Registry Credentials
### Option A: Admin User (Quick Setup)
Go to Azure Portal → **Container Registries** → Select your registry
Go to **Settings** → **Access keys** → Enable **Admin user**
Copy the **username** and **password** provided
### Option B: Service Principal (Recommended)
Create a Service Principal with the **AcrPull** or **AcrPush** role
Assign the Service Principal to your ACR with appropriate permissions
Enter the Service Principal App ID and password in CybeDefend
Using Admin User is convenient for testing but Service Principal is recommended for production environments.
## Security Best Practices
Prefer Service Principals over Admin User for production environments.
Use the minimal `AcrPull` role for scanning operations only.
Rotate Service Principal secrets regularly to minimize exposure.
When running in Azure, prefer Managed Identities for authentication.
## Troubleshooting
* Verify Service Principal App ID and password are correct
* Check if the client secret has expired
* Ensure the login server URL is correct
* Verify the Service Principal has `AcrPull` role
* Check RBAC assignments on the registry
# Docker Hub
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/docker-hub
Connect and scan container images from Docker Hub.
**Docker Hub** is the default registry for Docker containers. CybeDefend allows you to scan both public and private images using Personal Access Token authentication.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------------- | -------------------------------- | ----------------------- |
| **DockerHub Username** | Your Docker Hub username | `username` |
| **Personal Access Token** | Docker Hub Personal Access Token | `dckr_pat_xxxxxxxxxxxx` |
## How to Create a Personal Access Token in DockerHub
Go to Docker Hub → **Account Settings** → **Security** → **Access Tokens**
Create a new Access Token with a description (e.g., `cybedefend-scanner`)
Select **Read-only** permission (recommended for scanning)
Copy the token immediately and paste it in CybeDefend (you won't see it again!)
The Personal Access Token is only displayed once when created. Make sure to copy it immediately before closing the dialog.
## Security Best Practices
Create tokens with minimal permissions required for scanning operations only.
Change your access tokens periodically to minimize security risks.
Store tokens in environment variables or secret managers, never in code.
Create a separate Docker Hub account for automated scanning.
## Troubleshooting
* Verify username and token are correct
* Check if the token has expired
* Ensure the token has the required permissions
* Docker Hub has pull rate limits for free accounts
* Consider upgrading to Docker Hub Pro for higher limits
* Use authenticated pulls to get higher rate limits
# GitHub Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/github-container-registry
Scan container images stored in GitHub Container Registry (GHCR).
**GitHub Container Registry (GHCR)** is GitHub's container registry for Docker images. CybeDefend integrates with GHCR to scan public and internal container images.
**Supported Image Visibility:**
* ✅ **Public** images - Accessible to everyone
* ✅ **Internal** images - Accessible within your organization
* ❌ **Private** images - Not supported by CybeDefend
## CybeDefend Configuration
**Personal Access Token Required:** A Personal Access Token with `read:packages` scope is required to scan internal container images. Public images can be scanned without authentication.
| Field | Description | Example |
| ------------------------- | -------------------------------------------------------------------- | ---------------------------- |
| **GitHub Username** | Your GitHub username or organization | `myorg` |
| **Personal Access Token** | GitHub PAT with `read:packages` scope (required for internal images) | `ghp_xxxxxxxxxxxx` |
| **Description** | Optional description for the registry | `Production GitHub Registry` |
## How to Create a Personal Access Token (PAT) in GitHub
A Personal Access Token with the `read:packages` scope is **required** to scan internal container images. Public images can be accessed without authentication.
Go to GitHub → **Settings** → **Developer settings** → **Personal access tokens** → **Tokens (classic)**
Click **Generate new token** and select **Generate new token (classic)**
Select the required scopes for internal container images:
* ✅ `read:packages` (required for internal images)
* Optional: `write:packages` (if you need write access)
Copy the generated token and paste it in CybeDefend
The Personal Access Token is only displayed once when created. Make sure to copy it immediately before leaving the page.
## Security Best Practices
Prefer fine-grained PATs over classic tokens when possible for better security.
Only grant `read:packages` scope for scanning operations.
Always set an expiration date for your tokens to limit exposure.
Change your access tokens periodically to minimize security risks.
## Troubleshooting
* Verify the PAT has `read:packages` scope
* Check if the token has expired
* Ensure the username matches the token owner
* Verify you have access to the repository
* Check package visibility settings
* Ensure organization membership for internal packages
* Private container images are not supported by CybeDefend
* Change image visibility to **Internal** or **Public** to enable scanning
* Contact your GitHub admin to modify package visibility settings
# GitLab Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/gitlab-container-registry
Scan container images stored in GitLab's integrated container registry.
**GitLab Container Registry** provides a secure space for your Docker images. CybeDefend integrates with GitLab's registry to scan your containers for vulnerabilities.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------------ | ---------------------------- | ------------------------------------- |
| **GitLab Project ID** | Numeric project ID in GitLab | `12345` |
| **Registry URL** | GitLab registry URL | `registry.gitlab.com` |
| **Project Path** | Project path in GitLab | `username/project` or `group/project` |
| **Project Access Token** | GitLab project access token | `glpat-xxxxxxxxxxxx` |
## How to Create a Project Access Token in GitLab
Go to your GitLab project → **Settings** → **Access Tokens**
Create a new token with a name (e.g., `CybeDefend Scanner`)
Select the role: **Developer**
Select the required scopes:
* `read_api` (required to list images)
* `read_registry` (required to access the registry)
Click **Create project access token** and copy it immediately (you won't see it again!)
Paste the credentials with your project information in CybeDefend
The Project Access Token is only displayed once when created. Make sure to copy it immediately before closing the dialog.
## Security Best Practices
Prefer project access tokens over personal tokens for better security isolation.
Only grant `read_api` and `read_registry` scopes for scanning.
Always set an expiration date for your tokens to limit exposure.
Use Reporter role instead of Developer when only read access is needed.
## Troubleshooting
* Verify token has both `read_api` and `read_registry` scopes
* Check if the token has expired
* Ensure the registry URL is correct
* Verify the project ID is correct
* Check project visibility settings
* Ensure registry is enabled for the project
# Google Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/google-container-registry
Scan container images stored in Google Container Registry.
**Google Container Registry (GCR)** is Google Cloud's managed Docker registry service. CybeDefend integrates with GCR to scan your container images using service account authentication.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------------------ | ---------------------------------------- | ---------------------------------- |
| **GCP Project ID** | Your Google Cloud project ID | `my-gcp-project-123` |
| **Registry Hostname** | GCR hostname for your region | `gcr.io (Global/US)` |
| **Service Account Key (JSON)** | Full JSON content of service account key | `{"type": "service_account", ...}` |
### Available Registry Hostnames
| Hostname | Region |
| ------------- | ---------------------- |
| `gcr.io` | Global / United States |
| `us.gcr.io` | United States |
| `eu.gcr.io` | Europe |
| `asia.gcr.io` | Asia |
## How to Create a Service Account Key in GCP
Go to GCP Console → **IAM & Admin** → **Service Accounts**
Create a new service account or select an existing one
Grant the role **Storage Object Viewer** (read access) or **Storage Admin** (read/write)
Create a new key in **JSON format** and download it
Paste the complete JSON content in CybeDefend
The service account key JSON file contains sensitive credentials. Store it securely and never commit it to version control.
## Security Best Practices
Use `Storage Object Viewer` role for read-only access to images.
Rotate service account keys regularly to minimize security risks.
Prefer Workload Identity over service account keys when possible.
Enable Cloud Audit Logs for monitoring and compliance.
## Troubleshooting
* Verify the JSON key is valid and complete
* Check if the service account has been deleted or disabled
* Ensure the project ID matches your registry
* Verify the service account has `Storage Object Viewer` role
* Check if Container Registry API is enabled
# Harbor Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/harbor
Scan container images stored in Harbor registry.
**Harbor** is an open-source enterprise container registry. CybeDefend integrates with Harbor to scan your container images using robot account authentication.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------ | -------------------------------- | ---------------------------- |
| **Harbor URL** | Full URL of your Harbor instance | `https://harbor.example.com` |
| **Harbor Project** | Name of the Harbor project | `my-project` |
| **Robot Username** | Robot account username | `robot$my-project+deploy` |
| **Robot Token** | Robot account token | `*****` |
| **Description** | Optional description | `Production Harbor Registry` |
## Required Robot Account Permissions
| Resource | Permission |
| -------------- | ---------------- |
| **Artifact** | List, Read |
| **Label** | List, Read |
| **Project** | Read |
| **Repository** | List, Pull, Read |
| **Tag** | List |
## How to Configure Harbor Container Registry
Connect to your Harbor instance and navigate to your project
Go to **Robot Accounts** and create a new robot account with read access
Configure the robot account permissions as listed above for scanning access
Copy the robot username (e.g., `robot$project+name`) and the generated token
Enter your Harbor URL, project name, robot username, and token in CybeDefend
The robot token is only displayed once when created. Make sure to copy it immediately before closing the dialog.
## Security Best Practices
Prefer robot accounts over personal credentials for automated scanning.
Grant only the required permissions listed above for security.
Configure robot account expiration dates to limit exposure.
Always use TLS for Harbor connections to encrypt data in transit.
## Troubleshooting
* Verify robot username format: `robot$project+name`
* Check if the robot account has expired
* Ensure the Harbor URL is correct
* Verify robot account has the required permissions
* Check project visibility settings
# JFrog Artifactory
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/jfrog-artifactory
Scan container images stored in JFrog Artifactory.
**JFrog Artifactory** is a universal artifact repository manager that supports Docker registries. CybeDefend integrates with JFrog Artifactory to scan your container images using access token authentication.
## CybeDefend Configuration
| Field | Description | Example |
| ------------------------- | ------------------------------- | --------------------------------------- |
| **JFrog Artifactory URL** | Full URL of your JFrog instance | `https://company.jfrog.io` |
| **Docker Repository Key** | Docker repository key name | `docker-local` |
| **Username** | Artifactory username | `admin` |
| **Access Token** | Access token for authentication | `*****` |
| **Description** | Optional description | `Production JFrog Artifactory Registry` |
## How to Configure JFrog Artifactory Container Registry
Connect to your JFrog Artifactory instance
Go to **User Management** → **Access Tokens** and create a new token
Ensure the token has read access to your Docker repositories
Enter your Artifactory URL, Docker repository key, username, and access token
Access tokens are only displayed once. Make sure to copy and store the token securely before closing the dialog.
## Security Best Practices
Prefer access tokens over API keys for better security.
Grant only read access to Docker repositories for scanning.
Configure token expiration dates to limit exposure window.
Rotate access tokens regularly (every 90 days recommended).
## Troubleshooting
* Verify username and access token are correct
* Check if the token has expired
* Ensure the Artifactory URL is correct
* Verify the Docker repository key is correct
* Check if the repository is of type Docker
# Red Hat Quay
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/red-hat-quay
Scan container images stored in Red Hat Quay registry.
**Red Hat Quay** is an enterprise-grade container registry. CybeDefend integrates with both Quay.io (SaaS) and self-hosted Quay instances to scan your container images.
## CybeDefend Configuration
| Field | Description | Example |
| --------------------------------- | ------------------------ | ----------------------------- |
| **Quay Host** | Quay hostname | `quay.io` |
| **Namespace (Organization/User)** | Organization or username | `myorganization` |
| **Robot Account Username** | Robot account username | `myorganization+deploy_robot` |
| **Robot Account Token** | Robot account token | `*****` |
| **Description** | Optional description | `Production Quay registry` |
## How to Configure Quay.io Container Registry
Connect to your Quay.io account and navigate to your repository
Go to **Repository Settings** → **Robot Accounts** and create a new robot account
Grant the robot account **read access** to your repository
Copy the robot username and token and paste them in CybeDefend
The robot token is only displayed once when created. Make sure to copy it immediately before closing the dialog.
## Security Best Practices
Prefer robot accounts over personal credentials for automated scanning.
Grant only read access for scanning operations.
Rotate robot account tokens regularly to minimize exposure.
Limit robot account access to specific repositories only.
## Troubleshooting
* Verify robot username format: `organization+robot_name`
* Check if the robot account has been deleted
* Ensure the token is correct
* Verify robot account has read access to the repository
* Check repository visibility settings
# Scaleway Container Registry
Source: https://docs.cybedefend.com/latest/container-scanning/registry-integrations/scaleway-container-registry
Scan container images stored in Scaleway Container Registry.
**Scaleway Container Registry** is Scaleway's managed Docker registry service available across multiple European regions. CybeDefend integrates with Scaleway to scan your container images using API secret key authentication.
## CybeDefend Configuration
| Field | Description | Example |
| -------------------------- | ------------------------------------------------------ | -------------------------------------- |
| **Scaleway Project ID** | Your Scaleway project UUID | `550e8400-e29b-41d4-a716-446655440001` |
| **Region** | Scaleway region where the registry is hosted | `fr-par` |
| **Namespace Name** | The name of your Scaleway Container Registry namespace | `my-namespace` |
| **Secret Key** | Your Scaleway API secret key | `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
| **Description** (optional) | A label to help identify this credential | `Production registry` |
### Available Regions
| Region Code | Location |
| ----------- | ---------------------- |
| `fr-par` | France, Paris |
| `nl-ams` | Netherlands, Amsterdam |
| `pl-waw` | Poland, Warsaw |
## How to Get Your Scaleway API Secret Key
Go to [console.scaleway.com](https://console.scaleway.com) and log in to your account.
Go to **Identity and Access Management (IAM)** → **API Keys**.
Click **Generate an API key**. Select the project scope and set the purpose to container registry access.
Copy the **Secret Key** value. This is only shown once — store it securely.
In CybeDefend, go to your organization's **Container Registry** settings and add a new Scaleway credential with the secret key.
The secret key is only displayed once when created. If you lose it, you must generate a new API key.
## How It Works
Once credentials are stored, CybeDefend can:
1. **Browse namespaces** — List all container registry namespaces in your Scaleway project
2. **List images** — View all Docker images within a namespace
3. **List tags** — See all available tags for a specific image
4. **Scan images** — Pull and scan any image for known vulnerabilities
Credentials are stored with **AES-256-GCM encryption** and are never exposed in API responses.
## Credential Management
Credentials are managed at two levels:
| Level | Actions | Permission Required |
| ---------------- | -------------------------------------------- | --------------------- |
| **Organization** | Create and delete credentials | `manage_integration` |
| **Project** | View credentials, browse images, start scans | `read` / `start_scan` |
Credentials are created at the organization level and can be used across all projects within that organization.
## Security Best Practices
Create a dedicated API key with only Container Registry permissions.
Rotate API keys regularly and update stored credentials in CybeDefend.
Scope API keys to specific projects rather than granting organization-wide access.
Monitor API key usage in Scaleway's IAM audit logs.
## Troubleshooting
* Verify the secret key is correct and has not been revoked
* Check that the API key has Container Registry permissions
* Ensure the region matches the namespace location
* Confirm the namespace name is spelled correctly (case-sensitive)
* Verify the namespace exists in the selected region
* Check that the API key's project scope includes the namespace
* Ensure the API key has `ContainerRegistryFullAccess` or equivalent policy
* Verify the API key is scoped to the correct Scaleway project
* Verify the image name and tag are correct
* Ensure the image exists in the specified namespace
* Check that the `container_scanning` feature is enabled for your plan
# Assigning Roles in Organizations and Teams
Source: https://docs.cybedefend.com/latest/get-started/account-setup/assigning-roles
Learn about the different roles available in CybeDefend organizations and teams, and how to manage user permissions.
CybeDefend provides **distinct roles** for Organizations and Teams, each granting specific permissions. Update roles from Organization or Team settings to ensure everyone has appropriate access levels.
![Roles and Permissions Overview]()
Each Organization has at least one Administrator/Creator, and each Team has at least one Team Manager.
***
## Organization Roles
| **Role** | **Description** | **Key Permissions** |
| ------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Administrator** | Top-level authority. Cannot modify their own role or another Admin’s role. | - Manage organization settings
- Add/remove users
- Update user roles
- Create/delete teams
- Read logs
- Full access
|
| **Manager** | High-level authority but slightly less than Administrator. | - Manage integrations
- Add/remove users
- Create teams
- Read logs
|
| **Billing Manager** | Focuses on financial or billing aspects within the organization. | - Access billing settings
- Read organization info
|
| **Member** | Standard member with basic read and limited write rights. | - Read organization information
- Use assigned tools
|
***
## Team Roles
| **Role** | **Description** | **Key Permissions** |
| --------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Team Manager** | Leads the team. Cannot modify their own role or another Team Manager’s role. | - Manage team settings
- Create/remove users
- Update user roles
- Create projects
- Read logs
- Start scans
|
| **Analyst Developer** | Focuses on analyzing scan results and possibly contributing code fixes. | - Read and create reports
- Change vulnerability states
- Start scans
- Full read on scan results
|
| **Developer** | Primarily involved in writing code. | - Read scan results
- Change vulnerability states
- Start scans
|
| **Read Only** | Has read access to projects, teams, and scan outcomes but no editing rights. | - View team details
- View project scan results (where granted by org/team)
|
All roles inherit the Organization’s overarching permissions, but these team roles define additional capabilities within each team.
***
## Managing Organization Member Roles
1. **Open Organization Settings → Manage**\
Scroll to the user list and click **Manage** next to a user’s name.
2. **Choose New Role**\
Pick from Administrator, Manager, Billing Manager, or Member.
3. **Save Changes**\
The user’s permissions update instantly.
![Change Organization Member Role]()
Must keep at least one Administrator. Admins cannot downgrade themselves or each other.
***
## Managing Team Member Roles
1. **Organization Settings → Teams → Manage**\
Select a team, find the user, and click **Manage** next to their name.
2. **Assign Role**\
Pick Team Manager, Analyst Developer, Developer, or Read Only.
3. **Confirm**\
The user’s capabilities in that team adjust immediately.
Each team must have at least one Team Manager. Team Managers cannot modify their own or each other’s roles.
***
## Future Role Customization
Some organizations may require specialized roles. If your use case isn’t covered:
* Visit our [Roadmap](https://cybedefend.featurebase.app/roadmap) for upcoming role expansions.
* Send feedback to our dev team—if enough customers share a need, we may add a new role.
We strive to balance simplicity and flexibility when expanding role definitions.
# Create Account
Source: https://docs.cybedefend.com/latest/get-started/account-setup/create-account-organization
Learn how to create your CybeDefend account, set up an organization, and integrate your code repositories.
CybeDefend simplifies onboarding by allowing you to create an account through **OAuth2** (Google, Microsoft, GitHub, or GitLab). After signing in, you can form an **Organization** to group your projects and manage access. Once your repositories are connected, CybeDefend automatically starts scanning them.
***
## 1. Create an Account via OAuth2
1. **Go to the CybeDefend Registration Page**\
Choose the sign-up option of your choice (Google, Microsoft, GitHub, GitLab).
2. **Select Your Cloud Region**\
CybeDefend offers two sovereign cloud options to meet your compliance and performance needs:
**Optimized for GDPR compliance and data sovereignty**
![Select Europe Cloud]()
**Certifications held by the underlying infrastructure provider (Scaleway):**
* CISPE
* ANSSI SecNumCloud
* G-Cloud UK
* ACN (Italy)
* ENS (Spain)
* BSI KRITIS
* BSI C5
* ISO 27001/17/18
* ISO 27701
These are **Scaleway's** certifications, describing the infrastructure CybeDefend runs on. They are not CybeDefend's own certifications. CybeDefend is GDPR compliant today; our SOC 2 Type II and ISO 27001 audits are in progress. See the [Security page](https://cybedefend.com/en/legal/security) for our current status.
Choose Europe for full GDPR compliance and European data sovereignty requirements.
**Optimized for low latency in North America**
![Select US Cloud]()
**Certifications held by the underlying infrastructure provider (Google Cloud):**
* SOC 2
* ISO 27001/17/18
* ISO 27701
* HIPAA
* PCI-DSS
These are **Google Cloud's** certifications, describing the infrastructure CybeDefend runs on. They are not CybeDefend's own certifications. CybeDefend is GDPR compliant today; our SOC 2 Type II and ISO 27001 audits are in progress. See the [Security page](https://cybedefend.com/en/legal/security) for our current status.
Choose United States for lowest latency in North America.
Your region selection binds IAM/Gateway endpoints at runtime.
3. **Authorize Your Credentials**\
OAuth2 ensures a secure handshake without requiring you to store new passwords.
4. **Complete Your Profile**\
Provide your name and agree to our Terms of Service to finalize your account creation.
Already have an existing OAuth provider account? The sign-up process is near-instant.
***
## 2. Create Your Organization
1. **Access the Form**\
After your first login, you’ll be prompted to create an **Organization**. Alternatively, visit **Organization Settings** → **New Organization**.
2. **Fill in Details**\
Provide an organization name, an optional description, and (if needed) a logo.
3. **Save & Continue**\
This sets up your top-level group where teams and projects will live.
![Create Organization Form]()
You can create multiple organizations if you manage different companies, clients, or environments.
***
## 3. Connect Your Repositories
1. **Select Your Version Control Platform**\
CybeDefend supports GitHub. Check out our [Detailed Integration Guides](/latest/get-started/connect-your-source-code/connect-github) for each platform.
2. **Authorize Access**\
Approve read (and optionally write) permissions so we can scan your code.
3. **Pick Your Repositories**\
Choose which repos to include in your **Organization**. You can assign them to specific teams or projects later.
4. **Instant Scanning**\
As soon as you connect a repository, CybeDefend triggers an initial scan, identifying potential vulnerabilities.
![Connecting Your Repository]()
Once your repositories are connected, scans start automatically—no extra steps required.
# Managing Access with Organizations and Teams
Source: https://docs.cybedefend.com/latest/get-started/account-setup/managing-access-org-teams
Learn how to structure your organization, create teams, and invite members to manage code and projects effectively.
CybeDefend offers flexible structures to keep your organization and teams organized. Each **Organization** can have multiple **Teams**, and each Team can own projects (the codebase). This helps segment permissions and simplify collaboration.
![Organization and Team Structure]()
Teams are ideal for grouping people working on the same projects or requiring similar levels of access.
***
## How to Create Teams
1. **Open Organization Settings**\
From the main dashboard, select **Organization Settings**.
2. **Navigate to Teams**\
Click **Teams** → **Create New Team**.
3. **Provide Basic Info**\
Name your team and optionally include a description.
![Create Team Popup]()
Each organization has at least **one** Team Manager, who can manage team members and their projects.
## Inviting Organization Members
1. **Open the Invite Dialog**
* Go to **Organization Settings** → **+ Add Member**.
* Enter the user’s email and assign an **Organization Role** (e.g., Administrator, Manager, Billing Manager, or Member).
![Invite Organization Member Popup]()
2. **Pending Invitations**
* Once invited, the user appears in the member list with a **Pending** status.
* You can cancel the invite at any time if needed.
![Pending Invitation List]()
3. **User Acceptance Flow**
* **Receive Email**: The invitee gets an email with a unique link.
* **Sign Up or Log In**: If they don’t have a CybeDefend account, they’ll be prompted to create one.
* **Accept Invitation**: After confirming, they’re redirected to the main dashboard with new **Organization Access**.
![Invitation Landing Page]()
Admins can revoke an invitation before it’s accepted, ensuring you maintain full control over who joins your organization.
***
## Adding Team Members
1. **Go to Teams**\
In **Organization Settings** → **Teams**, pick the team you want to modify.
2. **+ Add Member**\
Enter the user’s email and a team role (Team Manager, Analyst Developer, Developer, or Read Only).
3. **Save & Notify**\
Once they accept your organization invite, they’ll see team details and projects.
![Add Team Member Popup]()
***
## Switching Organizations in the UI
If you belong to multiple organizations, use the top navigation bar or settings dropdown to switch org contexts easily.
![Switch Organization UI]()
# Connect GitHub Account to CybeDefend
Source: https://docs.cybedefend.com/latest/get-started/connect-your-source-code/connect-github
Authorize and install the CybeDefend GitHub App to link your repositories for static code scanning.
To begin performing **static code scans** on your GitHub repositories with CybeDefend, you’ll need to **authorize** and **install** our GitHub App. Once installed, your repositories will be accessible when creating new projects in CybeDefend.
![GitHub Integration Intro]()
***
## 1. Access Organization Integrations
1. **Navigate to “Integratin Settings”**
Go to your Organization's settings > Integrations.
2. **Search for “GitHub”**
Within that section, choose the **GitHub** option for installation instructions.
3. **Click “Install & Authorize”**\
You’ll be redirected to GitHub’s official authorization flow.
You must have Administrator or Manager privileges in CybeDefend to add integrations.
***
## 2. Install & Authorize CybeDefend on GitHub
When GitHub prompts you to install the **CybeDefend GitHub App**:
1. **Choose Repositories**\
Select either all or specific repositories to grant CybeDefend read access.
2. **Confirm Permissions**\
We need at least read access for scanning. Write access is optional but enables advanced features like **Auto-Fix PRs** (coming soon).
3. **Complete Installation**\
Wait a few seconds for GitHub to finalize authorization.
If you have organizational policies restricting third-party app installations, contact your GitHub Org Admin to approve CybeDefend’s GitHub App.
***
## 3. Linking Repositories to Your Projects
After installation, you can associate any authorized repository with a **new project** in CybeDefend:
* **Go to "Create Project"**: Navigate to [Create Project](/latest/get-started/project-management/create-project).
* **Select "Continue with GitHub"**: Your authorized repos will appear in a dropdown.
* **Choose Your Repo**: Pick a repository, assign it to a team, and configure scanning parameters.
If you just installed the app, it may take a few moments before your repositories become visible in the "Create Project" flow.
***
**Related:** [Connect GitLab](/latest/get-started/connect-your-source-code/connect-gitlab) · [Create a Project](/latest/get-started/project-management/create-project) · [Cybe AutoFix](/latest/agent-ai-integration/cybe-autofix-detail)
# Connect GitLab Account to CybeDefend
Source: https://docs.cybedefend.com/latest/get-started/connect-your-source-code/connect-gitlab
Authorize and install the CybeDefend GitLab integration to link your repositories for static code scanning.
To begin performing **static code scans** on your GitLab repositories with CybeDefend, you'll need to **authorize** and **install** our GitLab integration. Once installed, your repositories will be accessible when creating new projects in CybeDefend.
![GitLab Integration Intro]()
***
## 1. Access Organization Integrations
1. **Navigate to "Integration Settings"**
Go to your Organization's settings > Integrations.
2. **Search for "GitLab"**
Within that section, choose the **GitLab** option for installation instructions.
3. **Click "Install & Authorize"**\
You'll be redirected to GitLab's official authorization flow.
You must have Administrator or Manager privileges in CybeDefend to add integrations.
***
## 2. Install & Authorize CybeDefend on GitLab
When GitLab prompts you to authorize **CybeDefend**:
1. **Choose Repositories**\
Select either all or specific repositories to grant CybeDefend read access.
2. **Confirm Permissions**\
We need at least read access for scanning. Write access is optional but enables advanced features like **Auto-Fix Merge Requests**.
3. **Complete Installation**\
Wait a few seconds for GitLab to finalize authorization.
If you have organizational policies restricting third-party integrations, contact your GitLab Admin to approve CybeDefend's access.
***
## 3. Linking Repositories to Your Projects
After installation, you can associate any authorized repository with a **new project** in CybeDefend:
* **Go to "Create Project"**: Navigate to [Create Project](/latest/get-started/project-management/create-project).
* **Select "Continue with GitLab"**: Your authorized repos will appear in a dropdown.
* **Choose Your Repo**: Pick a repository, assign it to a team, and configure scanning parameters.
If you just installed the integration, it may take a few moments before your repositories become visible in the "Create Project" flow.
***
**Related:** [Connect GitHub](/latest/get-started/connect-your-source-code/connect-github) · [Create a Project](/latest/get-started/project-management/create-project) · [Cybe AutoFix](/latest/agent-ai-integration/cybe-autofix-detail)
# Creating Projects
Source: https://docs.cybedefend.com/latest/get-started/project-management/create-project
Learn how to create projects in CybeDefend, whether you're linking GitHub, GitLab, or uploading a ZIP file.
CybeDefend projects are the core of your DevSecOps workflow. They allow you to scan your code for vulnerabilities, track your security posture, and collaborate with your team. This guide will show you how to create projects in CybeDefend using GitHub, GitLab, or ZIP upload.
***
## How to Create Projects
Before creating your first project, decide how you want to add your code to CybeDefend:
1. **Recommended: Link a Git Provider**\
Connect your **GitHub** or **GitLab** account to seamlessly import repositories. See our integration guides:
* [GitHub Integration Setup](/latest/get-started/connect-your-source-code/connect-github)
* [GitLab Integration Setup](/latest/get-started/connect-your-source-code/connect-gitlab)
2. **Alternatively: Upload a ZIP**\
You can upload your code in a zip file for quick or offline testing. We strongly recommend connecting a Git repository for the best DevSecOps experience.
***
## Steps to Create a Project
### 1. Navigate to Create Project
In your organization's home page, click **Create Project**.
### 2. Select Your Method
Choose how you want to add your code:
#### Option A: Connect with GitHub
![Link GitHub Project]()
* Click **Continue with GitHub**
* Select your repository from the dropdown
* Assign it to a specific team
* Configure scan parameters
#### Option B: Connect with GitLab
![Link GitLab Project]()
* Click **Continue with GitLab**
* Select your repository from the dropdown
* Assign it to a specific team
* Configure scan parameters
#### Option C: Upload ZIP
![Upload ZIP Project]()
* Click **Upload ZIP**
* Provide your code archive
* Assign to a team
* Configure scan parameters
### 3. Configure Scan Parameters
Adjust scanning settings based on your needs:
* **Severity levels**: Choose which vulnerabilities to detect
* **Scanner types**: SAST, SCA, IaC, Container
* **Advanced options**: Enable Cybe Analysis etc.
See more details in our [Scan Project Parameters](/latest/code-scanning/scanning-options/scan-parameters) guide.
***
## What Happens After Creation?
Once your project is created:
* **Initial Scan Starts**: CybeDefend automatically begins scanning your code
* **Vulnerabilities Detected**: Results appear in your project dashboard
***
**Related:** [Connect GitHub](/latest/get-started/connect-your-source-code/connect-github) · [Connect GitLab](/latest/get-started/connect-your-source-code/connect-gitlab) · [Scan Parameters](/latest/code-scanning/scanning-options/scan-parameters) · [Cybe Analysis](/latest/agent-ai-integration/cybe-analysis-detail)
# Global Project Management
Source: https://docs.cybedefend.com/latest/get-started/project-management/global-project-management
Get a high-level view of all your organization’s projects, vulnerabilities, and trends.
**CybeDefend** provides a central dashboard to help you see your organization’s security posture at a glance. This page is your go-to hub for the big-picture stats and aggregated vulnerability data across all projects.
![Main Dashboard Overview]()
## Key Dashboard Sections
1. **High-Risk Projects Count**\
Instantly see how many projects have critical or high-severity vulnerabilities. This allows teams to prioritize resources where they’re needed most.
2. **Recent Activity (7-Day Window)**
* **New Issues**: The number of vulnerabilities discovered in the past week.
* **Resolved Issues**: How many vulnerabilities were fixed over the same period, reflecting your team’s remediation efforts.
3. **Pie Chart: Vulnerabilities by Severity**\
A visual breakdown (Critical, High, Medium, Low) across your entire organization, offering a quick sense of overall risk distribution.
4. **Project List & Severity Counts**\
Below the summary stats, you’ll find a detailed table of all projects. Each row shows:
* **Project Name**
* **Open Vulnerabilities by Severity** (e.g., 2 Critical, 5 High, 8 Medium)
* **Scanner Type Counts** (SAST, IAC, SCA) if you need to see which analysis is flagging the most issues.
![Project List with Vulnerability Details]()
The table supports searching by project name. You can also click a project row to jump into its detailed vulnerability list.
(PS: of course our API is not vulnerable, it's just an example :) )
***
## Recommended Usage
* **Daily Standups**: Quickly identify if any new critical vulnerabilities appeared overnight.
* **Reporting**: Export or screenshot this page for management updates on your organization's security trends.
* **Prioritization**: High-risk projects and spikes in new issues are immediate signals where additional focus may be needed.
Stay proactive by scheduling scans at a higher frequency for your “High-Risk Projects” to detect newly introduced vulnerabilities faster.
# Project Overview & Stats
Source: https://docs.cybedefend.com/latest/get-started/project-management/project-overview-stats
Dive deeper into per-project analytics, including severity breakdowns, states, and historical trends.
While the **Project Vulnerability List** highlights current open issues, the **Project Overview** page offers in-depth analytics and historical context. It answers questions like, “Are we reducing critical vulnerabilities over time?” and “Which scanner finds the most issues?”
![Project Overview Dashboard]()
## Breakdown Charts
1. **Vulnerabilities by Severity**\
A bar or donut chart showing the split among Critical, High, Medium, Low issues. Perfect for zeroing in on severity hotspots.
2. **Vulnerabilities by Analysis Type**\
Compares how many issues come from SAST, IAC, or SCA. This can reveal if your code (SAST) or your infrastructure (IAC) demands more attention.
3. **Vulnerabilities by State**\
Shows how many are Open, In Progress, or Resolved. Great for agile workflows to see if issues keep piling up or are actively being addressed.
4. **Vulnerabilities Over Time**\
A timeline chart that records how many vulnerabilities exist at any given time in the project’s history. This helps track improvement trends.
***
## Practical Use Cases
* **Management Reporting**: Show weekly or monthly improvements to stakeholders.
* **Prioritization**: If SAST counts are skyrocketing, your dev team might need more secure coding guidance.
* **Team Accountability**: Some organizations tie metrics (like “Resolved vs. New Vulnerabilities”) to sprint goals.
Combine this data with your weekly triage approach to confirm that your security posture is actually improving.
# Antigravity
Source: https://docs.cybedefend.com/latest/ide-integrations/antigravity
Install the CybeDefend extension in Antigravity via the Open VSX Registry.
Scan. Detect. Fix. — Security meets AI, right in your editor.
***
## Overview
Antigravity is compatible with VS Code extensions via the **Open VSX Registry**. The CybeDefend extension works in Antigravity with the same features as in VS Code — security scanning, AI-powered remediation, and vulnerability management.
Get the CybeDefend extension for Antigravity
***
## Getting Started
Open the Extensions view in Antigravity, search for "**CybeDefend**", and click **Install**. The extension is fetched from the Open VSX Registry automatically.
Follow the same setup steps as VS Code: select your region, authenticate via OAuth 2.0, configure your project, and start scanning.
See the [VS Code Extension guide](/latest/ide-integrations/vscode#getting-started) for detailed step-by-step instructions — the workflow is identical.
***
## Features
All features from the VS Code extension are available in Antigravity:
* **5 scan types** — SAST, SCA, IaC, Secrets, CI/CD
* **CybeAgent** — AI-powered vulnerability analysis and fix suggestions
* **DeepFix** — Automated dependency upgrades across 9 ecosystems
* **Editor integration** — Gutter icons, diagnostics, context menu, status bar
* **Vulnerability management** — Update status directly from the IDE
For full feature details, see the [VS Code Extension](/latest/ide-integrations/vscode) documentation.
***
**Related:** [VS Code Extension](/latest/ide-integrations/vscode) · [Windsurf](/latest/ide-integrations/windsurf) · [Cursor](/latest/ide-integrations/cursor) · [MCP Server Integration](/latest/plateform-overview/key-features/mcp-server-integration)
# Cursor
Source: https://docs.cybedefend.com/latest/ide-integrations/cursor
Install the CybeDefend extension in Cursor by downloading the .vsix file from the Open VSX Registry.
Scan. Detect. Fix. — Security meets AI, right in your editor.
***
## Overview
Cursor supports VS Code extensions, but does not connect to the Open VSX Registry by default. To install CybeDefend in Cursor, you need to **download the `.vsix` file** and install it manually.
***
## Getting Started
Go to the CybeDefend extension page on Open VSX and download the latest `.vsix` file:
Download the CybeDefend `.vsix` file
On the extension page, click the **Download** button to get the `.vsix` file.
Open Cursor and install the extension using one of these methods:
**Option A — Command Palette:**
1. Open the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`)
2. Type **"Extensions: Install from VSIX..."**
3. Select the downloaded `.vsix` file
**Option B — Terminal:**
```bash theme={null}
cursor --install-extension path/to/cybedefend-cybedefend-.vsix
```
Follow the same setup steps as VS Code: select your region, authenticate via OAuth 2.0, configure your project, and start scanning.
See the [VS Code Extension guide](/latest/ide-integrations/vscode#getting-started) for detailed step-by-step instructions — the workflow is identical.
When a new version of CybeDefend is released, you will need to download and install the updated `.vsix` file manually. Cursor does not auto-update extensions installed from `.vsix` files.
***
## Features
All features from the VS Code extension are available in Cursor:
* **5 scan types** — SAST, SCA, IaC, Secrets, CI/CD
* **CybeAgent** — AI-powered vulnerability analysis and fix suggestions
* **DeepFix** — Automated dependency upgrades across 9 ecosystems
* **Editor integration** — Gutter icons, diagnostics, context menu, status bar
* **Vulnerability management** — Update status directly from the IDE
For full feature details, see the [VS Code Extension](/latest/ide-integrations/vscode) documentation.
***
**Related:** [VS Code Extension](/latest/ide-integrations/vscode) · [Windsurf](/latest/ide-integrations/windsurf) · [Antigravity](/latest/ide-integrations/antigravity) · [MCP Server Integration](/latest/plateform-overview/key-features/mcp-server-integration)
# JetBrains Plugin
Source: https://docs.cybedefend.com/latest/ide-integrations/jetbrains
Integrate CybeDefend security scanning and AI-powered remediation into IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs.
Scan. Detect. Fix. — Security meets AI, right in your editor.
***
## Overview
The CybeDefend plugin for JetBrains IDEs brings comprehensive security analysis and AI-powered remediation directly into your development workflow. Identify vulnerabilities, get AI-generated fixes, and manage your security posture — all without leaving your IDE.
Get the CybeDefend plugin for JetBrains IDEs
***
## Supported IDEs
The plugin is compatible with **JetBrains IDEs build 2024.3+**, including:
And all other JetBrains IDEs based on the IntelliJ Platform (DataGrip, AppCode, etc.).
***
## Key Features
SAST, SCA, IaC, Secrets, and CI/CD scanning in one plugin
AI-powered assistant that analyzes and fixes vulnerabilities with full code context
Automated dependency upgrades for SCA vulnerabilities across 10 ecosystems
Gutter icons, diagnostics, context menus, and tool windows built for JetBrains
### Security Scanning
| Scan Type | What It Detects |
| ----------- | -------------------------------------------------------------------------------------------------- |
| **SAST** | SQL injection, XSS, path traversal, command injection — with taint analysis and data flow tracking |
| **SCA** | Known CVEs in dependencies (npm, Maven, pip, Go, NuGet, RubyGems, Cargo, Swift, Packagist) |
| **IaC** | Misconfigurations in Terraform, CloudFormation, Kubernetes, Docker |
| **Secrets** | Leaked API keys, tokens, passwords, certificates |
| **CI/CD** | Insecure pipeline configurations and overly permissive permissions |
### Editor Integration
* **Gutter icons** — Severity-colored markers on every vulnerable line (Critical, High, Medium, Low, Info)
* **Diagnostics** — Native underlines visible in the inspections/problems panel
* **Context menu** — Right-click on vulnerable code to view details or trigger AI fix
* **Tool windows** — Dedicated "CybeDefend" and "CybeDefend Security" panels
* **Code navigation** — Click any vulnerability to jump to the exact line of code
### CybeAgent — AI-Powered Fix
Click **"Fix with CybeAgent"** on any vulnerability. The AI agent receives the full vulnerability context — severity, CWE, OWASP classification, data flow, code snippet, and remediation guidance — then proposes a precise code fix that you review and apply.
### DeepFix — Automated Dependency Upgrades
Automatically resolves safe version upgrades for SCA vulnerabilities. Supports **10 package ecosystems**: npm, Maven, pip/PyPI, Go, NuGet, Packagist, RubyGems, Cargo, SwiftPM, and CocoaPods.
### Git Integration
The plugin adds a **"Generate Commit Message"** action in the VCS commit dialog, using AI to generate meaningful commit messages based on your staged changes.
***
## Getting Started
Open **Settings/Preferences** → **Plugins** → **Marketplace**, search for "**CybeDefend**", and click **Install**. Restart the IDE when prompted.
In the CybeDefend tool window settings, select **EU** (Europe — default) or **US** (United States) depending on your CybeDefend instance.
Open the CybeDefend tool window and click **Login**. Your browser opens for a secure OAuth 2.0 authentication flow. After completing login, you are redirected back to the IDE automatically.
No API key or Personal Access Token is needed — the plugin uses secure browser-based OAuth 2.0 with PKCE.
Select the corresponding CybeDefend Organization and Project for your workspace.
Open the CybeDefend Security tool window and start a vulnerability scan with one click. Results appear directly in your editor with gutter icons and diagnostics.
***
## File Exclusion
Create a **`.cybeignore`** file at your project root to exclude files and directories from scans. It uses `.gitignore` syntax:
```
# Exclude test fixtures
tests/fixtures/
*.test.js
# Exclude generated code
dist/
build/
```
The older name `.cybedefend` is still read, but it is deprecated: it collides with the `.cybedefend/` directory VibeDefend uses for `config.json`. See [.cybeignore Exclusion File](/latest/code-scanning/scanning-options/cybedefend-ignore-file).
Common directories like `node_modules`, `.git`, `dist`, `build`, `venv`, and `__pycache__` are excluded by default.
***
## Vulnerability Management
You can update vulnerability status directly from the IDE:
| Status | Meaning |
| ------------- | ----------------------- |
| **To Verify** | Needs triage (default) |
| **Confirmed** | Validated vulnerability |
| **Resolved** | Fixed |
| **Ignored** | Accepted risk |
***
## Requirements
* **JetBrains IDE** 2024.3 or later (build 243.0+)
* A **CybeDefend account** ([create one here](/latest/get-started/account-setup/create-account-organization))
* Internet connection to the CybeDefend API
***
**Related:** [VS Code Extension](/latest/ide-integrations/vscode) · [MCP Server Integration](/latest/plateform-overview/key-features/mcp-server-integration) · [Create Your Account](/latest/get-started/account-setup/create-account-organization) · [CybeDefend Ignore File](/latest/code-scanning/scanning-options/cybedefend-ignore-file)
# VS Code Extension
Source: https://docs.cybedefend.com/latest/ide-integrations/vscode
Integrate CybeDefend security scanning and AI-powered remediation directly into Visual Studio Code.
Scan. Detect. Fix. — Security meets AI, right in your editor.
***
## Overview
The CybeDefend VS Code extension brings comprehensive security analysis and AI-powered remediation directly into your development workflow. Identify vulnerabilities, get AI-generated fixes, and manage your security posture — all without leaving Visual Studio Code.
Get the CybeDefend extension for VS Code
***
## Key Features
SAST, SCA, IaC, Secrets, and CI/CD scanning in one extension
AI-powered assistant that analyzes and fixes vulnerabilities with full code context
Automated dependency upgrades for SCA vulnerabilities across 9 ecosystems
### Security Scanning
| Scan Type | What It Detects |
| ----------- | -------------------------------------------------------------------------------------------------- |
| **SAST** | SQL injection, XSS, path traversal, command injection — with taint analysis and data flow tracking |
| **SCA** | Known CVEs in dependencies (npm, Maven, pip, Go, NuGet, RubyGems, Cargo, Swift, Packagist) |
| **IaC** | Misconfigurations in Terraform, CloudFormation, Kubernetes, Docker |
| **Secrets** | Leaked API keys, tokens, passwords, certificates |
| **CI/CD** | Insecure pipeline configurations and overly permissive permissions |
### Editor Integration
* **Gutter icons** — Severity-colored markers on every vulnerable line (Critical, High, Medium, Low, Info)
* **Diagnostics** — Native squiggly underlines visible in the Problems panel
* **Context menu** — Right-click on vulnerable code to view details or trigger AI fix
* **Status bar** — Live scan progress and result summary
* **Code navigation** — Click any vulnerability to jump to the exact line of code
### CybeAgent — AI-Powered Fix
Click **"Fix with CybeAgent"** on any vulnerability. The AI agent receives the full vulnerability context — severity, CWE, OWASP classification, data flow, code snippet, and remediation guidance — then proposes a precise code fix that you review and apply.
### DeepFix — Automated Dependency Upgrades
Automatically resolves safe version upgrades for SCA vulnerabilities. Supports **9 package ecosystems**: npm, Maven, pip/PyPI, Go, NuGet, Packagist, RubyGems, Cargo, and SwiftPM.
***
## Getting Started
Search for "**CybeDefend**" in the VS Code Extensions view (`Ctrl+Shift+X` / `Cmd+Shift+X`) and click **Install**.
Alternatively, open Quick Open (`Ctrl+P` / `Cmd+P`) and run:
```
ext install CybeDefend.cybedefend
```
Open VS Code settings and set `cybedefend.region` to **eu** (Europe — default) or **us** (United States) depending on your CybeDefend instance.
Click the CybeDefend icon in the Activity Bar and click **Login**. Your browser opens for a secure OAuth 2.0 authentication flow. After completing login, you are redirected back to VS Code automatically.
No API key or Personal Access Token is needed — the extension uses secure browser-based OAuth 2.0 with PKCE.
Open your project folder. The extension guides you to select the corresponding CybeDefend Organization and Project. You can also use the command `CybeDefend: Update Project ID (Current Workspace)`.
Open the CybeDefend Security panel from the Activity Bar and click the **Start Vulnerability Scan** icon. Results appear directly in your editor with gutter icons and diagnostics.
***
## File Exclusion
Create a **`.cybeignore`** file at your project root to exclude files and directories from scans. It uses `.gitignore` syntax:
```
# Exclude test fixtures
tests/fixtures/
*.test.js
# Exclude generated code
dist/
build/
```
The older name `.cybedefend` is still read, but it is deprecated: it collides with the `.cybedefend/` directory VibeDefend uses for `config.json`. See [.cybeignore Exclusion File](/latest/code-scanning/scanning-options/cybedefend-ignore-file).
Common directories like `node_modules`, `.git`, `dist`, `build`, `venv`, and `__pycache__` are excluded by default.
***
## Settings
| Setting | Default | Description |
| ------------------------------------ | ------------------------------------- | --------------------------------------------------------- |
| `cybedefend.region` | `eu` | Region (`eu` or `us`) — determines auth and API endpoints |
| `cybedefend.enableCodeActions` | `true` | Show quick-fix code actions on vulnerabilities |
| `cybedefend.allowedCommands` | `["git log", "git diff", "git show"]` | Terminal commands the AI agent can run |
| `cybedefend.deniedCommands` | `[]` | Blocked terminal commands |
| `cybedefend.commandExecutionTimeout` | `0` | Command timeout in seconds (0 = no limit) |
| `cybedefend.apiRequestTimeout` | `600` | API request timeout in seconds |
| `cybedefend.debug` | `false` | Enable debug logging |
***
## Vulnerability Management
You can update vulnerability status directly from VS Code:
| Status | Meaning |
| ------------- | ----------------------- |
| **To Verify** | Needs triage (default) |
| **Confirmed** | Validated vulnerability |
| **Resolved** | Fixed |
| **Ignored** | Accepted risk |
***
## Requirements
* **VS Code** 1.84.0 or later
* A **CybeDefend account** ([create one here](/latest/get-started/account-setup/create-account-organization))
* Internet connection to the CybeDefend API
***
**Related:** [JetBrains Plugin](/latest/ide-integrations/jetbrains) · [Create Your Account](/latest/get-started/account-setup/create-account-organization) · [CybeDefend Ignore File](/latest/code-scanning/scanning-options/cybedefend-ignore-file)
# Windsurf
Source: https://docs.cybedefend.com/latest/ide-integrations/windsurf
Install the CybeDefend extension in Windsurf via the Open VSX Registry.
Scan. Detect. Fix. — Security meets AI, right in your editor.
***
## Overview
Windsurf is compatible with VS Code extensions via the **Open VSX Registry**. The CybeDefend extension works in Windsurf with the same features as in VS Code — security scanning, AI-powered remediation, and vulnerability management.
Get the CybeDefend extension for Windsurf
***
## Getting Started
Open the Extensions view in Windsurf, search for "**CybeDefend**", and click **Install**. The extension is fetched from the Open VSX Registry automatically.
Follow the same setup steps as VS Code: select your region, authenticate via OAuth 2.0, configure your project, and start scanning.
See the [VS Code Extension guide](/latest/ide-integrations/vscode#getting-started) for detailed step-by-step instructions — the workflow is identical.
***
## Features
All features from the VS Code extension are available in Windsurf:
* **5 scan types** — SAST, SCA, IaC, Secrets, CI/CD
* **CybeAgent** — AI-powered vulnerability analysis and fix suggestions
* **DeepFix** — Automated dependency upgrades across 9 ecosystems
* **Editor integration** — Gutter icons, diagnostics, context menu, status bar
* **Vulnerability management** — Update status directly from the IDE
For full feature details, see the [VS Code Extension](/latest/ide-integrations/vscode) documentation.
***
**Related:** [VS Code Extension](/latest/ide-integrations/vscode) · [Antigravity](/latest/ide-integrations/antigravity) · [Cursor](/latest/ide-integrations/cursor) · [MCP Server Integration](/latest/plateform-overview/key-features/mcp-server-integration)
# Introduction
Source: https://docs.cybedefend.com/latest/introduction
Overview and introduction to the CybeDefend platform and its innovative approach to cybersecurity.
![CybeDefend Banner]()
Welcome to the CybeDefend documentation. This page provides an in-depth look at our platform, our motivations, and our future roadmap. Here you will discover how CybeDefend is revolutionizing cybersecurity by integrating robust security measures right from the start of development.
***
## Explore CybeDefend
### What is CybeDefend?
CybeDefend is a revolutionary SaaS cybersecurity platform designed to protect business applications against cyberattacks. By leveraging advanced artificial intelligence, our solution not only detects vulnerabilities but also analyzes them intelligently, eliminates false positives, and prioritizes real threats—ensuring robust security accessible to businesses of every size.
### Motivation
Our journey began with firsthand experiences of cyberattacks and the costly rework that follows when vulnerabilities are detected too late. With CybeDefend, security is embedded at the very beginning of the development cycle—not as an afterthought. This proactive approach prevents the need to reverse entire development loops and fixes vulnerabilities early, saving both time and resources.
### With CybeDefend, You Can
* **Secure Your Digital Assets:** Protect your applications and data from evolving cyber threats from the very first line of code.
* **Automate Vulnerability Management:** Leverage AI to reduce false positives and streamline remediation.
* **Gain a Unified View:** Access a single, integrated dashboard that combines all the standard security tools (SAST, DAST, SCA, etc.) with our innovative new features.
* **Innovate Beyond the Norm:** Not only do we provide all the tools that our competitors offer, but we also push the envelope by introducing BLSA—a revolutionary new scanner that sets a new industry standard.
* **Choose your sovereignty and platform:** Select either a European or US infrastructure to ensure optimal latency and secure storage of your analyses, tailored to your geolocation and regulatory requirements.
![Security from Day 1]()
### Roadmap
Our vision is built on a clear, phased roadmap that is available for public viewing. Check our progress at [CybeDefend Roadmap](https://cybedefend.featurebase.app/roadmap).
***
## What happens to your code
Security teams evaluating CybeDefend usually want this answer before anything else, so here it is in one place.
**The scanning platform receives your repository, because it cannot scan what it does not have.** Your repo is cloned into an isolated container, analysed, and the container together with its copy of the code is destroyed when the scan finishes. **We do not retain source code after analysis.** What we keep is the result: findings, their file and line, and repository metadata.
**VibeDefend is a different thing.** It is the layer that plugs into your AI coding agent (Claude Code, Cursor, Windsurf, GitHub Copilot, OpenAI Codex) and it runs on the developer's machine. Edits happen locally, and only governance metadata comes back to the platform.
**If you enable the AI features that learn your repository's conventions**, we additionally keep a business-logic knowledge graph. It holds **file paths and a short description of what each file does. It does not contain your source code.** You can delete it at any time, and disabling the AI features stops it being built.
**AI inference runs on open-weight models we host ourselves**, inside the region you selected: Scaleway for the EU region, Google Cloud for the US region. No code and no prompt is sent to any third-party AI API. Nothing crosses the regional boundary. Nothing you submit trains any model.
**Certifications.** GDPR compliant today. **SOC 2 Type II and ISO 27001 audits are in progress**, controls are implemented and operating, and we expect the SOC 2 report shortly. Certifications listed in this documentation for Scaleway or Google Cloud belong to those providers and describe the infrastructure we run on, not CybeDefend itself.
What we destroy, what we keep, and how the knowledge graph works. See also [LLM Usage & Privacy](/latest/plateform-overview/security-privacy/llm-usage-privacy), our [Security page](https://cybedefend.com/en/legal/security), and the [sub-processor list](https://cybedefend.com/en/legal/subprocessors).
***
## Evolution and Innovation: Introducing BLSA
### What is BLSA?
BLSA (Business Logic Security Analysis) is our innovative, next-generation scanner that uses AI agents to detect vulnerabilities in business logic—ensuring security by design from the outset. This breakthrough tool:
* **Detects Business Logic Flaws:** Uncovers vulnerabilities in the fundamental design of your applications that traditional scanners often miss.
* **Utilizes AI Agents:** Leverages intelligent agents to continuously monitor and analyze application logic for potential security risks.
* **Ensures Security by Design:** Integrates security measures early in the development process, preventing costly rework later on.
* **Complements Traditional Tools:** Works seamlessly alongside SAST, DAST, and SCA, providing a comprehensive 360° view of your security posture.
For more detailed information about BLSA, please visit our [BLSA documentation page](/latest/plateform-overview/key-features/blsa-business-logic-security-analysis).
![BLSA: Business Logic Security Analysis]()
***
## CybeDefend FAQs
Our platform embeds security from the very beginning of the development process. By detecting vulnerabilities early, CybeDefend prevents costly rework and ensures that security is a fundamental part of your coding practices.
BLSA (Business Logic Security Analysis) is a groundbreaking new scanner that employs AI agents to detect design flaws and vulnerabilities within the business logic of your applications. It ensures security by design and complements traditional scanning tools like SAST, DAST, and SCA. [Learn more about BLSA](/blsa)
Unlike traditional cybersecurity tools that offer fragmented solutions, CybeDefend provides a unified platform encompassing all standard security tools plus innovative features like BLSA. This holistic approach delivers comprehensive protection across the entire development lifecycle.
CybeDefend is designed for everyone—from individual developers and SMEs to large enterprises. Our scalable and flexible plans ensure that robust cybersecurity is accessible to organizations of all sizes.
For further information, please explore our [Website](https://www.cybedefend.com/).
# Jira Cloud
Source: https://docs.cybedefend.com/latest/issue-tracker-integrations/jira
Connect Atlassian Jira Cloud to turn CybeDefend vulnerabilities into trackable tickets, with two-way status sync via webhooks.
The Jira integration lets you push CybeDefend findings (SAST, SCA, IaC, Container, Secret) into your Atlassian Jira Cloud projects as tickets — either manually for selected vulnerabilities or **automatically after every scan**. Ticket status, priority, and assignee are kept in sync with CybeDefend in near real-time through Jira webhooks.
Only **Jira Cloud** is supported. Jira Data Center / Server is not currently compatible because the integration relies on Atlassian's OAuth 2.0 (3LO) flow and Cloud webhook APIs.
***
## What you get
* **Ticket creation** for one or many vulnerabilities, with three grouping strategies (per vulnerability, per type, per file).
* **Rich descriptions** in Atlassian Document Format (ADF), including CVSS, CWE/OWASP tags, file location, fix recommendations, and a direct link back to the CybeDefend view.
* **Severity → priority mapping** (Critical → Highest, High → High, …) applied to each issue.
* **Auto-create after scan** to file tickets without human intervention (configurable per project).
* **Branch allow-list** so tickets are only created for findings on branches you care about (e.g. `main`, `develop`).
* **Live status sync** via Jira webhooks — status, assignee, priority, and project moves are reflected in CybeDefend automatically.
* **Link to existing issue** for vulnerabilities already tracked under another ticket.
* **Duplicate protection** — open tickets are reused; closed tickets do not re-open silently.
***
## Prerequisites
You need a user that has access to the target Jira Cloud site and can install OAuth apps for it.
The OAuth app requests the following scopes:
* `read:jira-work` — list projects, read issues
* `write:jira-work` — create and update tickets
* `read:jira-user` — resolve assignees
* `manage:jira-webhook` — register the status-sync webhook
* `offline_access` — refresh tokens automatically
You must hold the `manage_integration` permission on the organization (Owner or Admin).
***
## 1. Connect Jira to your organization
In CybeDefend, go to **Organization Settings → Integrations** and select **Jira**.
Click **Connect Jira**. You will be redirected to Atlassian to authorize the CybeDefend app. A CSRF state token is stored server-side for 10 minutes — finish the flow within that window.
Approve access for the Jira Cloud site you want to use. If multiple sites are accessible to your Atlassian account, the integration uses the **first accessible site** returned by Atlassian.
On callback, CybeDefend exchanges the authorization code for an access token, encrypts it with AES-256-GCM, and registers a webhook so issue updates flow back automatically.
Tokens are encrypted at rest. Refresh is automatic — you do not need to re-authorize unless the integration is uninstalled from the Atlassian side.
***
## 2. Map a CybeDefend project to a Jira project
The OAuth connection is at the **organization** level. Each CybeDefend project then points to a single Jira project that will receive its tickets.
From the project view, go to **Settings → Integrations → Jira**.
Select the destination Jira project from the dropdown. CybeDefend fetches up to 100 projects from the connected site, ordered by name.
Add up to **50 branches** (e.g. `main`, `develop`, `release/*`) to the allow-list. Vulnerabilities detected on any other branch will be **silently skipped** when creating tickets. Leave the list empty to allow all branches.
Toggle **Auto-create tickets after scans** if you want every new finding (matching the branch allow-list) to be filed automatically once a scan completes.
For triage-heavy projects, leave **auto-create off** and use the **per vulnerability type** mode manually — you'll get one ticket per CWE/CVE rather than one ticket per occurrence, which is far easier to action.
***
## 3. Create tickets for vulnerabilities
From the vulnerability list (SAST, SCA, IaC, Container, Secret), select one or more findings and choose **Create Jira issues**. You pick the **grouping mode**:
| Mode | Behavior | When to use |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| **Per vulnerability** | One Jira ticket per individual detection (`vulnerabilityId + filePath + line`, or `vulnId + package@version` for SCA). | Fine-grained tracking, small batches. |
| **Per vulnerability type** | One ticket per rule / CVE, grouping all occurrences. | Default — best signal-to-noise ratio. |
| **Per file** | One ticket per `(scanner, file path)`. SCA tickets group by dependency manifest. | Code reviews organized by file owner. |
### What's in the ticket
* **Summary** — human-readable name (e.g. `lodash: Prototype pollution in lodash.merge`) with a `[CybeDefend]` prefix and a count suffix when grouped.
* **Description** (ADF) — severity, CVSS, CWE/OWASP, fix recommendation, code snippet for SAST, package details for SCA, and a deep link back to the matching CybeDefend view (filtered by name).
* **Priority** — mapped from severity: Critical → Highest, High → High, Medium → Medium, Low → Low, Info → Lowest.
* **Issue type** — `Bug` if available, otherwise `Task`, then `Story`, falling back to the first non-subtask type in the project's create-meta.
Before creating a ticket, CybeDefend checks for an **existing open ticket** with the same group key, or vulnerabilities already linked to a non-terminal ticket (`open`, `in progress`, …). Duplicates are skipped, not re-filed. Tickets in `done`, `closed`, `resolved`, or `deleted` states do not block re-creation.
***
## 4. Link to an existing Jira issue
If a ticket already exists for the work, you can attach CybeDefend vulnerabilities to it instead of creating a new one.
Select the findings in the CybeDefend vulnerability list and choose **Link to existing Jira issue**.
Provide the Jira key (e.g. `TRI-142`). CybeDefend validates the key exists and reads its current summary and status.
CybeDefend records the mapping and **appends** a "Linked CybeDefend vulnerabilities" section to the existing Jira description — your original description is never overwritten.
***
## 5. Status synchronization
CybeDefend registers a **dynamic webhook** at install time, listening to `jira:issue_updated` and `jira:issue_deleted` for every project on the site. When a ticket changes in Jira, CybeDefend updates the linked vulnerabilities within seconds:
* **Status** — reflected as `issueState` (e.g. `in progress`, `done`).
* **Priority** — stored on the mapping.
* **Assignee** — the Jira display name is mirrored.
* **Project key** — if a ticket is **moved between Jira projects**, the new key is detected via the changelog and all mappings are updated.
* **Deleted issues** — marked as `deleted` in CybeDefend.
Dynamic webhooks expire after 30 days; CybeDefend refreshes them periodically through a background cron, so no manual action is needed.
If a webhook ever misses an event, you can trigger a **manual sync** from the project's Jira integration panel — CybeDefend will pull the latest status for each linked ticket and detect any project moves at the same time.
***
## 6. Disconnecting Jira
Disconnecting from **Organization Settings → Integrations → Jira → Disconnect** will:
1. Remove the OAuth integration and stored tokens.
2. Delete every per-project Jira configuration (mapping, allowed branches, auto-create setting).
3. Remove every vulnerability ↔ Jira issue mapping for the organization.
4. **Leave the Jira tickets untouched** — they remain in Jira and are no longer linked back to CybeDefend.
To use Jira again afterwards, simply re-run the connect flow.
***
## Troubleshooting
Your Atlassian account does not have access to any Jira Cloud site, or your administrator has restricted OAuth apps for the site. Ask your Jira admin to grant access or approve the CybeDefend app.
The CybeDefend project has no mapping yet. Open **Project Settings → Integrations → Jira** and select a destination Jira project.
Check three things: (1) **Auto-create** is enabled on the CybeDefend project, (2) the scan's branch is in the **allow-list** (or the list is empty), (3) the vulnerability isn't already linked to an open Jira ticket — duplicates are intentionally skipped.
The webhook may have been removed at the Jira side, or the webhook expired. Disconnect and reconnect the integration to re-register it, or use the manual **Sync status** action on the project's Jira panel.
The CSRF state token lives for 10 minutes. Restart the install flow from CybeDefend instead of refreshing the Atlassian callback page.
***
**Related:** [Project Vulnerability List](/latest/managing-vulnerabilities/project-vulnerability-list) · [Updating Vulnerabilities](/latest/managing-vulnerabilities/updating-vulnerabilities)
# Findings Export (GRC / SIEM)
Source: https://docs.cybedefend.com/latest/managing-vulnerabilities/findings-export
Pull every finding across your organization from a single cursor-paginated endpoint, designed for GRC platforms and SIEM ingestion.
The **Findings Export** is a read-only, organization-wide feed of your security findings. It exists for machines: a GRC platform, a SIEM, a compliance warehouse, or any internal job that needs the whole picture on a timer rather than one project at a time in the dashboard.
This is a **public contract**. Field names are `snake_case`, and every optional field is always present. When there is no value for a field, it is explicitly `null`, so a consumer can tell "never triaged" apart from "field missing".
## Endpoint
```http theme={null}
GET /organization/{organizationId}/findings
```
Authenticate with a bearer token, exactly as elsewhere in the API. Use the base URL of the region your organization is hosted in: `https://api-eu.cybedefend.com` (EU) or `https://api-us.cybedefend.com` (US).
```bash theme={null}
curl -H "Authorization: Bearer $CYBEDEFEND_TOKEN" \
"https://api-eu.cybedefend.com/organization/$ORG_ID/findings?severity=critical,high&page_size=100"
```
## Scope
The export covers the projects your token has access to. The `project_id` filter can only **narrow** that set, never widen it.
## Query parameters
| Parameter | Type | Description |
| --------------- | --------- | ---------------------------------------------------------------------------------- |
| `status` | enum list | `to_verify`, `confirmed`, `ignored`, `resolved`. Omit for every state. |
| `severity` | enum list | `critical`, `high`, `medium`, `low`, `none`. Computed from the current CVSS score. |
| `project_id` | uuid list | Restrict to these projects. Max 200 per page. |
| `updated_since` | ISO 8601 | Findings whose lifecycle changed at or after this instant. |
| `cursor` | string | Opaque cursor from `next_cursor`. Do not construct or edit it. |
| `page_size` | integer | 1 to 100. Defaults to 50. |
List parameters accept **both** spellings and any mix of the two:
```
?status=confirmed,ignored
?status=confirmed&status=ignored
```
**A mistyped filter fails loudly. It never widens the scope.**
An unknown value (`?status=confimed`), an unrecognised parameter name (`?statuss=`), or a filter that is present but empty (`?status=`) all return **400**. On a compliance feed, silently dropping a filter would return your entire organization while you believed you asked for one status, so the API refuses the request instead.
## Response
```json theme={null}
{
"success": true,
"message": "Findings retrieved",
"data": {
"findings": [
{
"id": "a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1a3f1",
"finding_type": "sast",
"project_id": "11111111-1111-4111-8111-111111111111",
"project_name": "payments-api",
"title": "SQL injection in the invoice lookup",
"description": "User input reaches the query builder unescaped.",
"remediation": "Bind the parameter instead of concatenating it.",
"severity": "critical",
"status": "confirmed",
"url": "https://app.cybedefend.com/...",
"first_detected_at": "2026-07-02T09:14:00.000Z",
"last_detected_at": "2026-08-30T02:11:00.000Z",
"triaged_at": "2026-07-03T16:20:00.000Z",
"triaged_by": "22222222-2222-4222-8222-222222222222",
"triaged_by_type": "user",
"resolved_at": null,
"dismissal_reason": null,
"details": { "file": "src/invoices/lookup.ts", "line": 88 },
"updated_at": "2026-08-30T02:11:00.000Z"
}
],
"next_cursor": "...",
"has_more": true,
"next_since": "2026-08-30T02:10:55.000Z"
}
}
```
### Notable fields
Survives reindentation, line drift and scanner rule renames. It **does** change when the file is renamed, when the vulnerable code itself changes, or when one of several identical occurrences in a file disappears.
Computed from the CVSS 4 environmental score, falling back to the base score. `none` is a real band (a CVSS score of exactly 0) and is exported.
`null` where the source carries none, such as OSV advisories (`sca`) and container findings. A null here means "we have no guidance", **not** "no action needed".
File and line for `sast`, package for `sca`, image for `container`, and so on. `null` when no structured details are available for the finding.
## Paginating one pull
Follow `next_cursor` until `has_more` is `false`. Results are sorted ascending on `updated_at`.
```bash theme={null}
CURSOR=""
while : ; do
PAGE=$(curl -s -H "Authorization: Bearer $CYBEDEFEND_TOKEN" \
"https://api-eu.cybedefend.com/organization/$ORG_ID/findings?page_size=100&cursor=$CURSOR")
echo "$PAGE" | jq '.data.findings[]'
[ "$(echo "$PAGE" | jq -r '.data.has_more')" = "true" ] || break
CURSOR=$(echo "$PAGE" | jq -r '.data.next_cursor')
done
```
`updated_at` is the sort key, so a finding modified mid-pagination moves forward in the stream and is delivered again. Consumers must be idempotent on `id`.
## Pulling incrementally
Store the `next_since` of your last page and replay it verbatim as `updated_since` on the next run. That is the whole contract: you do not compute the watermark yourself.
```
run 1: GET .../findings -> next_since = T1
run 2: GET .../findings?updated_since=T1 -> next_since = T2
run 3: GET .../findings?updated_since=T2 -> ...
```
`next_since` is set a few seconds before the last row served, so that consecutive runs overlap slightly. This guarantees that no finding is skipped. Overlap is cheap, a missed finding is not.
## Rate limiting
A GRC platform polls on a timer, so **429 is part of this contract, not an error path**. Back off and retry.
| Status | Meaning |
| ------ | ------------------------------------------------------------------- |
| `400` | Unknown parameter name, unknown filter value, or an emptied filter. |
| `401` | Missing or invalid token. |
| `403` | The token is not allowed to export findings for this organization. |
| `429` | Rate limited. Back off and retry. |
# Project Vulnerability List
Source: https://docs.cybedefend.com/latest/managing-vulnerabilities/project-vulnerability-list
Dive into a specific project's vulnerabilities, with filters and sorting for clear organization.
Once you select a project from the **Global Dashboard**, you’ll land on the **Project Vulnerability List**. This section consolidates **all vulnerabilities** for a single project—whether discovered by SAST, IAC, or SCA scanning.
![Project Vulnerability List Interface]()
## Scanner Tabs & Filters
1. **Scanner Tabs**\
Switch between **SAST**, **IAC**, **SCA** or **CONTAINER** tabs to isolate vulnerabilities discovered by each scanner type. This helps you focus on code issues, infrastructure misconfigurations, or library dependencies, respectively.
2. **Severity Filter**\
Show or hide vulnerabilities at different severity levels (e.g., Critical, High, Medium, Low).
3. **Status Filter**\
Limit results to vulnerabilities marked **To Verify**, **In Progress** or **Resolved** etc.
4. **Priority Filter**\
If you’ve tagged vulnerabilities with internal priorities (Critical Urgent, Urgent, Normal, High, Low), you can quickly narrow down the list to see which require immediate attention.
5. **Sort Options**
* **Severity**: Sort by ascending or descending severity.
* **CVSS Score** (SCA-only): Sort libraries by their numeric score to find the most dangerous dependencies first.
**1. Break it down by Scanner**\
If your codebase is quite large, start with SAST to address code-based vulnerabilities, then move on to IAC for cloud misconfigurations.
**2. Sort by Priority**\
Combining severity + priority helps you quickly form a top-10 list to tackle.
**3. Batch Update**\
Some teams use a weekly bug triage meeting to set statuses or priorities for multiple vulnerabilities at once.
Always re-run or schedule scans after significant code or infrastructure changes to keep this list accurate.
# Top Vulnerabilities
Source: https://docs.cybedefend.com/latest/managing-vulnerabilities/top-vulnerabilities
A unified Top N list of the highest-priority vulnerabilities across every scanner in a project
## Overview
The **Top Vulnerabilities** view answers the single most important triage question — *"if I had time for only five fixes today, which ones should I take?"*
It ranks **active** vulnerabilities across **every scanner** (SAST, SCA, IAC, Container, CICD, Secrets) on a single composite priority score, so the most urgent items always surface first — regardless of which scanner detected them.
One ranked list across SAST · SCA · IAC · Container · CICD · Secrets
Sorted by composite Priority Score, not raw severity
Excludes resolved / ignored detections automatically
Default Top 5 — request any N via the API
***
## What "Top" means
Each detection is scored by the platform's [Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) engine — a weighted blend of CVSS 4.0 environmental score, EPSS percentile, exploitability verdict and project Security Context. The Top Vulnerabilities list returns the **N highest composite scores** across the project.
Only detections in an **active** state are eligible:
* `to_verify`
* `proposed_not_exploitable`
* `confirmed`
Resolved, ignored, fixed and false-positive findings are excluded — the list is always a current to-do.
A re-scored detection (after a Security Context change or an exploitability verdict update) can enter or leave the Top in real time. There is no daily snapshot — the ranking is computed on demand.
***
## API reference
```http theme={null}
GET /project/{projectId}/results/top-vulnerabilities?limit=5
```
| Parameter | In | Type | Description |
| ----------- | ----- | ------- | -------------------------------------------- |
| `projectId` | path | UUID | The project to query |
| `limit` | query | integer | Number of items to return. Defaults to **5** |
### Response shape
```json theme={null}
{
"items": [
{
"id": "b41…",
"vulnerabilityType": "sca",
"name": "CVE-2024-12345",
"description": "Prototype pollution in lodash",
"severity": "critical",
"compositeScore": 0.842,
"cvss4EnvironmentalScore": 9.4,
"exploitabilityVerdict": "proven",
"exploitabilityReason": "Reachable from production code path",
"exploitabilityScoreReason": "Used in src/server/index.ts",
"exploitabilitySource": "agent",
"filePath": null,
"line": null,
"cveId": "CVE-2024-12345",
"cwe": [],
"packageName": "lodash"
}
]
}
```
| Field | Notes |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `vulnerabilityType` | One of `sast`, `iac`, `cicd`, `secret`, `sca`, `container` |
| `compositeScore` | Internal 0–1 composite priority (× 100 = user-facing Priority Score) |
| `cvss4EnvironmentalScore` | The project-adjusted CVSS 4.0 score used in the calculation |
| `exploitabilitySource` | `agent`, `manual` or `static` — see [Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) |
| `filePath` / `line` | Populated for SAST, IAC, CICD and Secrets findings |
| `cveId` / `packageName` | Populated for SCA and Container findings |
| `cwe` | CWE identifiers for code-based findings |
***
## How items are selected
For each scanner table, the service pre-loads `max(limit × 4, 20)` rows ordered by stored `priorityScore DESC`. This keeps the candidate pool large enough that re-scoring with the current Security Context cannot demote a true winner.
Each candidate is re-scored with the project's current Security Context (business criticality, data classification) so the ranking always reflects the latest configuration — not the score stored at the time of the scan.
All candidates from all scanners are merged and sorted by `compositeScore` descending. The first `limit` items are returned.
Detections with a **manual priority override** keep their stored score and are included in the ranking unchanged. If you want them re-evaluated, clear the override first.
***
## Where it appears
* **Project dashboard** — the *Top 5* widget on the project overview.
* **Email reports** — periodic vulnerability reports start with the project's Top items.
* **Cybe MCP & API** — agents and external integrations consume the same endpoint to brief developers on the day's priorities.
***
## Best practices
The Top list is most useful once the project's **Internet Exposure**, **Environment**, **Data Classification** and **Business Criticality** are set. Without context, the CVSS environmental score and the Context signal fall back to neutral defaults and the ranking becomes a CVSS-only sort.
The default `limit=5` matches what a developer can realistically address in a day. A wider `limit=25` is better suited to weekly grooming or release-readiness reviews.
A `not_exploitable` verdict from Cybe Analysis can keep a CVSS 9.8 out of the Top — that is by design. Review the `exploitabilityReason` before reopening.
Pair the Top list with a [Policy](/latest/plateform-overview/key-features/policy-management) that blocks merges when any Top item is in the `Critical Urgent` bucket. Triage becomes self-enforcing.
***
**Related:** [Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) · [CVSS 4.0 Scoring](/latest/plateform-overview/key-features/cvss-4-scoring) · [Project Vulnerability List](/latest/managing-vulnerabilities/project-vulnerability-list) · [Updating Vulnerabilities](/latest/managing-vulnerabilities/updating-vulnerabilities)
# Updating Vulnerabilities
Source: https://docs.cybedefend.com/latest/managing-vulnerabilities/updating-vulnerabilities
Easily change vulnerability status, priority, and add comments to coordinate fixes.
CybeDefend streamlines remediation by letting you **update each vulnerability** (found by SAST, IAC, or SCA) directly from the dashboard. Whether you’re marking it as “In Progress” or adding a priority label, you can keep the entire team aligned.
![Vulnerability Update Popup]()
## Steps to Update
1. **Open the Vulnerability**\
In the project’s vulnerability list, click a specific item to reveal the **Update Popup**.
2. **Edit Fields**
* **Status**: Switch from To Verify → Confirmed.
* **Priority**: Assign internal priority tags (e.g., critical, low).
* **Comment**: Record progress, decisions made, or references to external tickets.
3. **Confirm & Save**\
Changes are immediately visible to all team members, helping them see updated statuses without additional overhead.
## Dismissing a finding requires a justification
Setting a finding to **Ignored** — in the dashboard, through the API, or through the Cybe MCP tool — now requires a written reason. A dismissal without one is refused.
**Breaking change.** Any integration that sets `status: "ignored"` must now send `dismissalReason` alongside it. Requests that omit it fail validation with `dismissalReason is required when status is "ignored"`.
| Rule | Value |
| -------------- | ------------------------------------------ |
| Required when | `status` is `ignored` |
| Blank values | Rejected — whitespace only is not a reason |
| Maximum length | 512 characters |
```json theme={null}
{
"vulnerabilityId": "11111111-1111-4111-8111-111111111111",
"status": "ignored",
"dismissalReason": "Accepted risk — signed off by the CISO on 2026-07-01"
}
```
The same rule applies to **bulk dismissal**: each item in a batch update carries its own `dismissalReason`, so a bulk action stays audited rather than becoming a way around the requirement.
The justification is recorded against the finding and surfaces as `dismissal_reason` in the [Findings Export](/latest/managing-vulnerabilities/findings-export). Automated triage is held to the same standard — when Cybe Agent dismisses a finding, it records its own reason and is attributed as `agent`.
![After Updating Vulnerability]()
Use the comment field for quick, contextual notes. This eliminates the need for separate emails or Slack threads where details can get lost.
***
## Consistent Management Across Scanners
A critical SAST finding about SQL injection can be handled the same way as a high-severity IAC misconfiguration in Terraform. This uniform approach:
* **Reduces Confusion**: No separate tools or flows for each scanner.
* **Speeds Remediation**: Everyone uses the same interface, no matter the vulnerability source.
Consider adopting weekly triage sessions where you review newly detected vulnerabilities and update them as a team.
# Slack
Source: https://docs.cybedefend.com/latest/notifications/slack
Connect your Slack workspace to receive CybeDefend scan results, security alerts, and reports directly in your team channels.
The **Slack integration** lets CybeDefend push security notifications into the channels your team already uses. Once connected, you can map any project to a Slack channel and receive scan completions, zero-day alerts, and periodic security reports — without leaving Slack.
***
## What You Get
A summary of every scan: total findings, severity breakdown, and per-scanner counts (SAST, SCA, IaC, secrets, containers).
Instant notifications when newly disclosed vulnerabilities affect packages already in your projects.
A 7-day summary of open findings, new vulnerabilities, and resolved issues per project.
A monthly rollup with severity distribution and trend indicators to share with stakeholders.
***
## Prerequisites
* You must have **Administrator** or **Manager** privileges on the CybeDefend organization (the `manage_integration` permission).
* You must be a **workspace admin** in Slack, or have permission to install Slack apps in your workspace.
The Slack integration is configured at the **organization level**. Once connected, every project in the organization can map a channel — but each project can only target a single channel.
***
## 1. Connect Your Slack Workspace
From the CybeDefend dashboard, go to your **Organization settings → Integrations**, then click **Slack**.
A Slack authorization window opens. You will be asked to choose the workspace to install the CybeDefend app into.
Slack will list the permissions the app needs:
* `chat:write` — post messages in channels the app is a member of
* `channels:read` — list public channels in the workspace
* `groups:read` — list private channels the app is invited to
Click **Allow** to complete installation.
The popup closes automatically and the integration modal shows your workspace name with a **Connected** badge. You are now ready to map channels to projects.
If your Slack workspace requires admin approval for third-party apps, the install request is sent to your workspace administrator. Installation completes once it is approved.
***
## 2. Map a Channel to a Project
Each project routes its notifications to one Slack channel. The mapping is configured from the project itself.
Navigate to your project → **Settings → Notifications**.
Click the **Slack channel selector**. A searchable dropdown lists all accessible channels in the connected workspace — public channels and private channels the app has been invited to.
Pick a channel (e.g. `#security-alerts`). The CybeDefend bot will automatically join public channels selected here.
**Private channels:** The CybeDefend bot cannot auto-join private channels. You must invite it manually with `/invite @CybeDefend` inside the channel before notifications can be delivered.
To **remove** the mapping, click the **×** next to the channel name. The project will stop sending notifications to Slack but the workspace integration remains active.
***
## Notification Anatomy
All CybeDefend Slack messages share a consistent layout: a colored sidebar indicating severity, a header with the project name, a compact breakdown, and an action button that deep-links into the CybeDefend dashboard.
| Color | Meaning |
| --------- | --------------------------------------- |
| 🔴 Red | At least one **Critical** finding |
| 🟠 Orange | At least one **High** finding |
| 🟡 Yellow | At least one **Medium** finding |
| 🔵 Blue | Only **Low** findings, or informational |
| 🟢 Green | Clean scan — no vulnerabilities |
### Example: Scan Complete
```
✅ Scan Complete
my-frontend-app — `main` · SAST · SCA
5 vulnerabilities found
🔴 1 critical · 🟠 2 high · 🟡 2 medium
[ View Results ]
```
### Example: Zero-Day Alert
```
🚨 Zero-Day Vulnerability Alert
2 new vulnerabilities detected in api-backend
🔴 CVE-2025-12345 — CRITICAL · CVSS 9.8
🟠 CVE-2025-67890 — HIGH · CVSS 7.5
[ View Details ]
```
***
## Permissions Reference
| Action | CybeDefend permission | Scope |
| ------------------------------- | ------------------------------- | ---------------------- |
| Connect / disconnect Slack | `manage_integration` | Organization |
| List workspace channels | `manage_integration` | Organization |
| Map a channel to a project | `manage_integration` + `update` | Organization + Project |
| View a project's mapped channel | `start_scan` | Project |
***
## Disconnect Slack
Disconnecting Slack removes the integration **and all project channel mappings** in the organization.
Organization settings → Integrations → **Slack**.
Confirm in the dialog. CybeDefend will revoke the bot token and delete the workspace mapping.
Disconnecting is **irreversible from the dashboard**: project–channel mappings are deleted on disconnect. You will need to reconfigure them after re-installing the app.
***
## Security & Privacy
The Slack bot token is encrypted at rest using **AES-256-GCM** before being stored in CybeDefend's database.
The integration requests only the scopes needed to list channels and post messages — no message reading, no user identity scopes.
CybeDefend never sends source code, secrets, or vulnerable file contents to Slack. Messages only include metadata (counts, severities, CVE IDs, deep links).
Disconnecting from CybeDefend revokes the bot token. You can also remove the app directly from your Slack workspace admin panel.
***
## Troubleshooting
* Verify the workspace is still **Connected** in Organization settings → Integrations.
* Confirm the project has a channel mapped (Project → Settings → Notifications).
* For **private channels**, ensure the CybeDefend bot has been invited with `/invite @CybeDefend`.
* Check that your organization is not in a **read-only** billing state — notification dispatch is gated by writability.
* The bot lists **public channels** and **private channels it is already a member of**. Invite the bot to any private channel you want to use.
* If even public channels are missing, try disconnecting and re-installing the Slack app to refresh the workspace token.
* Verify popups are not blocked for the CybeDefend dashboard origin.
* Make sure your Slack workspace allows installation of third-party apps. If admin approval is required, your request is pending in the Slack admin console.
The bot tried to post in a channel it is not a member of. For public channels, re-select the channel in the project settings — CybeDefend will attempt to auto-join. For private channels, invite the bot manually.
***
**Related:** [Managing Vulnerabilities](/latest/managing-vulnerabilities/project-vulnerability-list) · [Policy Management](/latest/plateform-overview/key-features/policy-management) · [Account Setup](/latest/get-started/account-setup/assigning-roles)
# AI-BOM & EU AI Act Compliance
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/ai-bom
Inventory every AI component in your code — models, datasets, frameworks, agents, MCP servers, guardrails — and assess compliance with the EU AI Act
## Overview
The **AI-BOM** (AI Bill of Materials) scanner builds a complete inventory of the artificial intelligence and machine-learning components used by your project. It discovers AI models, ML frameworks, AI SDKs, datasets, vector stores, agents, MCP servers, guardrails and model weight files directly from your source code and dependency manifests — then maps each component to the obligations of **Regulation (EU) 2024/1689 (the EU AI Act)**.
AI-BOM is a dedicated scanner type, alongside SAST, SCA, Container, IaC and Secret scanning. Unlike the others, it does not report vulnerabilities — it produces a **structured inventory** of your AI supply chain and the regulatory context that applies to it.
Automatically discovers models, frameworks, SDKs, datasets, agents, MCP servers and guardrails across your codebase
Classifies each component by risk category and links it to the applicable articles and obligations
Output follows the standard CycloneDX 1.6 Machine Learning profile, ready to export and share
Detects and fingerprints loose model weight files (.safetensors, .gguf, .onnx, .pt…) on disk
***
## What Gets Detected
The AI-BOM scanner inventories AI/ML usage from several angles — imported packages, declared dependencies, hard-coded model identifiers and model files present in the repository.
| Component family | Examples |
| ------------------------------------ | ----------------------------------------------------------------------------------- |
| **AI models** | LLMs (GPT, Claude, Gemini, Llama…), embeddings, vision and speech models |
| **ML frameworks** | PyTorch, TensorFlow, Transformers, LangChain, LlamaIndex, scikit-learn |
| **AI SDKs & services** | Provider client libraries and hosted inference APIs |
| **Datasets & vector stores** | Vector databases, dataset loaders, retrieval stores |
| **AI applications** | Streamlit, Gradio, Chainlit and similar AI app frameworks |
| **Inference infrastructure** | Local inference engines and serving runtimes |
| **Agents, MCP servers & guardrails** | Agent frameworks, Model Context Protocol servers, safety/guardrail libraries |
| **Model weight files** | `.safetensors`, `.gguf`, `.ggml`, `.onnx`, `.pt`, `.pth`, `.h5`, `.pkl`, `.tflite`… |
Regular dependencies that have nothing to do with AI are **not** included — the AI-BOM focuses exclusively on AI/ML-relevant components. Code-level vulnerabilities remain the job of the SAST and SCA scanners.
***
## How Detection Works
The scanner combines multiple detection layers so that components are found even when one signal is missing:
1. **Dependency manifests** — parses Python `requirements*.txt`, `setup.py` and `pyproject.toml` to discover declared AI packages and pin their versions. UTF-8 and UTF-16 (Windows-generated) manifests are both supported.
2. **Source code analysis** — scans source files for AI-related imports and for hard-coded model identifiers (e.g. `"gpt-4o"`, `"claude-..."`, `"meta-llama/Llama-..."`) that would otherwise go unrecorded.
3. **Model weight files** — discovers model artifacts on disk by extension, records them as components and fingerprints them with a SHA-256 hash.
4. **Version & evidence enrichment** — attaches versions from manifests and records the exact file location where each component was found.
### Coverage
* **Primary language:** Python (`.py`)
* **Additional languages:** JavaScript / TypeScript, Go, Java, Kotlin, Ruby, Rust, C#, C/C++, Shell, and configuration files (YAML / TOML / JSON, Dockerfiles)
Build and vendor directories (`node_modules`, `venv`, `__pycache__`, `dist`, `build`, `.git`, …) are automatically excluded from the inventory.
***
## Component Types
Every component is classified using the **CycloneDX 1.6** native component types:
| Type | Typical AI usage |
| ------------------------ | --------------------------------------------------- |
| `machine-learning-model` | LLMs, embeddings, vision models, model weight files |
| `framework` | PyTorch, TensorFlow, LangChain, Transformers |
| `library` | AI SDKs, ML utility libraries |
| `data` | Datasets, vector stores, retrieval sources |
| `application` | AI app frameworks (Streamlit, Gradio, …) |
| `container` | Inference engines and serving runtimes |
| `file` | Loose model weight files detected on disk |
***
## Inventory Output
For each detected component, the AI-BOM records a rich, standards-aligned set of fields:
* **Identity** — `name`, `version`, `type`, `purl` (Package URL) and `source` (e.g. a model hub, a package registry, a Git repository, or a local file)
* **Licenses** — SPDX identifiers extracted from the component, including composite expressions
* **Evidence** — the file path (and line where available) proving where the component is used
* **Hashes** — SHA-256 fingerprints for model weight files
* **External references** — links to model cards, documentation and source repositories
* **Model card** — for ML models, structured metadata such as model parameters, quantitative analysis and considerations (when available)
* **Tags & metadata** — additional classification labels and key/value metadata
The complete inventory is also available as a raw **CycloneDX 1.6 ML-BOM** JSON document that you can export and feed into other tools or share with auditors.
***
## EU AI Act Compliance
Beyond the inventory, the AI-BOM evaluates your AI components against **Regulation (EU) 2024/1689**.
### Risk Categories
Each component is mapped to an EU AI Act risk category:
| Category | Meaning |
| -------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Prohibited** | Practices banned under the EU AI Act (e.g. social scoring, certain biometric uses) |
| **High** | High-risk uses subject to strict obligations (e.g. employment screening, law enforcement, biometric identification) |
| **Limited** | Uses requiring transparency towards users (e.g. chatbots, synthetic/AI-generated content) |
| **Minimal** | Default category for components with minimal regulatory obligations |
### General-Purpose AI & Systemic Risk
The scanner identifies **General-Purpose AI (GPAI)** models and flags those that may fall under **systemic-risk** provisions (Article 51 and following), so you can quickly see which components carry the heaviest obligations.
### Compliance Report
A per-framework compliance report aggregates the analysis for a project and branch:
* Total components evaluated
* Breakdown by risk category
* Count of components flagged for systemic risk
* Applicable **obligations** and **articles**, with the components each one applies to
The AI-BOM inventory and compliance report together form the kind of technical record (in the spirit of the EU AI Act's Annex IV) that you can present to demonstrate visibility over your AI supply chain.
***
## Enabling AI-BOM
AI-BOM scanning is configured per project.
Navigate to your project's scanning configuration, where you choose which analysis types to run (SAST, SCA, IaC, Container, Secret, AI-BOM).
Turn on the **AI-BOM** analysis type for the project.
Launch a scan as usual. When it completes, the AI-BOM inventory and compliance report are available for the scanned branch.
***
## Viewing Results
Once a scan completes, the AI-BOM results are available in the project dashboard:
* **Component inventory** — the full list of detected AI components, filterable by **branch** and **component type**
* **Per-component detail** — identity, licenses, evidence (where it was found), external references and model card metadata
* **Compliance view** — the EU AI Act risk breakdown, GPAI / systemic-risk flags and the applicable obligations
***
## Best Practices
Start with components mapped to the **Prohibited** and **High** risk categories — these carry the strongest regulatory obligations under the EU AI Act.
General-purpose AI models, and especially those flagged for systemic risk, come with additional obligations. Keep an eye on these as your AI usage grows.
AI models often ship under non-standard or restrictive licenses. Use the recorded license information to confirm your usage is permitted.
Export the raw CycloneDX 1.6 ML-BOM to share with auditors, feed into governance tooling, or keep as part of your technical documentation.
AI usage changes quickly. Run AI-BOM on the branches you care about so the inventory stays current.
***
**Related:** [License Compliance](/latest/plateform-overview/key-features/license-compliance) · [Policy Management](/latest/plateform-overview/key-features/policy-management) · [Managing Vulnerabilities](/latest/managing-vulnerabilities/project-vulnerability-list)
# BLSA: Business Logic Security Analysis
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/blsa-business-logic-security-analysis
Discover our AI-driven, holistic approach to identifying insecure-by-design flaws in your application.
Traditional scanners (SAST, IAC, SCA) excel at finding known patterns or misconfigurations. **Business Logic Security Analysis (BLSA)** goes a step further, using **AI agents** to interpret your application's overall architecture, highlighting **insecure-by-design** issues that can't be detected by standard rule-based tools.
![BLSA Overview]()
## Why BLSA?
1. **Contextual Understanding**\
AI doesn't just read lines of code—it understands how different parts interact, spotting vulnerabilities when business flows are implemented incorrectly (e.g., logic around payment processing or user account privileges).
2. **Agent-Based Analysis**\
Each AI "agent" focuses on a segment of your code, forming an overall "mental model." This is especially valuable for complex monoliths or microservices that standard scanners struggle to piece together.
3. **Split Prompting & Intelligent Correlation**\
We split large codebases into chunks (split prompting) so our AI system can analyze the entire repository in detail, then reassemble findings into a single, cohesive report.
**Availability.** BLSA is **live for design partners** and is not yet generally available. If you want access, ask us and we will tell you honestly whether your stack is a fit today. Follow the [Roadmap](https://cybedefend.featurebase.app/roadmap) for general availability.
***
## Potential Impact
* **Uncover Hidden Flaws**: Identify logic breaks that hackers can exploit, such as bypassing payment checks or manipulating workflow states.
* **Reduce Manual Audits**: BLSA can flag suspicious flows that might otherwise require specialized security consultants.
* **Enhance DevSecOps**: Integrating BLSA results alongside SAST, IAC, and SCA ensures a complete coverage of technical and logical vulnerabilities.
We do not publish the full technical architecture, but we run live demos on a real repository with design partners. Ask for one rather than take our word for it.
***
**Related:** [Cybe Analysis](/latest/plateform-overview/key-features/cybe-analysis) · [Security Champion](/latest/plateform-overview/key-features/cybe-security-champion) · [Roadmap](https://cybedefend.featurebase.app/roadmap)
# CVSS 4.0 Scoring
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cvss-4-scoring
Modern severity scoring with environmental adjustments based on your project security context
## Overview
CybeDefend computes a **CVSS 4.0** score for every vulnerability — across SAST, SCA, IAC, Container, CICD and Secrets. The platform stores two distinct values:
* a **Base Score**, derived from the vulnerability's intrinsic properties (attack vector, complexity, impact on confidentiality / integrity / availability),
* an **Environmental Score**, recomputed for each project from the **Security Context** you configure, so the same CVE can legitimately score differently across projects.
Latest FIRST.org standard with Vulnerable / Subsequent system impact metrics
Legacy CVSS 3.1 vectors are automatically converted to a CVSS 4.0 base vector
Project context (exposure, environment, data class) reshapes the score
If no vector is available, severity (Critical / High / Medium / Low) drives a sensible default
***
## How the score is built
For each detection, CybeDefend resolves a CVSS 4.0 base vector with the following priority:
1. **Direct CVSS 4.0 vector** if provided by the scanner or advisory.
2. **CVSS 3.1 vector** — converted into an equivalent CVSS 4.0 base vector (AV/AC/PR/UI/VC/VI/VA mapping, AT defaulted to None, scope handled).
3. **Severity-only fallback** — uses a curated default vector per severity tier.
The resulting **base score** is stored once. The **environmental score** is then recomputed every time the project's Security Context changes.
Both the base vector and the full environmental vector (including `MAV`, `MAT`, `MPR`, `CR`, `IR`, `AR`, `MSC`, `MSI`, `MSA` modifiers) are persisted so the scoring is fully auditable.
***
## Environmental modifiers
The Security Context of the project drives the environmental adjustments applied to the base vector:
| Context field | CVSS 4.0 metric(s) | Effect |
| ------------------------------------------------------------------------------ | ------------------------------------ | -------------------------------------------------------------------------------- |
| **Internet Exposure** (`public` / `internal` / `airgapped`) | `MAV` (Modified Attack Vector) | Network → Adjacent → Local as exposure shrinks |
| **Network Segmentation** (`flat` / `segmented` / `microsegmented`) | `MAT` (Modified Attack Requirements) | Segmented networks raise attack requirements |
| **Environment** (`development` / `staging` / `production`) | `MPR`, `CR`, `IR`, `AR` defaults | Dev raises required privileges; prod sets high CIA requirements |
| **Data Classification** (`public` / `internal` / `confidential` / `regulated`) | `CR`, `MSC` | Regulated data boosts confidentiality requirement and subsequent confidentiality |
| **Business Criticality** (`low` / `medium` / `high` / `mission_critical`) | `AR`, `MSA` | Mission-critical workloads boost availability requirement |
| **Handles PII** | `CR:H`, `MSC:H` | PII processing raises confidentiality weight |
| **Handles Payment Data** | `CR:H`, `IR:H`, `MSC:H`, `MSI:H` | Payment processing raises confidentiality and integrity |
| **Safety-Critical** | `IR:H`, `AR:H`, `MSI:H`, `MSA:H` | Safety workloads raise integrity and availability |
Explicit `dataClassification` / `businessCriticality` values override the `environment`-derived defaults. PII / Payment / Safety boosts are applied last and can only **upgrade** previous values, never downgrade them.
***
## Where to see the scores
* **Vulnerability list** — sortable by CVSS Score (SCA) and severity.
* **Vulnerability detail** — displays both Base Score and Environmental Score, the full CVSS 4.0 vector, and a human-readable explanation of each component.
* **Top Vulnerabilities** widget — surfaces the highest-priority items, including the environmental CVSS score per detection.
* **API** — every detection returned by the REST API exposes `cvss4BaseScore`, `cvss4EnvironmentalScore`, `cvss4Vector` and `cvss4EnvironmentalVector`.
***
## Recalculation triggers
Environmental scores are automatically recomputed when:
Any update to the project's Security Context (exposure, environment, data class, criticality, PII / Payment / Safety toggles) re-enqueues a CVSS recalculation for all active detections.
Newly ingested vulnerabilities are scored with the current Security Context as part of the ingestion pipeline.
When a more authoritative CVSS source becomes available (e.g. NVD publishes a CVSS 4.0 vector for a CVE previously scored from CVSS 3.1), the score is upgraded.
If the Security Context contains `unspecified` fields, the corresponding modifier is **skipped** rather than guessed — the base vector is preserved for that axis. Fill the context in **Project Settings** to get the most accurate environmental score.
***
## Severity vs. Score
Severity buckets (`Critical`, `High`, `Medium`, `Low`) remain available for filtering and reporting, but the **environmental CVSS score** is what the platform uses internally as the CVSS dimension of the [Priority Score](/latest/plateform-overview/key-features/priority-scoring).
Severity displayed in the UI follows the standard CVSS 4.0 mapping: ≥ 9.0 Critical · ≥ 7.0 High · ≥ 4.0 Medium · > 0 Low · 0 None.
***
**Related:** [Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) · [Top Vulnerabilities](/latest/managing-vulnerabilities/top-vulnerabilities) · [Exploitable Path](/latest/plateform-overview/key-features/exploitable-path)
# Cybe Analysis
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cybe-analysis
AI-powered vulnerability analysis that eliminates false positives and provides expert-level security insights.
Transform your vulnerability management with **Cybe Analysis**, an autonomous AI agent that analyzes, contextualizes, and prioritizes security findings with senior-level expertise.
![Cybe Analysis Interface]()
***
## What is Cybe Analysis?
Powered by proprietary code parsing technology and advanced AI algorithms, Cybe Analysis eliminates up to **90% of false positives** while providing deep contextual analysis of every vulnerability. Our knowledge graph system enables unprecedented understanding of your codebase, delivering expert-level security insights 24/7.
***
## Key Capabilities
### Intelligent False Positive Detection
Leverages proprietary knowledge graph technology to understand your entire codebase context. By analyzing data flows, dependencies, and business logic, it achieves industry-leading accuracy in distinguishing real vulnerabilities from false alarms.
### Senior-Level Security Expertise
Operates at the expertise level of a senior security analyst, providing detailed vulnerability assessments, risk scoring, and prioritization recommendations. Each finding includes comprehensive analysis covering exploitability, business impact, and remediation complexity.
### Proprietary Code Understanding
Our breakthrough parsing technology creates a complete knowledge graph of your application, enabling Cybe Analysis to trace vulnerability paths through complex codebases with unprecedented precision.
### Contextual Vulnerability Analysis
Evaluates vulnerabilities based on actual usage patterns, data sensitivity, and architectural considerations—ensuring you focus on what truly matters.
***
## Why Cybe Analysis?
* **Unmatched Accuracy**: Proprietary parsing technology delivers unprecedented precision
* **Time Savings**: Reduce security team workload by eliminating false positives
* **Expertise at Scale**: Access senior-level security analysis 24/7
* **Complete Data Control**: Self-hosted AI models ensure code remains within your infrastructure
Learn more about configuring and using Cybe Analysis in the [detailed guide](/latest/agent-ai-integration/cybe-analysis-detail).
# Cybe AutoFix
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cybe-autofix
AI-powered intelligent remediation that understands context and fixes vulnerabilities across your entire codebase.
Go beyond simple patches with **Cybe AutoFix**—an AI agent that understands, contextualizes, and intelligently remediates vulnerabilities across your entire codebase.
![Cybe AutoFix Interface]()
***
## What is Cybe AutoFix?
Traditional autofix solutions apply band-aid fixes without understanding the broader context. Cybe AutoFix revolutionizes remediation by leveraging our proprietary knowledge graph to comprehend the full scope of each vulnerability, ensuring fixes are not only secure but also maintain code quality, performance, and architectural integrity.
***
## Advanced Remediation Features
### Context-Aware Remediation
Performs deep contextual analysis using knowledge graph technology. Understands the vulnerability's root cause, its propagation through the codebase, and potential side effects of remediation.
### Intelligent Code Generation
Generates production-ready code that follows your team's coding standards, maintains consistency with existing patterns, and preserves business logic while eliminating vulnerabilities.
### Multi-File Coherent Fixes
When vulnerabilities span multiple files, Cybe AutoFix orchestrates coherent modifications across your entire codebase, ensuring all related components are properly updated and synchronized.
### Automated Pull Request Generation
Seamlessly integrates with GitHub and GitLab by automatically creating detailed pull requests. Each PR includes comprehensive documentation explaining the vulnerability, the fix approach, and architectural considerations.
### Regression Prevention
By understanding the complete codebase through our knowledge graph, Cybe AutoFix ensures fixes don't introduce new vulnerabilities or break existing functionality.
***
## Why Cybe AutoFix?
* **Comprehensive Understanding**: Every fix considers full application context
* **Developer-Ready Code**: Follows your coding standards and architectural patterns
* **Reduced MTTR**: Cut Mean Time To Remediation with intelligent, automated fixes
* **Learning System**: Continuously improves remediation strategies from your codebase patterns
Learn how to configure and use Cybe AutoFix in the [detailed guide](/latest/agent-ai-integration/cybe-autofix-detail).
# Cybe Chat
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cybe-chat
The in-dashboard AI security assistant. Ask Cybe anything about your security posture across every project you can access, drive actions on findings from a single chat, and pick up where you left off thanks to RGPD-compliant memory.
**Cybe Chat is the assistant baked into the CybeDefend dashboard.** It talks to the same MCP toolset that powers our IDE integrations, but with a UI tuned for SecOps and engineering managers: cross-project posture, human-in-the-loop write actions, persistent memory, and a quota-aware streaming experience.
***
## What Cybe Chat gives you
| Scope | Example prompts |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **All accessible projects** | *"Where are the most critical findings across our portfolio?"* — *"Which teams have unaddressed criticals older than 30 days?"* — *"Compare the SCA exposure between our payment and back-office repos."* |
| **A specific project** | *"What changed in this project's posture since last week?"* — *"Walk me through the open SAST findings on `develop`."* — *"List packages with known CVEs and a fix available."* |
| **The current page** | *"Summarise this vulnerability."* — *"Is there a similar pattern elsewhere?"* — *"Propose a status update."* The scope auto-locks to whatever you are looking at. |
Cybe Chat sees only what your CybeDefend account is permitted to see. Permify is the single source of truth — the chat reflects your team and project scopes exactly the way the dashboard does.
***
## Why it matters
Most security platforms ask you to click through five pages to answer "what's the riskiest thing on my plate right now?". Cybe Chat collapses that into one question.
* **Cross-project posture from one prompt.** Instead of switching between dashboards, ask in plain English. Cybe walks your accessible projects, aggregates findings, and answers with citations back to the right view in the UI.
* **Actions, not just answers.** When the right next step is "mark these SQLi findings as not-exploitable" or "raise this CVE to critical", Cybe proposes the action and waits for your approval. Every write is human-confirmed before it lands.
* **Same engine as your IDE.** Cybe Chat and the [Cybe MCP server](/latest/plateform-overview/key-features/mcp-server-integration) share the same typed toolset and the same Permify-backed authorization. The view you have in the dashboard is the view your AI agents have in Cursor, Claude Code or VS Code.
* **Memory that respects your data rights.** Cybe remembers your last conversation, your preferences and the context you opened the drawer on. You can read, edit and delete every entry from the chat settings — GDPR-compliant by design.
***
## Human-in-the-loop write actions
Cybe Chat can call the same 18 typed MCP tools as your IDE agents. Read tools (`list_vulnerabilities_*`, `get_project_overview`, …) run silently. **Write tools always require explicit user approval.**
When Cybe proposes an action — for example, updating the status of a finding — a card appears in the conversation:
```text theme={null}
Cybe proposes:
update_vulnerability
project · payments-api
finding · vs_8a3b · SQLi on /api/users
set status → not_exploitable
comment → "fixed by parameterised query helper"
[ Confirm ] [ Reject ]
```
Confirming the card re-checks your Permify scope at execution time. If your access was revoked between the proposal and the confirmation, the action is rejected on the spot. Every confirmed action lands in your CybeDefend audit trail with your user identity and timestamp — the same audit surface as a manual change in the dashboard.
***
## Cross-project posture, in practice
Cybe Chat introduces an **all-accessible-projects** scope that no other surface of the platform exposes today. From a single prompt, Cybe can:
* Aggregate severity counts across every project your account can read.
* Surface the top contributors to your overall risk (project, scanner, language, branch).
* Compare two projects side by side.
* Highlight outliers — a project that suddenly accumulated criticals, a package showing up in many repos, a finding pattern recurring across teams.
The scope is gated by Permify. If you only see five projects, Cybe only sees five projects. There is no "admin override" that bypasses your team boundaries.
***
## Memory you control
Cybe Chat remembers two kinds of state for you:
* **Conversations**: every thread you have started, so you can pick up where you left off.
* **Preferences**: the last conversation you opened, whether the drawer should auto-open on dashboard load, and similar UI hints.
A dedicated settings panel inside the drawer lets you:
* View the sanitised memory entries Cybe stores about you.
* Update a single preference (e.g. disable auto-open).
* **Permanently delete** any memory entry. The deletion is immediate and irreversible — it does not "soft-delete" or queue for backup expiry.
This matches our public stance on AI usage and privacy: see [LLM usage privacy](/latest/plateform-overview/security-privacy/llm-usage-privacy) for the full picture.
***
## Quota, errors, and feedback
The chat streams answers token by token over SSE. If anything goes wrong — service unavailable, plan quota exceeded, downstream rate limit, malformed prompt — a red banner appears below the chat header with a clear, dismissible error code. You see exactly why the answer stopped.
Every Cybe response carries a thumbs-up / thumbs-down. Thumbs-down opens a tag picker (`wrong verdict`, `missing context`, `inaccurate`, `ambiguous`, `incomplete`, `off-topic`) plus an optional correction field. The feedback feeds back into Cybe's evaluation harness and is also visible to your account admin, so the team can act on patterns.
***
## Where it slots in the platform
The hands-on guide: opening the drawer, picking a scope, approving actions, managing memory.
Same toolset, exposed to Claude Code, Cursor, VS Code Copilot Chat, Windsurf and any MCP-compatible agent.
The project-specific code consultation engine. Use it to chat about *how* to fix; use Cybe Chat to act on *what* is exposed.
What Cybe Chat does, and does not, send to a model. Memory retention and deletion guarantees.
# Cybe Security Champion
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cybe-security-champion
Your AI-powered security expert that provides instant, expert-level guidance directly within your development workflow.
Empower every developer with an **AI Security Champion** that provides instant, expert-level security guidance directly within your development workflow.
![Cybe Security Champion Interface]()
***
## What is Cybe Security Champion?
Traditional Security Champion programs struggle with scalability and availability. Cybe Security Champion revolutionizes this approach by providing each developer with **24/7 access to senior-level security expertise**. Through our advanced chat interface and deep codebase understanding, developers can instantly get answers about vulnerabilities, security best practices, and remediation strategies specific to their project.
***
## Your AI-Powered Security Expert
### Interactive Security Consultation
Engage in natural language conversations about any security concern. The AI understands your specific codebase context through our knowledge graph, providing tailored advice rather than generic recommendations.
### Proactive Security Education
Doesn't just fix problems—it educates. Each interaction includes explanations of security principles, helping developers understand why vulnerabilities occur and how to prevent them in future code.
### Project-Specific Insights
By analyzing your entire project through our proprietary parsing system, provides insights specific to your application's architecture, dependencies, and security posture.
### Real-Time Vulnerability Exploration
Developers can explore detected vulnerabilities interactively, asking questions about severity, exploitation scenarios, and remediation options with detailed explanations and code examples from your actual project.
### 24/7 Availability
Unlike human Security Champions with limited availability, Cybe is always accessible. Get instant security guidance at any time, whether during late-night coding sessions or urgent production issues.
***
## Understanding Security Champions
In traditional organizations, a **Security Champion** is a designated expert—typically a senior developer with security expertise—who serves as the bridge between development teams and security departments. However, this model faces challenges:
* **Limited Availability**: One person covering multiple teams means waiting times
* **Knowledge Bottlenecks**: Development slows when the Security Champion is unavailable
* **Scaling Issues**: Growing organizations struggle to maintain recommended ratios
* **Inconsistent Coverage**: Time zones and working hours create gaps
**Cybe Security Champion** solves these challenges by providing every developer with their own dedicated security expert, available instantly, 24/7, with comprehensive knowledge of your entire codebase.
***
## Why Cybe Security Champion?
* **Scalable Expertise**: Provide every developer with senior-level security knowledge
* **Contextual Relevance**: Every interaction is specific to your codebase and technology stack
* **Measurable Impact**: Track security posture improvement through reduced vulnerabilities
* **Seamless Integration**: Works within existing development workflows
Learn how to configure and use Cybe Security Champion in the [detailed guide](/latest/agent-ai-integration/cybe-security-champion-detail).
# CybeRisk Score
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/cyber-risk-score
Risk-based prioritization at the project level: a single CVSS-weighted score that ranks every project by how much real risk it carries
## Overview
[Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) tells you *which finding to fix first inside a project*. The **CybeRisk Score** answers the level above it, *which project carries the most risk right now*, so security teams can prioritize **across an entire portfolio**, not just within a single repository.
It is a single number computed by summing a CVSS-weighted point contribution over every **active** vulnerability on a project's reference branch. Higher-severity findings contribute disproportionately more points, so the score reflects both the **volume** and the **severity** of open risk.
One risk number per project, aggregated across all six scanners
Critical findings contribute up to 20× more points than Low ones
Not capped at 100. A large, risky project can score in the hundreds
Per-scan-type contributions and the top 5 risk contributors
***
## The formula
The CybeRisk Score is the **rounded sum** of each active vulnerability's point contribution:
```
CybeRiskScore = round( Σ pointsFromVuln(v) ) for every active vulnerability v
```
Each vulnerability is mapped to points by linearly interpolating its effective CVSS inside its severity band:
| CVSS band | Points formula | Range |
| -------------------------- | ---------------------------- | ---------- |
| **Critical** `[9.0, 10.0]` | `15 + (cvss − 9) × 5` | 15 → 20 |
| **High** `[7.0, 9.0)` | `5 + (cvss − 7) × (5 / 1.9)` | 5 → \~10.3 |
| **Medium** `[4.0, 7.0)` | `2 + (cvss − 4) × (2 / 2.9)` | 2 → \~3.4 |
| **Low** `[0.1, 4.0)` | `1` (constant) | 1 |
The scale is **deliberately unbounded**. Unlike a normalized 0–100 score, a sum lets a project with 50 critical findings clearly outrank one with 5, so the number grows with the real backlog of risk.
### Which CVSS is used
The effective CVSS is resolved in priority order, falling back to a severity midpoint when no vector exists at all:
The project-adjusted [CVSS 4.0 environmental score](/latest/plateform-overview/key-features/cvss-4-scoring) is preferred.
Used when no environmental score is available.
For findings with no CVSS at all (typically SAST, IaC and Secrets), the midpoint of the severity band is used: **Critical = 17.5**, **High = 7.5**, **Medium = 3**, **Low = 1**.
***
## What counts toward the score
Only **active** vulnerabilities on the project's **reference branch** are included:
* `to_verify`
* `proposed_not_exploitable`
* `confirmed`
Resolved, ignored and confirmed-not-exploitable findings are excluded, so the score always reflects the *current* open risk.
When a project has no reference branch configured, the score falls back to the `main` (then `master`) branch. An explicit "all branches" selection is treated the same way, so the score stays branch-scoped and comparable.
***
## Risk levels
The numeric score maps to a categorical level used for filtering, dashboards and portfolio views:
| CybeRisk Score | Level |
| -------------- | ------------ |
| ≥ 80 | **Critical** |
| ≥ 50 | **High** |
| ≥ 20 | **Medium** |
| \< 20 | **Low** |
**`low` is the floor.** Even a project with a score of 0 or no vulnerabilities reads as *Low*, there is no `none` level. This keeps every project on the same comparable scale.
***
## Where it appears
* **Project overview**: the headline risk indicator with its breakdown and top contributors.
* **Organization overview**: projects are ranked and filterable by CybeRisk level (`critical`, `high`, `medium`, `low`) to surface the riskiest projects in a portfolio.
* **Project listings**: each project carries both `cyberRiskScore` (for sorting) and `cyberRiskLevel` (for grouping/filtering).
The CybeRisk Score replaces the legacy bounded `riskScore` / `riskLevel` (0–100) project metric. The thresholds for the levels are unchanged, but the score itself is now an unbounded sum so it scales with the true backlog of risk.
***
## CybeRisk Score vs Priority Score
These two scores work at different altitudes and complement each other:
| | **Priority Score** | **CybeRisk Score** |
| ------------ | ------------------------------------------ | ---------------------------------------------- |
| **Scope** | One vulnerability | One project (reference branch) |
| **Question** | What do I fix first *here*? | Which project is *riskiest*? |
| **Scale** | 0–100 (normalized) | Unbounded sum of points |
| **Signals** | CVSS 4.0 · EPSS · Exploitability · Context | CVSS-weighted point sum across active findings |
| **Use** | In-project triage, Top Vulnerabilities | Portfolio prioritization, executive reporting |
***
**Related:** [Priority Scoring](/latest/plateform-overview/key-features/priority-scoring) · [CVSS 4.0 Scoring](/latest/plateform-overview/key-features/cvss-4-scoring) · [Top Vulnerabilities](/latest/managing-vulnerabilities/top-vulnerabilities) · [Exploitable Path](/latest/plateform-overview/key-features/exploitable-path)
# Exploitable Path
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/exploitable-path
Identify whether vulnerable dependencies are actually used in your code with SCA reachability analysis
## Overview
The **Exploitable Path** feature (also known as **Reachability Analysis**) determines whether vulnerable SCA dependencies are actually imported and used in your codebase. Instead of treating every dependency vulnerability equally, CybeDefend pinpoints the ones that matter — the packages your code actually calls — so you can focus remediation where it counts.
Automatically identifies whether each dependency is used, unused, or potentially used in your code
Boosts priority for used packages and lowers it for unused ones, so critical risks surface first
Optionally auto-ignores vulnerabilities in dependencies your code never imports
Shows exactly where in your code each dependency is imported, with file paths and line numbers
***
## How It Works
During an SCA scan, CybeDefend analyzes your source code to detect import statements and matches them against detected dependencies. Each package receives a **reachability status**:
| Status | Meaning | Impact |
| -------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------- |
| **Used** | The package is directly imported in your code | Priority is **promoted** one level (e.g., normal → urgent) |
| **Unused** | No import of this package was found in your code | Priority is set to **very low**; optionally auto-ignored |
| **Potentially Used** | The package may be used indirectly (e.g., via a framework plugin) | No automatic priority change |
For **transitive dependencies** (indirect dependencies pulled in by your direct dependencies), CybeDefend traces the dependency chain and propagates import locations from ancestor packages when available.
***
## Import Location Tracking
When a package is marked as **Used**, CybeDefend records the exact locations where it is imported in your code. For each import, you can see:
* **File path** — the relative path to the source file (e.g., `src/utils/helpers.ts`)
* **Line number** — the exact line where the import occurs
* **Code snippet** — the actual import statement content
This allows developers to quickly navigate to the relevant code and assess the actual exposure to the vulnerability.
***
## Priority Adjustment
When reachability priority adjustment is enabled, CybeDefend automatically modifies vulnerability priorities based on package usage:
| Original Priority | Used Package | Unused Package |
| ----------------- | --------------- | -------------- |
| Very Low | Low | Very Low |
| Low | Normal | Very Low |
| Normal | Urgent | Very Low |
| Urgent | Critical Urgent | Very Low |
| Critical Urgent | Critical Urgent | Very Low |
This means a **Normal** severity vulnerability in a package your code actually imports gets promoted to **Urgent**, while the same vulnerability in an unused dependency drops to **Very Low** — dramatically reducing noise in your vulnerability backlog.
***
## Configuration
Exploitable Path analysis is controlled by two per-project settings, both **enabled by default**:
### Reachability Priority Adjustment
When enabled, vulnerability priorities are automatically adjusted based on whether the affected package is used or unused in your code (see the priority table above).
### Reachability Auto-Ignore
When enabled, vulnerabilities associated with **unused** packages are automatically set to **Ignored** status. This significantly reduces noise by hiding vulnerabilities that cannot be exploited since the dependency is never called.
Open your project and go to the **Settings** section.
Locate the **Reachability Priority Adjustment** and **Reachability Auto-Ignore** toggles.
Enable or disable each setting independently based on your team's workflow.
Disabling reachability auto-ignore will stop automatically ignoring vulnerabilities in unused packages for **future scans**. Previously ignored vulnerabilities will not be automatically restored.
***
## Supported Ecosystems
Exploitable path analysis is available for all package ecosystems supported by CybeDefend's SCA scanner, including:
* **npm** (JavaScript/TypeScript)
* **pip / Poetry** (Python)
* **Maven / Gradle** (Java, Kotlin, Scala)
* **Go modules**
* **NuGet** (.NET)
* **Composer** (PHP)
* **Cargo** (Rust)
* **CocoaPods / Swift PM** (iOS)
* **Pub** (Dart/Flutter)
* **Hex** (Elixir/Erlang)
* **Clojars** (Clojure)
* **Conan** (C/C++)
The accuracy of reachability detection varies by ecosystem. Ecosystems with explicit import statements (e.g., JavaScript `import`, Python `import`) provide the most precise results.
***
## Best Practices
The default configuration (priority adjustment + auto-ignore) provides the best signal-to-noise ratio. Only disable these settings if your compliance requirements mandate reviewing all dependency vulnerabilities regardless of usage.
Packages marked as **Potentially Used** may still represent real risk. Review these manually, especially for critical and high severity vulnerabilities.
Use the [Policy Management](/latest/plateform-overview/key-features/policy-management) feature to create rules that account for reachability. For example, block builds only when a **used** package has a critical vulnerability.
When triaging a vulnerability, review the import locations to understand how the package is used. A package imported only in test files may carry less risk than one used in production code paths.
***
**Related:** [License Compliance](/latest/plateform-overview/key-features/license-compliance) · [Managing Vulnerabilities](/latest/managing-vulnerabilities/project-vulnerability-list) · [Policy Management](/latest/plateform-overview/key-features/policy-management)
# License Compliance
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/license-compliance
Identify, categorize, and manage open-source license risks across your SCA dependencies
## Overview
The **License Compliance** feature gives you full visibility into the open-source licenses used by your project dependencies. CybeDefend automatically detects licenses during SCA scans, categorizes them by risk level, and lets you customize classifications at the organization level.
Licenses are extracted from package metadata during every SCA scan
Each license is classified as Permissive, Weak Copyleft, Strong Copyleft, or Unknown
Full support for complex SPDX expressions with OR, AND, and WITH operators
Customize license risk categories to match your organization's legal requirements
***
## License Categories
CybeDefend classifies every detected license into one of four categories, each with an associated risk level:
| Category | Risk | Description |
| ------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Permissive** | None | Minimal restrictions on use, modification, and redistribution. Examples: MIT, Apache-2.0, BSD-2-Clause, ISC |
| **Weak Copyleft** | Medium | Requires derivative works of the library itself to remain open-source, but allows proprietary linking. Examples: LGPL-2.1, MPL-2.0, EPL-2.0 |
| **Strong Copyleft** | High | Requires any software that links to or includes the library to be released under the same license. Examples: GPL-3.0, AGPL-3.0, SSPL-1.0 |
| **Unknown** | Unknown | License could not be identified or is not in the known SPDX database |
CybeDefend ships with a built-in classification for **100+ SPDX licenses**. You can override any of these at the organization level to match your specific compliance requirements.
***
## SPDX Expression Support
Many packages declare their license using complex SPDX expressions. CybeDefend parses these expressions and evaluates the effective risk:
### Operators
| Operator | Meaning | Risk Evaluation |
| -------- | ------------------------------ | ----------------------------------------------------- |
| `OR` | User may choose either license | Picks the **least restrictive** option |
| `AND` | Both licenses apply | Picks the **most restrictive** option |
| `WITH` | License with exception | Evaluates the base license with the exception applied |
### Examples
```
MIT OR GPL-3.0-only
→ Effective risk: None (MIT is the least restrictive choice)
MIT AND GPL-3.0-only
→ Effective risk: High (GPL-3.0 is the most restrictive, both apply)
GPL-2.0-only WITH Classpath-exception-2.0
→ Evaluated as GPL-2.0 with the Classpath exception
```
When a package uses an `OR` expression, CybeDefend assumes you will choose the most permissive option, resulting in a lower effective risk.
***
## License Summary Dashboard
The license summary provides aggregated statistics for all SCA packages in a project:
* **Total packages** scanned and how many have detected licenses
* **Breakdown by category**: count of Permissive, Weak Copyleft, Strong Copyleft, and Unknown packages
* **Ignored packages**: packages you have explicitly excluded from license analysis
* **Per-license detail**: each individual SPDX license with its category, risk level, and package count
You can filter results by **branch** and **package type** (npm, pip, maven, etc.) to focus on specific ecosystems.
***
## Managing Licenses
### Viewing Packages by License
Click on any license in the summary to see all packages using that license. For each package, you can see:
* Package name and version
* Ecosystem (npm, pip, maven, go, etc.)
* Whether it is a transitive or direct dependency
* Whether it is a dev dependency
* Current ignore status
### Assigning a License Manually
When a package has no detected license (categorized as **Unknown**), you can manually assign an SPDX license ID:
Go to the license summary and click on the **Unknown** category to see unidentified packages.
Find the package you want to update.
Use the license assignment dropdown to select the correct SPDX identifier (e.g., `MIT`, `Apache-2.0`).
### Ignoring a Package
If a package is irrelevant to your license compliance analysis (e.g., internal tooling, test-only dependencies), you can toggle the **ignore** flag. Ignored packages are excluded from the license summary counts but remain visible in the detail view.
***
## Organization-Level Configuration
### Customizing License Classifications
Each organization can override the default risk classification for any SPDX license:
Navigate to **Settings → Licenses** in your organization.
Use the search bar and category filters to find the license you want to modify.
Select a new category (Permissive, Weak Copyleft, Strong Copyleft, or Unknown) for the license.
Your overrides are saved and applied immediately to all projects in the organization.
Changing a license classification affects **all projects** in the organization. Coordinate with your legal and security teams before modifying classifications.
### Adding Custom Licenses
If your project uses a license that is not in CybeDefend's built-in database, you can add it as a custom entry with your chosen classification.
### Resetting Overrides
You can reset all organization overrides to return to CybeDefend's default classifications. This action removes all custom classifications and cannot be undone.
***
## Supported Ecosystems
License detection is available for the following package ecosystems:
* **npm / Yarn / pnpm / Bun / Deno** (JavaScript/TypeScript)
* **pip / Poetry / Pipenv** (Python)
* **Maven / Gradle** (Java, Kotlin, Scala)
* **Go modules**
* **NuGet** (.NET)
* **Composer** (PHP)
* **Cargo** (Rust)
* **CocoaPods / Swift PM** (iOS)
* **Pub** (Dart/Flutter)
* **Hex** (Elixir/Erlang)
* **RubyGems** (Ruby)
* **Conan** (C/C++)
* **Clojars** (Clojure)
* **GitHub Actions**
***
## Best Practices
Packages with unknown licenses represent the highest uncertainty. Prioritize identifying and manually assigning licenses to these packages.
Work with your legal team to determine which license categories are acceptable for your use case. Override CybeDefend's defaults if your organization has stricter or more lenient requirements.
Different ecosystems may have different license norms. Use the package type filter to analyze npm, pip, maven, and other ecosystems independently.
Mark internal or first-party packages as ignored to keep your license summary focused on third-party dependencies.
Use the [Policy Management](/latest/plateform-overview/key-features/policy-management) feature to create automated rules that block builds containing packages with unacceptable licenses.
***
**Related:** [API Reference - SCA Licenses](/latest/api-reference/introduction) · [Managing Vulnerabilities](/latest/managing-vulnerabilities/project-vulnerability-list) · [Policy Management](/latest/plateform-overview/key-features/policy-management)
# Cybe MCP Server
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/mcp-server-integration
The flagship CybeDefend feature. Connect your AI coding agent (Claude Code, Cursor, Copilot, Windsurf and others) to your CybeDefend tenant in one click. 18 typed tools over the Model Context Protocol, OAuth-discovered, browser-only sign-in. No API key, no local proxy.
**Cybe MCP is the flagship feature of CybeDefend.** A single MCP server that any modern AI coding assistant can connect to in one click and use as its security backend: fetching findings, driving the status lifecycle, and pulling project-specific business-logic context before generating code.
***
## What Cybe MCP gives your agent
| Surface | What the agent can do |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Read every finding** | List + drill into SAST, SCA, IaC, CI/CD, Secrets and Container findings, with file paths, line numbers, snippets, package trees and remediation hints. |
| **Drive the lifecycle** | Move a finding through one of four statuses (`to_verify`, `confirmed`, `resolved`, `ignored`). Set priority, attach a comment. Each action lands in the audit trail. |
| **Find similar issues** | One call returns the cluster of look-alike findings, so the agent can act on a class of false-positives or fix a pattern in one batch. |
| **Pull business-logic context** | Before writing a payment endpoint, an auth flow or an export job, the agent calls `get_business_logic_context` and Security Champion returns the tenant-specific rules mined from your repo. The agent inlines them into its system prompt and writes secure code from the first line. |
**18 typed tools, all wired to your CybeDefend Gateway**, all gated by your existing Permify scopes. A user's per-project permissions are authoritative; the MCP enforces nothing of its own.
***
## Why it matters
Most AI-in-AppSec tooling on the market today is a bolt-on: a panel that surfaces findings inside a single IDE. CybeDefend's MCP server flips the model. Instead of pushing data into one IDE, we publish a typed protocol that every modern AI coding assistant already speaks (Claude Code, Cursor, VS Code Copilot Chat, Windsurf, Continue, Cline, Zed, Claude Desktop). The agent the developer chose stays in charge; CybeDefend becomes its security backend.
That single decision unlocks the rest of the platform:
* **Inline fixes.** The agent applies the remediation in the same loop where it's writing code. No copy-paste, no second tool window.
* **Triage from chat.** Tell the agent "mark every SQLi in `/api/users` as resolved, with a comment pointing to the parameterised query helper". One prompt, two tool calls (`get_similar_vulnerabilities` + `update_vulnerability`), audit trail intact.
* **Secure-by-default generation.** Business-logic context flows from your codebase to the agent before it generates the next line. The agent doesn't have to guess your tenant scope, refund cap, idempotency convention or audit pattern.
***
## Getting connected
CybeDefend ships **two regional MCP endpoints**, isolated per region:
`https://mcp-eu.cybedefend.com/mcp`
Backed by the EU CybeDefend region (Scaleway, Paris). GDPR / NIS2 / DORA-aligned.
`https://mcp-us.cybedefend.com/mcp`
Backed by the US CybeDefend region (Google Cloud). Controls aligned with SOC 2, Type II audit in progress.
You point your AI assistant at the URL of the region your CybeDefend tenant lives in, and the assistant handles the rest. Authentication is **OAuth 2.1 with Dynamic Client Registration** (RFC 7591). The MCP client opens a browser tab, you sign in to CybeDefend the same way you sign in to the dashboard, the assistant receives a Bearer JWT, and you're connected. **No API key to manage. No PAT to rotate. No local proxy to run.**
Register the MCP plus the hook layer for Claude Code, Cursor, Codex, Windsurf and Copilot in a single `npx` install.
Add the MCP URL to any client by hand — the full how-to in **Agent & AI Integration → Cybe MCP**.
***
## What the agent loop looks like
A single user prompt ("Add an endpoint to update user profile") produces this exchange under the hood, end-to-end through Cybe MCP:
```text theme={null}
$ user: "Add an endpoint to update user profile"
↳ claude.thinking…
↳ cybe.mcp · context.fetch · 156 files indexed
↳ cybe.mcp · graph.walk · auth.mw → users.repo
↳ cybe.mcp · rules.inject · tenant-scope, zod, audit, pii
↳ claude · PATCH /users/:id (src/api/users.ts:42)
↳ claude · requireOwner middleware enforced
↳ claude · zod schema applied (input + output)
↳ claude · audit.log(actor, "users.update")
↳ cybe.mcp · scan.run · checking diff
↳ cybe.mcp · SQLi caught at users.ts:48
↳ cybe.mcp · fix.apply · parameterised query
↳ cybe.mcp · scan.rerun · diff is clean
✓ 0 vulns · 0 violations · 4 rules met · ship · no human review needed
```
The MCP layer is everything between the user prompt and the green check.
***
## Privacy, isolation and audit trail
* **Region pinning.** EU MCP traffic stays on EU infrastructure (Scaleway, Paris). US MCP traffic stays on Google Cloud (US). The two regions are independent CybeDefend tenants. They do not share storage, identity or audit trail.
* **No data crosses to a third-party LLM.** CybeDefend operates its own AI inference layer using open-weight Mistral models self-hosted on Scaleway. We do **not** call Anthropic, OpenAI or Google AI APIs. When *you* connect Claude Code or Cursor to our MCP, that agent runs on the agent vendor's infrastructure under your contract with that vendor; CybeDefend's role is only to answer the agent's tool calls.
* **No code is stored at the MCP layer.** mcp-service is a thin transport in front of the CybeDefend Gateway. Every tool call is a REST request, the Gateway answers under your existing Permify scope, the response streams back to the agent. Nothing persists at rest in the MCP server.
* **Every action is auditable.** Read-only tool calls (`list_…`, `get_…`) and write tool calls (`update_vulnerability`) are logged to your CybeDefend audit trail with the user identity that signed the OAuth handshake and the timestamp of the call.
***
## Where it slots in the platform
Concrete setup snippets for Claude Code, Claude Desktop, Cursor, VS Code Copilot Chat, Windsurf, Continue, Zed and any other MCP client.
The same toolset, surfaced inside the CybeDefend dashboard with cross-project posture and human-in-the-loop write actions.
The agent behind `get_business_logic_context`. Crawls your repo, builds the knowledge graph, returns project-specific rules.
The reachability + business-context engine that explains *why* a finding is exploitable. Same data the MCP serves to the agent.
EU + US isolated regions, the same model that backs the two regional MCP endpoints.
# Policy Management
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/policy-management
Define security policies as code and enforce compliance across your organization
## Overview
The **Policy Management** feature provides a **Policy as Code** approach to security governance. Define your security requirements in YAML or JSON, and CybeDefend will automatically evaluate every scan against your policies.
Organization → Team → Project hierarchy ensures policies cascade appropriately
Version-controlled YAML/JSON policies that integrate with your GitOps workflow
Non-blocking BullMQ-based worker for fast policy evaluation
Full audit trail and compliance history for governance reporting
***
## Key Features
### Policy Hierarchy
Policies are applied in a hierarchical manner, ensuring organizational standards cannot be bypassed:
```
Organization Policy (highest priority)
↓
Team Policy
↓
Project Policy (lowest priority)
```
A policy at a higher level **cannot be disabled** by a policy at a lower level. Lower-level policies can only **add stricter rules**.
### Automatic Vulnerability Filtering
During policy evaluation, certain vulnerabilities are automatically ignored to focus on active security risks:
| Status | Description |
| --------------------------- | ---------------------------------------------------------- |
| `resolved` / `fixed` | Already fixed in the source code |
| `ignored` / `accepted_risk` | Risks that have been formally accepted by the organization |
***
## Policy Configuration
Policies are defined in YAML format with complete metadata. Here's a full example:
```yaml theme={null}
version: '1.0'
name: 'Production Security Policy'
description: 'Strict security policy for production deployments'
scope: PROJECT # ORGANIZATION | TEAM | PROJECT
priority: 10 # 1-100 (lower = higher priority)
enabled: true
# For PROJECT scope - specify target projects
projectIds:
- 550e8400-e29b-41d4-a716-446655440001
rules:
- name: 'Block critical vulnerabilities'
type: severity
operator: eq
value: CRITICAL
action: block
- name: 'Warn on high vulnerabilities'
type: severity
operator: eq
value: HIGH
action: warn
- name: 'Block high CVSS scores'
type: cvss_score
operator: gt
value: 9.0
action: block
# Optional exclusions (max 30)
exclusions:
- pattern: 'test/**'
reason: 'Test files are not deployed to production'
- pattern: '**/vendor/**'
reason: 'Third-party code - tracked separately'
expirationDate: '2026-06-30T00:00:00Z'
```
Policies require **1-15 rules** and support a **maximum of 30 exclusions**.
***
## Rule Types
| Type | Description | Valid Values |
| ------------------------ | ------------------------------- | --------------------------------------------------- |
| `severity` | Vulnerability severity level | `critical`, `high`, `medium`, `low`, `info` |
| `cvss_score` | CVSS score (0-10) | Numeric value (e.g., `7.5`, `9.0`) |
| `cwe_check` | CWE identifier | String (e.g., `CWE-89`, `CWE-79`) |
| `owasp_category` | OWASP Top 10 category | String (e.g., `A01:2021`, `A03:2021`) |
| `scanner_type` | Type of scanner | `sast`, `secret`, `sca`, `container`, `iac`, `cicd` |
| `vulnerability_age_days` | Days since detection | Numeric value |
| `is_new_vulnerability` | Whether vulnerability is new | Boolean (`true`/`false`) |
| `branch` | Git branch name (supports glob) | String (e.g., `main`, `feature/*`) |
| `composite_and` | Combine rules with AND logic | Array of sub-rules |
| `composite_or` | Combine rules with OR logic | Array of sub-rules |
***
## Operators
| Operator | Description | Example |
| -------- | --------------------- | --------------------------------- |
| `eq` | Equals (exact match) | `severity eq critical` |
| `neq` | Not equals | `severity neq info` |
| `gt` | Greater than | `cvss_score gt 7.0` |
| `lt` | Less than | `vulnerability_age_days lt 30` |
| `gte` | Greater than or equal | `cvss_score gte 9.0` |
| `lte` | Less than or equal | `vulnerability_age_days lte 7` |
| `in` | In list | `severity in [critical, high]` |
| `not_in` | Not in list | `cwe_check not_in [CWE-1, CWE-2]` |
***
## Actions
| Action | Description | CI/CD Exit Code |
| ------- | --------------------------------------------- | --------------- |
| `block` | Blocks the pipeline, creates violation record | `1` |
| `warn` | Creates violation record, doesn't block | `0` |
***
## Composite Rules
Use composite rules to combine multiple conditions:
### AND Logic (All conditions must match)
```yaml theme={null}
- name: 'Block Critical on Main Branch'
type: composite_and
action: block
criteria:
- type: severity
operator: eq
value: CRITICAL
- type: branch
operator: eq
value: main
```
### OR Logic (Any condition can match)
```yaml theme={null}
- name: 'Block dangerous patterns'
type: composite_or
action: block
criteria:
- type: cvss_score
operator: gt
value: 9.0
- type: cwe_check
operator: in
value: ['CWE-89', 'CWE-78', 'CWE-94']
```
***
## Exclusions
Exclusions allow you to skip policy evaluation for specific files or patterns:
```yaml theme={null}
exclusions:
- pattern: 'test/**'
reason: 'Test files are not deployed' # Required
- pattern: '**/node_modules/**'
reason: 'Dependencies tracked via SCA'
expirationDate: '2026-12-31T00:00:00Z' # Optional expiration
```
**Pattern matching uses glob patterns:**
* `**` matches any number of directories
* `*` matches any characters except `/`
* `?` matches a single character
Always set expiration dates on exclusions to prevent permanent security gaps.
***
## Policy Examples
### Branch-Based Policy (Production Protection)
```yaml theme={null}
version: '1.0'
name: 'Production Branch Policy'
description: 'Strict policy for production branches'
scope: PROJECT
priority: 5
enabled: true
projectIds:
- 550e8400-e29b-41d4-a716-446655440001
rules:
# Block ALL high/critical on main and release branches
- name: 'Block critical on production branches'
type: composite_and
action: block
criteria:
- type: branch
operator: in
value: ['main', 'master', 'release-*', 'release/*']
- type: severity
operator: in
value: [CRITICAL, HIGH]
# Only warn on feature branches
- name: 'Warn on feature branches'
type: composite_and
action: warn
criteria:
- type: branch
operator: in
value: ['feature/*', 'feat/*', 'develop']
- type: severity
operator: eq
value: CRITICAL
# Block secrets on any branch
- name: 'Always block exposed secrets'
type: composite_and
action: block
criteria:
- type: scanner_type
operator: eq
value: SECRET
- type: severity
operator: in
value: [CRITICAL, HIGH]
```
### Multi-Scanner Organization Policy
```yaml theme={null}
version: '1.0'
name: 'Organization Security Policy'
description: 'Enterprise-wide policy for all scanners'
scope: ORGANIZATION
priority: 1
enabled: true
rules:
# SAST Rules
- name: 'SAST - Block critical vulnerabilities'
type: composite_and
action: block
criteria:
- type: scanner_type
operator: eq
value: sast
- type: severity
operator: eq
value: CRITICAL
# Secret Detection
- name: 'Secrets - Block exposed secrets'
type: composite_and
action: block
criteria:
- type: scanner_type
operator: eq
value: secret
- type: severity
operator: in
value: ['CRITICAL', 'HIGH']
# Container Scanning
- name: 'Container - Block high CVSS'
type: composite_and
action: block
criteria:
- type: scanner_type
operator: eq
value: container
- type: cvss_score
operator: gt
value: 8.0
# OWASP Categories
- name: 'OWASP A01 - Broken Access Control'
type: owasp_category
operator: eq
value: 'A01:2021'
action: block
exclusions:
- pattern: 'test/**'
reason: 'Test files'
- pattern: 'docs/**'
reason: 'Documentation'
```
***
## CI/CD Integration
### GitHub Actions
Use the official CybeDefend GitHub Action with policy evaluation enabled:
```yaml theme={null}
name: CybeDefend Security Scan with Policy Enforcement
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Run CybeDefend Security Scan
uses: CybeDefend/cybedefend-action@v1
with:
token: ${{ secrets.CYBEDEFEND_PAT }}
project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
branch: ${{ github.head_ref || github.ref_name }}
# Policy evaluation options
policy_check: true
policy_timeout: 300
show_policy_vulns: true
show_all_policy_vulns: false
```
#### Policy Evaluation Options
| Option | Default | Description |
| ----------------------- | ------- | ------------------------------------------- |
| `policy_check` | `true` | Enable/disable policy evaluation after scan |
| `policy_timeout` | `300` | Timeout in seconds for policy evaluation |
| `show_policy_vulns` | `true` | Show affected vulnerabilities in output |
| `show_all_policy_vulns` | `false` | Show all vulnerabilities (no limit) |
### GitLab CI
Use the CybeDefend CLI directly with policy evaluation:
```yaml theme={null}
stages:
- security
cybedefend-scan:
stage: security
image: ghcr.io/cybedefend/cybedefend-cli:v1.0.9
variables:
CYBEDEFEND_PAT: $CYBEDEFEND_PAT
CYBEDEFEND_PROJECT_ID: $CYBEDEFEND_PROJECT_ID
script:
# Run scan with policy evaluation (enabled by default)
- cybedefend scan --dir . --branch $CI_COMMIT_REF_NAME --ci
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == "main"
```
#### CLI Policy Flags
| Flag | Default | Description |
| ------------------------- | ------- | -------------------------------------- |
| `--policy-check` | `true` | Enable/disable policy evaluation |
| `--policy-timeout` | `300` | Timeout in seconds for evaluation |
| `--show-policy-vulns` | `true` | Show affected vulnerabilities |
| `--show-all-policy-vulns` | `false` | Show all vulnerabilities without limit |
#### Example Output
```
✓ Scan completed successfully
ℹ Checking policy evaluation status...
✓ Policy evaluation completed
ℹ Policy violations found: 2 BLOCK, 1 WARN
⛔ BLOCK Actions:
✗ No Critical Vulnerabilities (BLOCK)
Affected: 3 vulnerabilities
→ [CRITICAL] SQL Injection - src/api/users.ts (L45-48)
https://us.cybedefend.com/project/xxx/sast/issue/yyy
→ [CRITICAL] Path Traversal - src/utils/file.ts (L12)
https://us.cybedefend.com/project/xxx/sast/issue/zzz
⚠️ WARN Actions:
⚠ Dependency Check (WARN)
Affected: 1 vulnerability
→ [HIGH] Prototype Pollution - lodash@4.17.15
https://us.cybedefend.com/project/xxx/sca/issue/aaa
✓ Acknowledged Violations (not blocking):
⚠ No High Vulnerabilities (BLOCK)
✓ Acknowledged: Risk accepted for legacy code
```
If any policy has a **BLOCK** action with violations, the CLI exits with code `1`, failing the pipeline. **WARN** actions are informational only and don't affect the exit code.
***
## Managing Violations
When a policy violation occurs, you have two options to resolve it:
Change the vulnerability status from "open" to "ignored" with a justification. The vulnerability will be excluded from future policy evaluations.
Resolve the security issue directly in your source code and re-run the scan. The vulnerability will be marked as "resolved" and excluded from policy evaluations.
Both approaches create an audit trail. Changing status to "ignored" requires a comment explaining the risk acceptance decision.
***
## Best Practices
When rolling out policies, start with `action: warn` to understand the impact before switching to `action: block`.
Always set expiration dates on exclusions to prevent permanent security gaps:
```yaml theme={null}
exclusions:
- pattern: 'src/legacy/**'
reason: 'Technical debt - scheduled for Q2 refactor'
expirationDate: '2026-06-30T00:00:00Z'
```
* **Organization level**: Global security requirements (e.g., no exposed secrets)
* **Team level**: Team-specific standards (e.g., frontend vs backend rules)
* **Project level**: Project-specific exclusions only
Store policy YAML files in your repository:
```
repo/
├── .cybedefend/
│ ├── policies/
│ │ ├── sast-policy.yaml
│ │ ├── sca-policy.yaml
│ │ └── secret-policy.yaml
│ └── README.md
```
***
**Related:** [API Reference - Policy Management](/latest/api-reference/introduction) · [Managing Vulnerabilities](/latest/managing-vulnerabilities/project-vulnerability-list) · [CI/CD Integrations](/latest/code-scanning/ci-cd-integrations/github-action-setup)
# Priority Scoring
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/priority-scoring
Composite priority that blends CVSS 4.0, EPSS, exploitability and business context into a single 0–100 score
## Overview
Severity alone does not tell you what to fix first. CybeDefend computes a **Priority Score** for every detection — a weighted blend of four orthogonal signals — and exposes both the final score and the **per-signal contributions** so triage decisions are fully transparent.
CVSS 4.0 environmental score · EPSS percentile · Exploitability · Business context
A single user-facing number (`priorityScore`) sortable across all scanners
Mapped into Critical Urgent · Urgent · Normal · Low · Very Low buckets
Each detection exposes the exact contribution of every signal
***
## The formula
The internal composite score is a weighted sum of four normalized signals, each in `[0, 1]`:
```
compositeScore = w1·CVSS4_norm + w2·EPSS_percentile + w3·Exploitability + w4·Context
```
The user-facing **`priorityScore`** is `compositeScore × 100` (rounded to one decimal, bounded to `[0, 100]`).
### Default weights
| Weight | Signal | Default |
| ------ | ---------------------------------------------------- | -------- |
| `w1` | CVSS 4.0 (environmental score / 10) | **0.35** |
| `w2` | EPSS percentile (probability of exploit in the wild) | **0.25** |
| `w3` | Exploitability (verdict-driven) | **0.25** |
| `w4` | Context (business criticality + data classification) | **0.15** |
Weights are configured at the platform level (`PRIORITY_WEIGHT_*` env vars) and must always sum to `1.0`. When EPSS is unknown for a detection, `w2` is dropped and `w1 / w3 / w4` are renormalized so the score remains comparable.
***
## Signals in detail
### 1. CVSS 4.0 (environmental)
The CVSS 4.0 **environmental** score is preferred; the base score is used as a fallback, and finally a severity-default if no vector is available. The score is divided by 10 to land in `[0, 1]`. See [CVSS 4.0 Scoring](/latest/plateform-overview/key-features/cvss-4-scoring) for how that score is built.
### 2. EPSS percentile
EPSS (Exploit Prediction Scoring System) percentile estimates the probability that a vulnerability will be exploited in the next 30 days, relative to all other CVEs. CybeDefend ingests EPSS for SCA and Container findings where a CVE identifier is available.
### 3. Exploitability
A qualitative verdict mapped to a numeric score:
| Verdict | Score | Meaning |
| -------------------- | ----- | --------------------------------------------------- |
| `not_exploitable` | 0.05 | Demonstrated false positive / unreachable code path |
| `theoretical` | 0.35 | Default before deeper analysis |
| `proven` | 0.75 | Confirmed exploitable in this codebase |
| `actively_exploited` | 0.95 | Known to be exploited in the wild |
For SCA detections, when **Exploitable Path** marks a dependency as **unused**, the exploitability contribution is forced to `0` — even before the verdict pipeline runs.
The verdict can come from three sources, persisted in `exploitabilitySource`:
* **`static`** — heuristics on file path (test / vendor / example code is demoted) and reachability.
* **`agent`** — Cybe Analysis LLM verdict with rationale.
* **`manual`** — overridden by a user.
### 4. Context
The Context signal averages two project-level inputs:
| Business Criticality | Modifier | Data Classification | Modifier |
| -------------------- | ------------- | ------------------- | ------------- |
| Mission Critical | 1.0 | Regulated | 1.0 |
| High | 0.7 | Confidential | 0.7 |
| Medium | 0.4 | Internal | 0.4 |
| Low | 0.2 | Public | 0.2 |
| Unspecified | 0.5 (neutral) | Unspecified | 0.5 (neutral) |
`Context = (BusinessCriticality + DataClassification) / 2`
***
## Priority levels
The composite score is mapped to a discrete priority level used by filters, dashboards, and policy rules:
| Composite Score | Priority |
| --------------- | ------------------- |
| ≥ 0.80 | **Critical Urgent** |
| ≥ 0.60 | **Urgent** |
| ≥ 0.40 | **Normal** |
| ≥ 0.20 | **Low** |
| \< 0.20 | **Very Low** |
Thresholds are configurable platform-wide (`PRIORITY_THRESHOLD_*` env vars).
***
## Manual override
A user with the right permission can pin a priority manually on a detection. When set:
* The composite score is **no longer recalculated** automatically.
* The detection is flagged with `priorityManualOverride: true` and `isManualOverride: true` in the decomposition response.
* Subsequent scans, Security Context changes, or EPSS refreshes will not touch the priority until the override is cleared.
***
## Inspect the calculation
Every detection exposes a **priority decomposition** endpoint that returns the exact composition of its score:
```http theme={null}
GET /project/{projectId}/results/{type}/{vulnerabilityId}/priority-decomposition
```
Response (abbreviated):
```json theme={null}
{
"decomposition": {
"priority": "urgent",
"compositeScore": 0.674,
"cvss4Contribution": 0.287,
"epssContribution": 0.142,
"exploitContribution": 0.188,
"contextContribution": 0.057,
"w1": 0.35,
"w2": 0.25,
"w3": 0.25,
"w4": 0.15,
"isManualOverride": false
}
}
```
Use the decomposition to explain to a developer **why** a vulnerability landed at a given priority — particularly useful when the Security Context or exploitability verdict moves a finding up or down.
***
## How it impacts your workflow
* **Sorting** — the Vulnerability List can be sorted by Priority Score across all scanners.
* **Filtering** — filter by priority level (Critical Urgent, Urgent, Normal, Low, Very Low).
* **Top Vulnerabilities widget** — see the [Top Vulnerabilities](/latest/managing-vulnerabilities/top-vulnerabilities) page.
* **Policies** — Policy Management can gate merges/deploys on priority-level rules.
* **Reports** — emailed reports group findings by priority instead of raw severity.
***
**Related:** [CVSS 4.0 Scoring](/latest/plateform-overview/key-features/cvss-4-scoring) · [Exploitable Path](/latest/plateform-overview/key-features/exploitable-path) · [Policy Management](/latest/plateform-overview/key-features/policy-management) · [Top Vulnerabilities](/latest/managing-vulnerabilities/top-vulnerabilities)
# Advanced Access Control with ReBAC
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/rebac-management
Learn how CybeDefend leverages Role-Based and Relationship-Based Access Control to provide granular security within your organization.
CybeDefend uses a **dual approach** to access control:
1. **RBAC** (Role-Based Access Control) assigns predefined roles, such as Admin or Viewer, to users within specific teams or projects.
2. **ReBAC** (Relationship-Based Access Control) extends this model by considering relationships—like membership in multiple organizations or teams, each with unique roles.
![RBAC & ReBAC Management]()
ReBAC goes beyond basic role checks by examining the user’s relationship with an entity, allowing more flexible and fine-grained access rules.
***
## What is ReBAC?
**Relationship-Based Access Control (ReBAC)** defines permissions based on the **relationship** between a user and an entity (e.g., “Alice is an Admin in Team1,” or “Bob is a Viewer in OrgA”). This approach is ideal for complex organizations that require nuanced distinctions between user roles and multiple groups or teams.
### Key Advantages of ReBAC
* **Granular Permissions**: Distinguish between different teams, projects, or business units with dynamic relationships.
* **Scalable Model**: As new users, teams, or roles are added, ReBAC easily adapts without significant refactoring.
* **Flexible Hierarchies**: Handle nested relationships (e.g., sub-teams) without needing to define every possible role combination in advance.
***
## Open-Source ReBAC: react-rebac
CybeDefend has also developed an **open-source** library called [**react-rebac**](https://github.com/CybeDefend/react-rebac) to simplify **relationship-based access control** in **React** applications. This library:
* **Manages** user relationships with multiple entities (e.g., organizations, teams).
* **Conditionally Renders** content based on user roles or relationships.
* **Supports** single-entity mode and multi-entity mode (checking if the user has access to *any* of several entities).
***
**Related:** [Assigning Roles](/latest/get-started/account-setup/assigning-roles) · [Managing Access](/latest/get-started/account-setup/managing-access-org-teams) · [react-rebac on GitHub](https://github.com/CybeDefend/react-rebac)
# Sovereign Data Storage
Source: https://docs.cybedefend.com/latest/plateform-overview/key-features/sovereign-data-storage
Choose where your data is stored with sovereign cloud options in France and Europe for GDPR compliance, or opt for global cloud providers.
CybeDefend offers **sovereign data storage options** that allow organizations to maintain **full control** over their data location and compliance requirements. You can choose between:
* **European Cloud**: hosted on **SecNumCloud-qualified infrastructure (Scaleway)**, compliant with GDPR and European data protection law. Data is stored exclusively in Europe.
* **US Cloud**: hosted on **Google Cloud**, for organizations requiring low latency in North America. Data is stored in the United States.
SecNumCloud is a qualification awarded by the French ANSSI to a **hosting provider**, for a specific set of its services. It qualifies Scaleway, the infrastructure CybeDefend runs on in the EU region. CybeDefend's own certification status is on our [Security page](https://cybedefend.com/en/legal/security).
![Select US Cloud]()
## Storage Options
### European Cloud (SecNumCloud-qualified infrastructure)
* **Location**: Data stored exclusively in Europe
* **Compliance**: GDPR. Hosted on Scaleway infrastructure qualified SecNumCloud by ANSSI
* **Sovereignty**: Data never leaves European territory
* **Transparency**: Complete control and visibility over data location
### US Cloud
* **Location**: Data stored in the United States
* **Compliance**: Meets US regulatory standards
* **Performance**: Optimized for low latency in North America
## How It Works
1. **Organization Setup**: Choose your preferred data storage region (Europe or US) during organization creation or in your settings.
2. **Data Localization**: All scan results, vulnerability data, and project information are stored exclusively in your selected region.
3. **Compliance Assurance**: Your choice ensures compliance with GDPR (Europe) or US standards.
4. **Transparency**: Full visibility into where your data is stored and managed.
## Benefits for Organizations
* **Regulatory Compliance**: Meet GDPR and SecNumCloud requirements in Europe, or US standards in North America.
* **Data Sovereignty**: Maintain complete control over data location—your data never leaves your chosen region.
* **Transparent Governance**: Full visibility into where your data is stored and processed.
* **Flexible Choice**: Switch between regions as your business or compliance needs change.
***
**Related:** [Create Account & Select Region](/latest/get-started/account-setup/create-account-organization) · [LLM Usage & Privacy](/latest/plateform-overview/security-privacy/llm-usage-privacy)
# AI Usage & Entitlements
Source: https://docs.cybedefend.com/latest/plateform-overview/plan-&-pricing/ai-usage-tracking
Monitor your Cybe AI features usage and track available quotas.
Track your organization's consumption of Cybe AI features in real-time.
![AI Usage & Entitlements Dashboard]()
***
## How Credits Work
### Organization-Level Pooling
Credits are shared across your entire organization:
* **No per-user limits** — credits pool at organization level
* **Flexible distribution** — one developer can use more than another
* **Total matters** — only total organization consumption counts
**Example** — 2 seats × 60 credits = 120 total credits:
* Developer A: 80 credits used
* Developer B: 20 credits used
* **Total**: 100/120 credits (20 remaining)
***
## Reset & Expiration
* **Quotas reset** on your billing cycle date
* **Unused credits expire** at each reset
* **Add-ons expire** at the end of monthly billing periods
***
## Need More Credits?
Purchase add-on packs at [Manage Billing](/latest/plateform-overview/plan-&-pricing/manage-billing-subscription) when approaching quota limits.
# Pricing Model
Source: https://docs.cybedefend.com/latest/plateform-overview/plan-&-pricing/free-plan
Understand CybeDefend's flexible pricing model with organization-wide credits and on-demand add-ons.
CybeDefend offers a **flexible, usage-based pricing model** tailored to your organization's needs. Our subscriptions provide a package of **Cybe AI agent requests** and platform features, with the ability to add more credits as needed.
***
## How Our Pricing Works
### Organization-Wide Credit Pool
CybeDefend's pricing is designed around **organization-level credit allocation**, not individual users:
* **Credits are shared across your entire organization**
* **No per-user tracking** — one developer can use more credits than another without penalty
* **Flexible usage** — credits are pooled for all team members to draw from as needed
This means if one developer uses 1,000 Cybe AI requests and another uses 100, it doesn't matter—both draw from the same organizational credit pool.
### Add-On Credits
When your organization needs more Cybe AI requests:
* **Purchase additional credit packages** on-demand
* **No subscription changes required** — simply add credits as needed
* **Credits remain at the organization level** — shared by all members
Add-ons provide flexibility to scale your AI-powered analysis capabilities without upgrading your entire subscription.
***
**Related:** [Create Account](/latest/get-started/account-setup/create-account-organization) · [Manage Billing](/latest/plateform-overview/plan-&-pricing/manage-billing-subscription) · [AI Usage Tracking](/latest/plateform-overview/plan-&-pricing/ai-usage-tracking)
# Manage Billing & Subscription
Source: https://docs.cybedefend.com/latest/plateform-overview/plan-&-pricing/manage-billing-subscription
Configure your subscription, manage seats, add credits, and update billing information.
The **Billing & Subscription** page allows you to manage your CybeDefend plan, adjust the number of seats, purchase add-on credit packs, and maintain accurate billing information for invoicing.
***
## Subscription Details
Monitor and adjust your current subscription plan to match your organization's needs.
![Subscription Details]()
### Key Information
* **Plan Type**: View your current subscription plan (Trial, Pro, Enterprise, etc.)
* **Seats**: Number of active users in your organization
* **Trial Period**: If applicable, see when your trial ends
* **Billing Cycle**: View current period end and next reset date
### Monthly Usage Limits
Your subscription includes per-seat limits for Cybe AI features:
* **Cybe Security Champion** — AI-powered vulnerability prioritization (per seat)
* **Cybe AutoFix** — Automated vulnerability remediation suggestions (per seat)
* **Cybe Analysis** — Deep code analysis and insights (per seat)
* **Project Limit** — Unlimited projects across your organization
Click **Edit** to adjust the number of seats in your organization. Your subscription will be prorated automatically.
Usage limits are **per seat**, but credits are pooled at the organization level. If one developer exceeds their allocation while another uses less, the organization's total remains balanced.
***
## Billing Information
Maintain accurate billing details to ensure proper invoicing and VAT compliance.
![Billing Information]()
### General Information
* **Customer Type**: Individual or Company
* **First Name & Last Name**: Primary billing contact
* **Country**: Required for tax and VAT calculations
### Billing Address
* **Address Line 1 & 2**: Complete street address
* **City & Postal Code**: Location details
* **Region/State**: If applicable
Ensure your billing information is accurate and up-to-date. This information appears on all invoices and is used for VAT/tax calculations.
Click **Edit** in the top-right corner to update your billing information at any time.
***
## Manage Add-ons
Purchase additional credit packs to extend your Cybe AI capabilities beyond your base subscription limits.
![Manage Add-ons]()
### Available Add-on Packs
CybeDefend offers three types of credit packs:
1. **Cybe Security Champion Pack**\
Extra Cybe Security Champion conversations\
Pack size: 25 total for organization
2. **Cybe AutoFix Pack**\
Extra Cybe AutoFix operations\
Pack size: 25 total for organization
3. **Cybe Analysis Pack**\
Extra Cybe Analysis operations\
Pack size: 25 total for organization
### How to Purchase Add-ons
1. Click **Add** on the desired credit pack
2. Select the number of packs you need
3. Choose your billing cycle (Monthly or Yearly)
4. Review pricing and confirm
![Add-on Purchase Modal]()
### Add-on Pricing
Add-ons are available with flexible billing options:
* **Monthly billing**: Pay per month for ongoing credit access
* **Yearly billing**: Save with annual pre-payment (typically includes discount)
All add-on credits are pooled at the **organization level**. Any team member can use credits from any pack, regardless of who initiated the purchase.
Add-ons are prorated based on when you purchase them during your billing cycle. Unused credits from monthly packs expire at the end of each billing period.
# LLM Usage & Privacy
Source: https://docs.cybedefend.com/latest/plateform-overview/security-privacy/llm-usage-privacy
How CybeDefend uses sovereign LLMs with strict privacy guarantees.
CybeDefend leverages advanced Large Language Models (LLMs) to power our AI agents while maintaining the highest standards of data privacy and security.
***
## Our LLM Policy
### Sovereign LLM Infrastructure
All LLMs used by CybeDefend are deployed on **sovereign cloud infrastructure** within your chosen region (EU or US). Your code and vulnerability data never leave your selected geographical boundary.
### No Training or Fine-Tuning
**CybeDefend has a strict zero-training policy**: Your code, vulnerabilities, and interactions with our AI agents are **never used** for training, fine-tuning, or improving our models.
This policy ensures:
* **Complete confidentiality**: Your proprietary code remains private
* **No data leakage**: Your security findings never contribute to model training
* **Compliance**: GDPR compliant today. SOC 2 Type II and ISO 27001 audits in progress, see the [Security page](https://cybedefend.com/en/legal/security)
***
## Data Processing
When you use CybeDefend AI features (Cybe Analysis, Cybe AutoFix, Cybe Security Champion):
1. **Your code is parsed** into our proprietary knowledge graph
2. **Queries are sent** to sovereign LLMs within your chosen region
3. **Responses are generated** using your specific codebase context
4. **All data remains** within your regional boundary
LLM inference happens in real-time and is not persisted beyond the immediate request/response cycle.
### What the knowledge graph actually holds
The graph is what lets the agent apply your own business rules on its next generation. It stores **file paths and a short description of what each file does**. **It does not contain your source code.** You can delete it at any time from the project settings, and disabling the AI features stops it being built. Source code itself is destroyed with its container at the end of the scan, see [Never Stores Your Code](/latest/plateform-overview/security-privacy/never-stores-your-code).
***
## Regional LLM Deployment
Inference runs on open-weight models that CybeDefend hosts itself, inside the region you selected. Nothing crosses the regional boundary and no third-party AI API is involved.
| Region | Where inference runs | Operated by |
| ----------------- | --------------------------- | ------------------------------------------ |
| **Europe** | Scaleway, France | CybeDefend, self-hosted open-weight models |
| **United States** | Google Cloud, United States | CybeDefend, self-hosted open-weight models |
Certifications you may see listed for Scaleway or Google Cloud belong to **those providers** and describe the infrastructure we run on. CybeDefend's own certification status is on our [Security page](https://cybedefend.com/en/legal/security): GDPR compliant today, SOC 2 Type II and ISO 27001 audits in progress.
***
## Your Control
You can enable or disable AI features at the project level:
* **Cybe Analysis**: Can be toggled in project settings
* **Cybe AutoFix**: Requires explicit activation and Git integration
* **Cybe Security Champion**: Requires Cybe Analysis to be enabled
When AI features are disabled, no code is sent to LLMs.
***
**Related:** [Cybe Analysis Configuration](/latest/agent-ai-integration/cybe-analysis-detail) · [Data Storage & Privacy](/latest/plateform-overview/security-privacy/never-stores-your-code) · [Cloud Region Selection](/latest/get-started/account-setup/create-account-organization)
# Never Stores Your Code
Source: https://docs.cybedefend.com/latest/plateform-overview/security-privacy/never-stores-your-code
What CybeDefend receives, what it destroys at the end of the scan, and what it keeps.
In short: to scan your repository, CybeDefend has to receive it. We clone it into an isolated container, run the security checks, then destroy the container together with its copy of the code. **We do not keep your source code after the scan.** What we keep is the result: findings, their location, and repository metadata.
**Scanning platform and VibeDefend are two different things.** The platform receives your repository when you ask it to scan. **VibeDefend**, the layer that plugs into your AI coding agent, runs on the developer's machine: edits happen locally and only governance metadata comes back. This page describes the platform.
## Temporary Container Approach
When you connect your repository to CybeDefend, we create a **fresh container** to clone and analyze your code. This container is isolated and used only for your specific scan. Once the scan is done:
* The **container is terminated**.
* Any **temporary copies of your code** are destroyed immediately.
## The Process at a Glance
CybeDefend securely clones your repository into an isolated container, performs a vulnerability analysis, extracts only security findings, and completely wipes the container and code once the scan is complete.
![Secure Container Scanning]()
## What we keep, precisely
| What | Kept after the scan? |
| ----------------------------------------------------------------- | ------------------------------------------------------------ |
| Your source code | **No.** Destroyed with the container at the end of the scan. |
| Findings, severity, file and line of each finding | Yes. That is the product. |
| Repository metadata (names, branches, identifiers) | Yes. |
| Business-logic knowledge graph, **if you enable the AI features** | Yes. See below. |
### The business-logic knowledge graph
If you enable the AI features that learn your repository's own conventions, we build and keep a knowledge graph of your codebase. This is what lets the agent apply your business rules the next time it writes code.
The graph holds **file paths and a short description of what each file does**. **It does not contain your source code.**
* You can **delete it at any time** from the project settings.
* **Disabling the AI features** stops it being built in the first place, and no code is sent to the models.
### Where the analysis runs
Everything above happens inside the region you selected at signup: Scaleway for the EU region, Google Cloud for the US region. AI inference runs on open-weight models we host ourselves, in that same region. No code and no prompt is sent to any third-party AI API, and nothing crosses the regional boundary. See [LLM Usage & Privacy](/latest/plateform-overview/security-privacy/llm-usage-privacy).
# Create Security Champion conversation
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/create-security-champion-conversation
post /project/{projectId}/security-champion/conversation
Creates a new Security Champion AI conversation for a specific vulnerability. Returns a conversation ID to use with the streaming endpoint
# Delete conversation
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/delete-conversation
post /project/{projectId}/security-champion/{conversationId}/delete
Permanently deletes a Security Champion conversation and all associated messages
# Get conversation messages
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/get-conversation-messages
post /project/{projectId}/security-champion/{conversationId}/messages
Retrieves paginated messages from a specific Security Champion conversation
# List user conversations
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/list-user-conversations
post /project/{projectId}/security-champion/conversations/list
Retrieves Security Champion conversations for the authenticated user with optional filters and pagination
# Start AutoFix workflow
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/start-autofix-workflow
post /project/{projectId}/autofix
Initiates an AI-powered AutoFix workflow to automatically generate a fix for a vulnerability and create a Pull Request or Merge Request
# Start Batch AutoFix workflow
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/start-batch-autofix-workflow
post /project/{projectId}/autofix/batch
Initiates an AI-powered AutoFix workflow to automatically generate fixes for multiple vulnerabilities and create a single Pull Request or Merge Request
# Stop conversation generation
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/stop-conversation-generation
post /project/{projectId}/security-champion/{conversationId}/stop
Stops the ongoing AI response generation for a specific conversation
# Stream Security Champion messages
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ai-agent/stream-security-champion-messages
get /project/{projectId}/security-champion/{conversationId}/stream
Server-Sent Events (SSE) endpoint for streaming AI responses. Send a message and receive real-time token stream. Use heartbeat mode (no message) to maintain connection
# Get all container registry credentials for an organization
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/container-registry-credentials/get-all-container-registry-credentials-for-an-organization
get /integrations/container-registry/organization/{organizationId}/credentials
Returns all container registry credentials for an organization, grouped by provider.
**Supported providers:**
- **GitHub Container Registry (ghcr.io)** - Uses GitHub App installation (no stored credentials, returns availability status)
- **GitLab Container Registry** - Personal/group deploy tokens
- **DockerHub** - Personal access tokens
- **Azure Container Registry (ACR)** - Service principal credentials
- **Google Container Registry (GCR)** - Service account JSON keys
- **Amazon ECR** - IAM access keys
- **Quay.io** - Robot account credentials
- **Harbor** - Robot account credentials
- **JFrog Artifactory** - API keys or access tokens
This endpoint consolidates all registry credentials into a single response for easier frontend integration.
# Get GitHub repositories
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-integration/get-github-repositories
get /organization/{organizationId}/github/repositories
Retrieves all accessible GitHub repositories for an organization. Returns repositories from all GitHub installations associated with the organization.
# Get GitHub repository branches
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-integration/get-github-repository-branches
get /organization/{organizationId}/github/repositories/{repositoryId}/branches
Retrieves all branches for a specific GitHub repository in an organization. Use this to populate branch selection when linking a repository.
# Link GitHub repository to project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-integration/link-github-repository-to-project
post /organization/{organizationId}/project/{projectId}/github/link
Creates a link between a GitHub repository and a CybeDefend project for automated scanning. Once linked, the project will receive webhook events from the repository for automated security scans.
# Start GitHub repository scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-integration/start-github-repository-scan
post /project/{projectId}/github/start-scan
Triggers an asynchronous security scan on the latest commit of a linked GitHub repository. The scan runs in the background and results can be retrieved via the analysis reporting endpoints.
# Unlink GitHub repository from project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-integration/unlink-github-repository-from-project
delete /organization/{organizationId}/project/{projectId}/github/unlink
Removes the link between a GitHub repository and a CybeDefend project. This will stop webhook events and automated scans for this repository.
# Get GitLab repositories
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-integration/get-gitlab-repositories
get /integrations/gitlab/organization/{organizationId}/repositories
Retrieves all synchronized GitLab repositories for an organization. Returns repositories that the authenticated GitLab user has access to.
# Get GitLab repository branches
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-integration/get-gitlab-repository-branches
get /integrations/gitlab/organization/{organizationId}/repositories/{repositoryId}/branches
Retrieves all branches for a specific GitLab repository. Use this to populate branch selection when linking a repository.
# Link GitLab repository to project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-integration/link-gitlab-repository-to-project
post /integrations/gitlab/organization/{organizationId}/project/{projectId}/link
Creates a link between a GitLab repository and a CybeDefend project. Once linked, the project will receive webhook events from the repository for automated security scans.
# Start GitLab repository scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-integration/start-gitlab-repository-scan
post /integrations/gitlab/project/{projectId}/start-scan
Triggers an asynchronous security scan on the latest commit of a linked GitLab repository. The scan runs in the background and results can be retrieved via the analysis reporting endpoints.
# Unlink GitLab repository from project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-integration/unlink-gitlab-repository-from-project
delete /integrations/gitlab/organization/{organizationId}/project/{projectId}/unlink
Removes the link between a GitLab repository and a CybeDefend project. This will stop webhook events and automated scans for this repository.
# Get integration overview for organization
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/integrations/get-integration-overview-for-organization
get /organization/{organizationId}/integrations/overview
Returns combined status of all integrations including GitHub installation, GitLab connection, and container registry credentials count for the organization. This endpoint consolidates multiple API calls into a single request for better performance.
# Create a new security policy
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/create-a-new-security-policy
post /organization/{organizationId}/policies
# Delete a security policy
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/delete-a-security-policy
delete /organization/{organizationId}/policies/{policyId}
# Enable or disable a security policy
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/enable-or-disable-a-security-policy
put /organization/{organizationId}/policies/{policyId}/toggle
Toggle the enabled state of a security policy. For organization-level policies, only one can be active at a time.
# Export a policy as YAML file
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/export-a-policy-as-yaml-file
get /organization/{organizationId}/policies/{policyId}/yaml
# Get a security policy by ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-a-security-policy-by-id
get /organization/{organizationId}/policies/{policyId}
# Get compliance history for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-compliance-history-for-a-project
get /projects/{projectId}/compliance-history
Returns a paginated list of past policy evaluations for the project.
# Get compliance result for a scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-compliance-result-for-a-scan
get /projects/{projectId}/scans/{scanId}/compliance
Returns the compliance result from the most recent policy evaluation for this scan.
# Get effective policies for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-effective-policies-for-a-project
get /projects/{projectId}/effective-policies
Returns the list of policies that apply to this project (from organization, team, and project scopes).
# Get organization-wide compliance overview for CISO dashboard
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-organization-wide-compliance-overview-for-ciso-dashboard
get /organization/{organizationId}/compliance-overview
Returns a comprehensive overview of all projects within the organization with their compliance status, violation statistics, breakdown by rule type, and trend data for the last 30 days.
# Get policy violations for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-policy-violations-for-a-project
get /projects/{projectId}/violations
# Get policy violations for a scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-policy-violations-for-a-scan
get /projects/{projectId}/scans/{scanId}/violations
# Get the evaluation status for a scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-the-evaluation-status-for-a-scan
get /projects/{projectId}/scans/{scanId}/evaluation-status
Check if a policy evaluation has been triggered for this scan, and if so, what its current status is. Used by the CLI to poll for completion before checking compliance results.
# Get violation statistics for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/get-violation-statistics-for-a-project
get /projects/{projectId}/violation-stats
# List security policies
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/list-security-policies
get /organization/{organizationId}/policies
# Update a security policy
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/update-a-security-policy
put /organization/{organizationId}/policies/{policyId}
# Validate a policy YAML configuration without saving
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/policy/validate-a-policy-yaml-configuration-without-saving
post /organization/{organizationId}/policies/validate
# Analyze SCA vulnerabilities for autofix candidates
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/analyze-sca-vulnerabilities-for-autofix-candidates
post /project/{projectId}/results/sca/autofix
Analyzes SCA vulnerabilities using DeepFix to find fix candidates. For transitive dependencies, determines which version of the direct dependency will resolve the vulnerable package to a safe version. Returns the dependency path showing the import chain and recommended fixes.
# Batch update multiple vulnerabilities
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/batch-update-multiple-vulnerabilities
patch /project/{projectId}/results/batch
Update status, priority, and/or comment for multiple vulnerabilities at once. Maximum 100 vulnerabilities per request.
# Delete a scanned container image from a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/delete-a-scanned-container-image-from-a-project
delete /project/{projectId}/results/container/images/{imageId}
# Generate a security report for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/generate-a-security-report-for-a-project
get /project/{projectId}/owasp-report/{format}
Generate either an SBOM (Software Bill of Materials) report or OWASP Top 10 report in JSON, HTML, or PDF format
# Generate aggregated security report for a Team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/generate-aggregated-security-report-for-a-team
get /team/{teamId}/report/{reportType}/{format}
Generates a consolidated OWASP Top 10 or CWE Top 25 report for all projects in a team
# Generate aggregated security report for an Organization
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/generate-aggregated-security-report-for-an-organization
get /organization/{organizationId}/report/{reportType}/{format}
Generates a consolidated OWASP Top 10 or CWE Top 25 report for all projects in an organization
# Generate CWE Top 25 2024 report for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/generate-cwe-top-25-2024-report-for-a-project
get /project/{projectId}/cwe-report/{format}
# Generate report for a manual selection of projects
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/generate-report-for-a-manual-selection-of-projects
post /organization/{organizationId}/project/report/batch/{reportType}/{format}
Generates a consolidated OWASP Top 10 or CWE Top 25 report for a custom list of projects
# Get a container vulnerability by ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-container-vulnerability-by-id
get /project/{projectId}/results/container/{vulnerabilityId}
Retrieves detailed information about a specific container vulnerability
# Get a vulnerability of a project for CICD
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-vulnerability-of-a-project-for-cicd
get /project/{projectId}/results/cicd/{vulnerabilityId}
# Get a vulnerability of a project for IaC
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-vulnerability-of-a-project-for-iac
get /project/{projectId}/results/iac/{vulnerabilityId}
# Get a vulnerability of a project for SAST
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-vulnerability-of-a-project-for-sast
get /project/{projectId}/results/sast/{vulnerabilityId}
# Get a vulnerability of a project for SCA
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-vulnerability-of-a-project-for-sca
get /project/{projectId}/results/sca/{vulnerabilityId}
# Get a vulnerability of a project for Secret
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-a-vulnerability-of-a-project-for-secret
get /project/{projectId}/results/secret/{vulnerabilityId}
# Get aggregated overview statistics for an organization
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-aggregated-overview-statistics-for-an-organization
get /organization/{organizationId}/results/overview
Returns comprehensive vulnerability statistics aggregated across all projects in the organization. Supports filtering by projects, teams, severity, status, analysis types, date ranges, languages, branches, and more. Includes pagination for summaries and period-over-period comparison.
# Get all CICD vulnerabilities of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-cicd-vulnerabilities-of-a-project
get /project/{projectId}/results/cicd
# Get all container images of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-container-images-of-a-project
get /project/{projectId}/results/container/images
Retrieves all scanned container images associated with a project
# Get all container packages of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-container-packages-of-a-project
get /project/{projectId}/results/container/packages
Retrieves all packages detected in container images for a project
# Get all container vulnerabilities of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-container-vulnerabilities-of-a-project
get /project/{projectId}/results/container
Retrieves paginated container vulnerabilities with filtering options
# Get all IaC vulnerabilities of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-iac-vulnerabilities-of-a-project
get /project/{projectId}/results/iac
# Get all SCA packages of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-sca-packages-of-a-project
get /project/{projectId}/results/sca/packages
# Get all SCA vulnerabilities of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-sca-vulnerabilities-of-a-project
get /project/{projectId}/results/sca
# Get all Secret vulnerabilities of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-secret-vulnerabilities-of-a-project
get /project/{projectId}/results/secret
# Get all vulnerabilities of a project for SAST
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-all-vulnerabilities-of-a-project-for-sast
get /project/{projectId}/results/sast
# Get branches from vulnerability detections
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-branches-from-vulnerability-detections
get /project/{projectId}/branches
Retrieves distinct branch names found in SAST, SCA, and IAC vulnerability detections. Use this endpoint for projects that are not linked to GitHub or GitLab integrations.
# Get CICD vulnerabilities grouped by rule ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-cicd-vulnerabilities-grouped-by-rule-id
get /project/{projectId}/results/cicd/grouped
Returns CICD vulnerabilities consolidated by rule with occurrence counts and severity breakdown.
# Get container images grouped by repository
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-container-images-grouped-by-repository
get /project/{projectId}/results/container/images/grouped
Retrieves container images grouped by repository name, showing all tags within each image. Useful for viewing images with multiple tags (e.g., v1.0.0, latest) as a single entity.
# Get IAC vulnerabilities grouped by rule ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-iac-vulnerabilities-grouped-by-rule-id
get /project/{projectId}/results/iac/grouped
Returns IAC vulnerabilities consolidated by rule with occurrence counts and severity breakdown.
# Get overview of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-overview-of-a-project
get /project/{projectId}/results/overview
# Get SAST vulnerabilities grouped by rule ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-sast-vulnerabilities-grouped-by-rule-id
get /project/{projectId}/results/sast/grouped
Returns SAST vulnerabilities consolidated by rule with occurrence counts and severity breakdown. Useful for showing unique vulnerability types with their occurrences.
# Get SBOM report for a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-sbom-report-for-a-project
get /project/{projectId}/sbom
# Get SCA AutoFix job results
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-sca-autofix-job-results
get /project/{projectId}/results/sca/autofix/{jobId}
Get the full results of a completed SCA AutoFix job. Returns all analysis results including fix candidates and PR information.
# Get SCA AutoFix job status
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-sca-autofix-job-status
get /project/{projectId}/results/sca/autofix/{jobId}/status
Poll this endpoint to check the status of an SCA AutoFix job. Returns progress information and status (queued, processing, completed, failed).
# Get SCA vulnerabilities grouped by CVE + package name
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-sca-vulnerabilities-grouped-by-cve-+-package-name
get /project/{projectId}/results/sca/grouped
Returns SCA vulnerabilities consolidated by CVE and package with occurrence counts, severity breakdown, and CVSS scores.
# Get Secret vulnerabilities grouped by rule ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-secret-vulnerabilities-grouped-by-rule-id
get /project/{projectId}/results/secret/grouped
Returns Secret vulnerabilities consolidated by rule with occurrence counts and severity breakdown.
# Get vulnerability by ID with similar occurrences
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-vulnerability-by-id-with-similar-occurrences
get /project/{projectId}/results/{vulnerabilityId}/similar
Returns a vulnerability and all similar occurrences (same rule for SAST/IAC/CICD/Secret, same CVE for SCA).
# Update a vulnerability of a project
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/update-a-vulnerability-of-a-project
patch /project/{projectId}/results/{vulnerabilityId}
# Assign License to Package
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/assign-package-license
PUT /project/{projectId}/sca/packages/{packageId}/license
Manually assign an SPDX license ID to a specific SCA package
## Path Parameters
The UUID of the project
The UUID of the SCA package
## Authorization
Requires `change_vulnerability_state` permission on the project.
## Request Body
The SPDX license identifier to assign (e.g., `MIT`, `Apache-2.0`, `GPL-3.0-only`)
```json theme={null}
{
"spdxId": "MIT"
}
```
## Response
Whether the request succeeded
Confirmation message
```json theme={null}
{
"success": true,
"message": "License assigned successfully"
}
```
Assigning a license to a package that was previously categorized as **Unknown** will remove the Unknown placeholder and update the package's license list. This is particularly useful for internal packages or packages whose license metadata is missing from the registry.
# Get License Classifications
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/get-license-classifications
GET /organization/{organizationId}/licenses/classifications
Get all license classifications for an organization, including defaults and overrides
## Path Parameters
The UUID of the organization
## Authorization
Requires `read` permission on the organization.
## Response
Whether the request succeeded
SPDX license identifier
Human-readable license name
CybeDefend's default category: `PERMISSIVE`, `WEAK_COPYLEFT`, `STRONG_COPYLEFT`, or `UNKNOWN`
Currently active category (may differ from default if overridden)
Whether this license has been overridden at the organization level
```json theme={null}
{
"success": true,
"data": {
"licenses": [
{
"spdxId": "MIT",
"name": "MIT License",
"defaultCategory": "PERMISSIVE",
"currentCategory": "PERMISSIVE",
"isOverridden": false
},
{
"spdxId": "BUSL-1.1",
"name": "Business Source License 1.1",
"defaultCategory": "WEAK_COPYLEFT",
"currentCategory": "STRONG_COPYLEFT",
"isOverridden": true
}
]
}
}
```
# Get License Summary
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/get-license-summary
GET /project/{projectId}/results/sca/licenses/summary
Get aggregated license statistics for all SCA packages in a project
## Path Parameters
The UUID of the project
## Query Parameters
Filter by Git branch name
The UUID of the organization (required for permission resolution)
Filter by package ecosystem (e.g., `npm`, `pip`, `maven`, `go`). Can be specified multiple times.
## Authorization
Requires `read_scan_result` permission on the project.
## Response
Whether the request succeeded
The project UUID
Total number of SCA packages
Number of packages with at least one detected license
Number of packages with no detected license
Number of packages classified as Permissive
Number of packages classified as Weak Copyleft
Number of packages classified as Strong Copyleft
Number of packages with unknown or unresolved licenses
Number of packages marked as ignored for license analysis
SPDX license identifier (e.g., `MIT`, `Apache-2.0`)
Human-readable license name
License category: `PERMISSIVE`, `WEAK_COPYLEFT`, `STRONG_COPYLEFT`, or `UNKNOWN`
Risk level: `NONE`, `MEDIUM`, `HIGH`, or `UNKNOWN`
Human-readable description of the risk implications
Number of packages using this license
```json theme={null}
{
"success": true,
"data": {
"projectId": "550e8400-e29b-41d4-a716-446655440001",
"totalPackages": 142,
"packagesWithLicenses": 135,
"packagesWithoutLicenses": 7,
"permissiveCount": 120,
"weakCopyleftCount": 8,
"strongCopyleftCount": 3,
"unknownCount": 7,
"ignoredCount": 4,
"licenses": [
{
"spdxId": "MIT",
"name": "MIT License",
"category": "PERMISSIVE",
"risk": "NONE",
"riskDescription": "Minimal restrictions on use, modification, and redistribution",
"count": 85
},
{
"spdxId": "Apache-2.0",
"name": "Apache License 2.0",
"category": "PERMISSIVE",
"risk": "NONE",
"riskDescription": "Minimal restrictions on use, modification, and redistribution",
"count": 25
},
{
"spdxId": "GPL-3.0-only",
"name": "GNU General Public License v3.0 only",
"category": "STRONG_COPYLEFT",
"risk": "HIGH",
"riskDescription": "Requires derivative works to be released under the same license",
"count": 3
}
]
}
}
```
# Get Packages by License
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/get-packages-by-license
GET /project/{projectId}/results/sca/licenses/{spdxId}/packages
Get all packages in a project that use a specific SPDX license
## Path Parameters
The UUID of the project
The SPDX license identifier (e.g., `MIT`, `Apache-2.0`, `GPL-3.0-only`). Use `UNKNOWN` to retrieve packages with no detected license.
## Query Parameters
Filter by Git branch name
The UUID of the organization (required for permission resolution)
Filter by package ecosystem (e.g., `npm`, `pip`, `maven`, `go`). Can be specified multiple times.
## Authorization
Requires `read_scan_result` permission on the project.
## Response
Whether the request succeeded
SPDX license identifier
Human-readable license name
License category: `PERMISSIVE`, `WEAK_COPYLEFT`, `STRONG_COPYLEFT`, or `UNKNOWN`
Risk level: `NONE`, `MEDIUM`, `HIGH`, or `UNKNOWN`
Human-readable description of the risk implications
Total number of packages using this license
Package UUID
Package name (e.g., `lodash`, `express`)
Package version
Package ecosystem (npm, pip, maven, etc.)
All SPDX license IDs associated with this package
Whether this is a transitive (indirect) dependency
Whether this is a dev-only dependency
Whether this package is ignored in license analysis
```json theme={null}
{
"success": true,
"data": {
"spdxId": "MIT",
"name": "MIT License",
"category": "PERMISSIVE",
"risk": "NONE",
"riskDescription": "Minimal restrictions on use, modification, and redistribution",
"totalCount": 85,
"packages": [
{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"packageName": "lodash",
"packageVersion": "4.17.21",
"ecosystem": "npm",
"licenses": ["MIT"],
"isTransitive": false,
"isDev": false,
"isLicenseIgnored": false
},
{
"id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"packageName": "express",
"packageVersion": "4.18.2",
"ecosystem": "npm",
"licenses": ["MIT"],
"isTransitive": false,
"isDev": false,
"isLicenseIgnored": false
}
]
}
}
```
# Reset License Classifications
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/reset-license-classifications
DELETE /organization/{organizationId}/licenses/classifications
Reset all license classification overrides for an organization back to defaults
## Path Parameters
The UUID of the organization
## Authorization
Requires `manage` permission on the organization.
## Response
Whether the request succeeded
Confirmation message
```json theme={null}
{
"success": true,
"message": "All license classification overrides have been reset"
}
```
This action removes **all** organization-level license classification overrides and reverts to CybeDefend's default classifications. This cannot be undone.
# Toggle Package License Ignore
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/toggle-package-license-ignore
PUT /project/{projectId}/sca/packages/{packageId}/license-ignore
Toggle the ignore status for a package in license analysis
## Path Parameters
The UUID of the project
The UUID of the SCA package
## Authorization
Requires `change_vulnerability_state` permission on the project.
## Request Body
Set to `true` to ignore the package in license analysis, or `false` to include it again.
```json theme={null}
{
"ignored": true
}
```
## Response
Whether the request succeeded
Confirmation message
```json theme={null}
{
"success": true,
"message": "Package license ignore status updated"
}
```
Ignored packages are excluded from the license summary counts but remain visible in the package detail view. Use this for internal packages or test dependencies that are not relevant to your license compliance.
# Update License Classifications
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sca-licenses/update-license-classifications
PUT /organization/{organizationId}/licenses/classifications
Update license classification overrides for an organization
## Path Parameters
The UUID of the organization
## Authorization
Requires `manage` permission on the organization.
## Request Body
Array of license classification overrides to apply.
The SPDX license identifier to override (e.g., `MIT`, `BUSL-1.1`)
The new category: `PERMISSIVE`, `WEAK_COPYLEFT`, `STRONG_COPYLEFT`, or `UNKNOWN`
```json theme={null}
{
"overrides": [
{
"spdxId": "BUSL-1.1",
"category": "STRONG_COPYLEFT"
},
{
"spdxId": "Artistic-2.0",
"category": "PERMISSIVE"
}
]
}
```
## Response
Whether the request succeeded
Confirmation message
```json theme={null}
{
"success": true,
"message": "License classifications updated"
}
```
Overrides apply to **all projects** in the organization. Changing a license from Permissive to Strong Copyleft may surface new compliance issues across all projects.
# Get a scan by ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scan/get-a-scan-by-id
get /project/{projectId}/scan/{scanId}
Retrieves detailed information about a specific scan including status, progress, and configuration.
# Start a public container scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scan/start-a-public-container-scan
post /project/{projectId}/scan/container/start
Initiates a container image vulnerability scan for a public Docker image.
# Start a scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scan/start-a-scan
post /project/{projectId}/scan/start
Initiates a security scan for a project. Returns a signed URL to upload the source code. The scan will analyze the code for SAST, IaC, and SCA vulnerabilities based on project configuration.
# Add a member to a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/add-a-member-to-a-team
post /team/{teamId}/member
# Create a new team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/create-a-new-team
post /organization/{organizationId}/team
# Delete a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/delete-a-team
delete /team/{teamId}
# Get a member of a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/get-a-member-of-a-team
get /team/{teamId}/member/{userId}
# Get all members of a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/get-all-members-of-a-team
get /team/{teamId}/members
# Get all teams of an organization
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/get-all-teams-of-an-organization
get /organization/{organizationId}/teams
# Get team by ID
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/get-team-by-id
get /organization/{organizationId}/team/{teamId}
# Remove a member from a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/remove-a-member-from-a-team
delete /team/{teamId}/member
# Update a member role in a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/update-a-member-role-in-a-team
put /team/{teamId}/member/role
# Update a team
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/team/update-a-team
put /team/{teamId}
# Create a personal access token
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/create-a-personal-access-token
post /user/personal-access-tokens
# Delete a personal access token
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/delete-a-personal-access-token
post /user/personal-access-tokens/delete
# Get user profile
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/get-user-profile
get /user/profile
Retrieves the profile information of the currently authenticated user including notification settings and onboarding status.
# List personal access tokens
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/list-personal-access-tokens
get /user/personal-access-tokens
# Rename a personal access token
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/rename-a-personal-access-token
patch /user/personal-access-tokens/name
# Update user profile
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/user/update-user-profile
patch /user/profile
Updates the profile information of the currently authenticated user. Allows modification of notification preferences and onboarding completion status.
# Get app IDs for native clients
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/version/get-app-ids-for-native-clients
get /client-apps
Returns the public application IDs for native clients (CLI, VS Code Extension, IntelliJ IDEA Extension). No authentication required.
# Delete ACR credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/delete-acr-credentials
delete /integrations/acr/container-registry/organization/{organizationId}/credentials/{credentialId}
Permanently deletes stored Azure Container Registry credentials from the organization
# Get ACR credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/get-acr-credential-details
get /integrations/acr/container-registry/project/{projectId}/credentials/{credentialId}
Returns detailed information about a specific Azure Container Registry credential (sanitized, no secrets exposed)
# List ACR credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/list-acr-credentials
get /integrations/acr/container-registry/project/{projectId}/credentials
Returns all Azure Container Registry credentials available for the project (sanitized, no secrets exposed)
# List ACR image tags
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/list-acr-image-tags
get /integrations/acr/container-registry/project/{projectId}/images/{repositoryId}/tags
Lists all available tags for a specific Docker image (repository) in Azure Container Registry
# List ACR images
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/list-acr-images
get /integrations/acr/container-registry/project/{projectId}/images
Lists all Docker images (repositories) available in the Azure Container Registry using the specified credentials
# Start ACR container scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/start-acr-container-scan
post /integrations/acr/container-registry/project/{projectId}/scan
Initiates a vulnerability scan for a Docker image stored in Azure Container Registry. The scan runs asynchronously and results can be retrieved via the scan results endpoint.
# Store ACR Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/acr-container-registry/store-acr-container-registry-credentials
post /integrations/acr/container-registry/organization/{organizationId}/credentials
Stores Azure Container Registry Service Principal credentials at organization level. The credentials will be encrypted and stored securely.
# Bulk-apply a container-registry credential to projects
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/container-registry-credentials/bulk-apply-a-container-registry-credential-to-projects
post /integrations/container-registry/organization/{organizationId}/bulk-apply
Creates (or rotates) one credential of the given registry type and links it to a set of projects in a single call. Unknown or foreign-organization projects are skipped and reported in the response.
# List projects linked to a container-registry credential
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/container-registry-credentials/list-projects-linked-to-a-container-registry-credential
get /integrations/container-registry/organization/{organizationId}/credentials/{registryType}/{credentialId}/projects
Returns the full set of project ids currently linked to an organization-level container-registry credential, for the given registry type.
# Set projects linked to a container-registry credential
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/container-registry-credentials/set-projects-linked-to-a-container-registry-credential
put /integrations/container-registry/organization/{organizationId}/credentials/{registryType}/{credentialId}/projects
Replaces the full set of projects linked to an organization-level container-registry credential. An empty array unlinks the credential from every project.
# Delete DockerHub credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/delete-dockerhub-credentials
delete /integrations/dockerhub/container-registry/organization/{organizationId}/credentials/{credentialId}
Permanently deletes stored DockerHub credentials from the organization
# Get DockerHub credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/get-dockerhub-credential-details
get /integrations/dockerhub/container-registry/project/{projectId}/credentials/{credentialId}
Returns detailed information about a specific DockerHub credential (sanitized, no secrets exposed)
# List DockerHub credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/list-dockerhub-credentials
get /integrations/dockerhub/container-registry/project/{projectId}/credentials
Returns all DockerHub credentials available for the project (sanitized, no secrets exposed)
# List DockerHub image tags
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/list-dockerhub-image-tags
get /integrations/dockerhub/container-registry/project/{projectId}/images/{repositoryName}/tags
Lists all available tags for a specific Docker image (repository) in DockerHub
# List DockerHub images
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/list-dockerhub-images
get /integrations/dockerhub/container-registry/project/{projectId}/images
Lists all Docker images (repositories) available in the DockerHub namespace using the specified credentials
# Start DockerHub container scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/start-dockerhub-container-scan
post /integrations/dockerhub/container-registry/project/{projectId}/scan
Initiates a vulnerability scan for a Docker image stored in DockerHub. The scan runs asynchronously and results can be retrieved via the scan results endpoint.
# Store DockerHub Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/dockerhub-container-registry/store-dockerhub-container-registry-credentials
post /integrations/dockerhub/container-registry/organization/{organizationId}/credentials
Stores DockerHub Personal Access Token credentials at organization level. The credentials will be encrypted and stored securely.
# Delete ECR credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/delete-ecr-credentials
delete /integrations/ecr/container-registry/organization/{organizationId}/credentials/{credentialId}
Permanently deletes stored AWS Elastic Container Registry credentials from the organization
# Get ECR credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/get-ecr-credential-details
get /integrations/ecr/container-registry/project/{projectId}/credentials/{credentialId}
Returns detailed information about a specific AWS Elastic Container Registry credential (sanitized, no secrets exposed)
# List ECR credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/list-ecr-credentials
get /integrations/ecr/container-registry/project/{projectId}/credentials
Returns all AWS Elastic Container Registry credentials available for the project (sanitized, no secrets exposed)
# List ECR image tags
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/list-ecr-image-tags
get /integrations/ecr/container-registry/project/{projectId}/images/{repositoryId}/tags
Lists all available tags for a specific Docker image (repository) in AWS Elastic Container Registry
# List ECR images
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/list-ecr-images
get /integrations/ecr/container-registry/project/{projectId}/images
Lists all Docker images (repositories) available in the AWS Elastic Container Registry using the specified credentials
# List organization ECR credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/list-organization-ecr-credentials
get /integrations/ecr/container-registry/organization/{organizationId}/credentials
Returns all AWS Elastic Container Registry credentials stored at organization level (sanitized, no secrets exposed) with the count of linked projects.
# List projects linked to an ECR credential
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/list-projects-linked-to-an-ecr-credential
get /integrations/ecr/container-registry/organization/{organizationId}/credentials/{credentialId}/projects
Returns the full set of project ids currently linked to an organization-level ECR credential.
# Prepare an IAM-role-based ECR integration
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/prepare-an-iam-role-based-ecr-integration
post /integrations/ecr/container-registry/organization/{organizationId}/credentials/prepare-iam-role
Generates a unique external ID and returns the trust + permission policies the customer attaches to a role in their own AWS account. Use the returned external ID and the created role ARN with the store credentials endpoint (credentialType=iam_role).
# Set projects linked to an ECR credential
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/set-projects-linked-to-an-ecr-credential
put /integrations/ecr/container-registry/organization/{organizationId}/credentials/{credentialId}/projects
Replaces the full set of projects linked to an organization-level ECR credential. An empty array unlinks the credential from every project.
# Start ECR container scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/start-ecr-container-scan
post /integrations/ecr/container-registry/project/{projectId}/scan
Initiates a vulnerability scan for a Docker image stored in AWS Elastic Container Registry. The scan runs asynchronously and results can be retrieved via the scan results endpoint.
# Store ECR Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/ecr-container-registry/store-ecr-container-registry-credentials
post /integrations/ecr/container-registry/organization/{organizationId}/credentials
Stores AWS Elastic Container Registry credentials at organization level. The credentials will be encrypted and stored securely.
# Delete GCR Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/delete-gcr-container-registry-credentials
delete /integrations/gcr/container-registry/organization/{organizationId}/credentials/{credentialId}
Permanently deletes stored Google Container Registry or Artifact Registry credentials from the organization. This action cannot be undone.
# Get GCR Container Registry credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/get-gcr-container-registry-credential-details
get /integrations/gcr/container-registry/project/{projectId}/credentials/{credentialId}
Returns detailed information about a specific Google Container Registry or Artifact Registry credential. Sensitive data like service account keys are sanitized and not included in the response.
# List container images from GCR/Artifact Registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/list-container-images-from-gcrartifact-registry
get /integrations/gcr/container-registry/project/{projectId}/images
Retrieves a paginated list of all container images stored in Google Container Registry (GCR) or Artifact Registry. Uses the specified credential for authentication.
# List stored GCR Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/list-stored-gcr-container-registry-credentials
get /integrations/gcr/container-registry/project/{projectId}/credentials
Returns all Google Container Registry and Artifact Registry credentials associated with the project. Credentials are sanitized and do not include sensitive secrets like service account keys.
# List tags for a container image
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/list-tags-for-a-container-image
get /integrations/gcr/container-registry/project/{projectId}/images/{repositoryId}/tags
Retrieves all available tags for a specific container image in Google Container Registry (GCR) or Artifact Registry. Includes digest information and image metadata for each tag.
# Start GCR container vulnerability scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/start-gcr-container-vulnerability-scan
post /integrations/gcr/container-registry/project/{projectId}/scan
Initiates a vulnerability scan for a container image stored in Google Container Registry (GCR) or Artifact Registry. The scan runs asynchronously and results can be retrieved using the returned scan ID.
# Store GCR Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gcr-container-registry/store-gcr-container-registry-credentials
post /integrations/gcr/container-registry/organization/{organizationId}/credentials
Stores GCP service account key credentials for Google Container Registry (GCR) or Artifact Registry at the organization level. These credentials will be used to authenticate and pull container images for vulnerability scanning.
# Delete stored PAT for ghcr.io
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/delete-stored-pat-for-ghcrio
delete /integrations/github-container-registry/organization/{organizationId}/pat
Removes the stored Personal Access Token. After deletion, scanning private/internal packages will no longer be possible.
# Get GitHub Container Registry token
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/get-github-container-registry-token
get /integrations/github-container-registry/organization/{organizationId}/token
Generates a temporary GitHub App installation token for ghcr.io access. Use this token with docker login: `docker login ghcr.io -u x-access-token -p `. Token expires after approximately 1 hour.
# Get PAT status for ghcr.io
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/get-pat-status-for-ghcrio
get /integrations/github-container-registry/organization/{organizationId}/pat/status
Checks if a Personal Access Token is stored and validates it. Returns information about the token without exposing the actual token value.
# List Docker images from GitHub Container Registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/list-docker-images-from-github-container-registry
get /integrations/github-container-registry/organization/{organizationId}/images
Lists all Docker images available in ghcr.io for the GitHub account associated with the organization.
# List image tags from GitHub Container Registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/list-image-tags-from-github-container-registry
get /integrations/github-container-registry/organization/{organizationId}/images/{packageName}/tags
Lists all available tags/versions for a Docker image hosted on ghcr.io.
# Start GitHub Container Registry scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/start-github-container-registry-scan
post /integrations/github-container-registry/project/{projectId}/scan
Initiates a vulnerability scan for a container image hosted on ghcr.io. Uses the GitHub App installation token or configured PAT for authentication. The image is validated to ensure it belongs to the organization before scanning.
# Store a Personal Access Token (PAT) for ghcr.io
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/github-container-registry/store-a-personal-access-token-pat-for-ghcrio
post /integrations/github-container-registry/organization/{organizationId}/pat
Stores a GitHub Personal Access Token with read:packages scope. This is REQUIRED for scanning private or internal container images, as GitHub App tokens cannot pull these packages from ghcr.io. The token is encrypted before storage.
# Delete GitLab Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/delete-gitlab-container-registry-credentials
delete /integrations/gitlab/container-registry/organization/{organizationId}/credentials/{credentialId}
Permanently deletes stored GitLab Container Registry (registry.gitlab.com) credentials from the organization. This action cannot be undone.
# Get GitLab Container Registry credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/get-gitlab-container-registry-credential-details
get /integrations/gitlab/container-registry/project/{projectId}/credentials/{credentialId}
Returns detailed information about a specific GitLab Container Registry (registry.gitlab.com) credential. Credentials are sanitized and do not include secrets.
# List Docker image tags from GitLab Container Registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/list-docker-image-tags-from-gitlab-container-registry
get /integrations/gitlab/container-registry/project/{projectId}/images/{repositoryId}/tags
Lists all available tags for a specific Docker image in GitLab Container Registry (registry.gitlab.com). Useful for selecting which image version to scan.
# List Docker images from GitLab Container Registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/list-docker-images-from-gitlab-container-registry
get /integrations/gitlab/container-registry/project/{projectId}/images
Lists all Docker images available in the GitLab Container Registry (registry.gitlab.com) using the specified credentials. Results are paginated.
# List GitLab Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/list-gitlab-container-registry-credentials
get /integrations/gitlab/container-registry/project/{projectId}/credentials
Returns all GitLab Container Registry (registry.gitlab.com) credentials available for the project. Credentials are sanitized and do not include secrets.
# Start GitLab Container Registry scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/start-gitlab-container-registry-scan
post /integrations/gitlab/container-registry/project/{projectId}/scan
Initiates a security scan for a container image from GitLab Container Registry (registry.gitlab.com). The scan runs asynchronously and results can be retrieved via the scan status endpoint.
# Store GitLab Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/gitlab-container-registry/store-gitlab-container-registry-credentials
post /integrations/gitlab/container-registry/organization/{organizationId}/credentials
Stores deploy token credentials for GitLab Container Registry (registry.gitlab.com) at organization level. These credentials are used to authenticate and pull container images for security scanning.
# Delete Harbor credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/delete-harbor-credentials
delete /integrations/harbor/container-registry/organization/{organizationId}/credentials/{credentialId}
Deletes stored Harbor self-hosted container registry credentials from the organization
# Get Harbor credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/get-harbor-credential-details
get /integrations/harbor/container-registry/project/{projectId}/credentials/{credentialId}
Returns Harbor self-hosted registry credential details (sanitized, no secrets exposed)
# List Docker images from Harbor
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/list-docker-images-from-harbor
get /integrations/harbor/container-registry/project/{projectId}/credentials/{credentialId}/images
Returns available Docker images/repositories from the Harbor self-hosted container registry
# List Harbor image tags
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/list-harbor-image-tags
get /integrations/harbor/container-registry/project/{projectId}/credentials/{credentialId}/images/{repository}/tags
Returns available tags for a Docker image in Harbor self-hosted registry
# List Harbor projects
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/list-harbor-projects
get /integrations/harbor/container-registry/project/{projectId}/credentials/{credentialId}/projects
Returns Harbor self-hosted registry projects accessible with the stored credentials. Projects in Harbor are organizational units that contain repositories.
# List stored Harbor credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/list-stored-harbor-credentials
get /integrations/harbor/container-registry/project/{projectId}/credentials
Returns all Harbor self-hosted container registry credentials associated with the project (sanitized, no secrets exposed)
# Start Harbor container scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/start-harbor-container-scan
post /integrations/harbor/container-registry/project/{projectId}/scan
Initiates a security vulnerability scan for a container image from Harbor self-hosted registry. The scan runs asynchronously and results can be retrieved via the scan status endpoint.
# Store Harbor Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/harbor-container-registry/store-harbor-container-registry-credentials
post /integrations/harbor/container-registry/organization/{organizationId}/credentials
Stores robot account or user credentials for Harbor self-hosted registry at organization level. Supports authentication via robot accounts or standard user credentials.
# Delete JFrog Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/delete-jfrog-container-registry-credentials
delete /integrations/jfrog/container-registry/organization/{organizationId}/credentials/{credentialId}
Deletes stored JFrog Artifactory Docker registry credentials from the organization
# Get JFrog credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/get-jfrog-credential-details
get /integrations/jfrog/container-registry/project/{projectId}/credentials/{credentialId}
Returns JFrog Artifactory Docker registry credential details (sanitized, no secrets exposed)
# List Docker images in JFrog Artifactory repository
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/list-docker-images-in-jfrog-artifactory-repository
get /integrations/jfrog/container-registry/project/{projectId}/credentials/{credentialId}/images
Returns Docker container images stored in a JFrog Artifactory repository for vulnerability scanning
# List JFrog Artifactory Docker repositories
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/list-jfrog-artifactory-docker-repositories
get /integrations/jfrog/container-registry/project/{projectId}/credentials/{credentialId}/repositories
Returns JFrog Artifactory Docker repositories accessible with the stored credentials for container scanning
# List JFrog Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/list-jfrog-container-registry-credentials
get /integrations/jfrog/container-registry/project/{projectId}/credentials
Returns all JFrog Artifactory Docker registry credentials for the project (sanitized, no secrets exposed)
# List tags for a Docker image in JFrog Artifactory
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/list-tags-for-a-docker-image-in-jfrog-artifactory
get /integrations/jfrog/container-registry/project/{projectId}/credentials/{credentialId}/images/{imageName}/tags
Returns available tags for a Docker container image stored in JFrog Artifactory for vulnerability scanning
# Start JFrog Artifactory container image scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/start-jfrog-artifactory-container-image-scan
post /integrations/jfrog/container-registry/project/{projectId}/scan
Starts a vulnerability scan for a Docker container image stored in JFrog Artifactory. Returns scan ID to track progress.
# Store JFrog Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/jfrog-container-registry/store-jfrog-container-registry-credentials
post /integrations/jfrog/container-registry/organization/{organizationId}/credentials
Stores JFrog Artifactory Docker registry credentials at organization level for container image scanning
# Delete Quay Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/delete-quay-container-registry-credentials
delete /integrations/quay/container-registry/organization/{organizationId}/credentials/{credentialId}
Deletes stored Quay.io / Red Hat Quay container registry credentials from the organization
# Get Quay Container Registry credential details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/get-quay-container-registry-credential-details
get /integrations/quay/container-registry/project/{projectId}/credentials/{credentialId}
Returns Quay.io / Red Hat Quay credential details (sanitized, secrets are masked)
# List container image tags from Quay registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/list-container-image-tags-from-quay-registry
get /integrations/quay/container-registry/project/{projectId}/images/{repositoryId}/tags
Lists all tags for a specific container image repository in Quay.io / Red Hat Quay registry
# List container images from Quay registry
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/list-container-images-from-quay-registry
get /integrations/quay/container-registry/project/{projectId}/images
Lists all container images (repositories) accessible via the stored Quay.io / Red Hat Quay credentials
# List Quay Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/list-quay-container-registry-credentials
get /integrations/quay/container-registry/project/{projectId}/credentials
Returns all Quay.io / Red Hat Quay container registry credentials available for the project (sanitized, secrets are masked)
# Start Quay Container Registry scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/start-quay-container-registry-scan
post /integrations/quay/container-registry/project/{projectId}/scan
Initiates an asynchronous container image vulnerability scan using stored Quay.io / Red Hat Quay credentials. The scan runs in the background and results can be retrieved via the scan status endpoint.
# Store Quay Container Registry credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/quay-container-registry/store-quay-container-registry-credentials
post /integrations/quay/container-registry/organization/{organizationId}/credentials
Stores Quay.io / Red Hat Quay robot account credentials at organization level for container image scanning
# Get dockerhubsearchimages
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/results-&-vulnerabilities/get-dockerhubsearchimages
get /dockerhub/search/images
# Delete Scaleway Credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/delete-scaleway-credentials
DELETE /integrations/scaleway/container-registry/organization/{organizationId}/credentials/{credentialId}
Delete stored Scaleway Container Registry credentials
## Path Parameters
The UUID of the organization
The UUID of the credential to delete
## Authorization
Requires `manage_integration` permission on the organization.
## Response
Returns `204 No Content` on success.
```
HTTP/1.1 204 No Content
```
Deleting credentials is permanent and cannot be undone. Any future scans using this credential will fail until new credentials are stored.
# Get Scaleway Credential Details
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/get-scaleway-credential-details
GET /integrations/scaleway/container-registry/project/{projectId}/credentials/{credentialId}
Get details of a specific Scaleway Container Registry credential
## Path Parameters
The UUID of the project
The UUID of the stored credential
## Authorization
Requires `read` permission on the project.
## Response
Whether the request succeeded
Credential UUID
Scaleway region
Scaleway namespace UUID
Namespace name
Registry endpoint URL
Credential description
ISO 8601 creation timestamp
ISO 8601 last update timestamp
```json theme={null}
{
"success": true,
"data": {
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"region": "fr-par",
"namespaceId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"namespaceName": "production-registry",
"registryEndpoint": "rg.fr-par.scw.cloud/production-registry",
"description": "Production registry",
"createdAt": "2026-03-17T10:30:00.000Z",
"updatedAt": "2026-03-17T10:30:00.000Z"
}
}
```
Secret keys are never returned in API responses. Credentials are stored with AES-256-GCM encryption at rest.
# List Scaleway Credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/list-scaleway-credentials
GET /integrations/scaleway/container-registry/project/{projectId}/credentials
List all Scaleway Container Registry credentials for a project
## Path Parameters
The UUID of the project
## Authorization
Requires `read` permission on the project.
## Response
Whether the request succeeded
Credential UUID
Scaleway region
Scaleway namespace UUID
Namespace name
Registry endpoint URL
Credential description
ISO 8601 creation timestamp
```json theme={null}
{
"success": true,
"data": {
"credentials": [
{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"region": "fr-par",
"namespaceId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"namespaceName": "production-registry",
"registryEndpoint": "rg.fr-par.scw.cloud/production-registry",
"description": "Production registry",
"createdAt": "2026-03-17T10:30:00.000Z"
}
]
}
}
```
# List Scaleway Image Tags
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/list-scaleway-image-tags
GET /integrations/scaleway/container-registry/project/{projectId}/credentials/{credentialId}/images/{imageId}/tags
List tags for a specific Docker image in Scaleway Container Registry
## Path Parameters
The UUID of the project
The UUID of the stored credential
The Scaleway image UUID
## Query Parameters
Page number (1-based). Default: `1`
Number of items per page. Default: `20`
## Authorization
Requires `read` permission on the project.
## Response
Whether the request succeeded
The image name
Scaleway tag UUID
Tag name (e.g., `latest`, `v1.0.0`)
Image digest (SHA256)
Tag size in bytes
Tag status
ISO 8601 creation timestamp
ISO 8601 last update timestamp
Total number of tags
Current page number
Items per page
```json theme={null}
{
"success": true,
"data": {
"imageName": "my-api",
"tags": [
{
"tagId": "d4e5f6a7-b8c9-0123-def0-234567890123",
"name": "v1.2.0",
"digest": "sha256:abc123...",
"size": 134217728,
"status": "ready",
"createdAt": "2026-03-15T09:00:00.000Z",
"updatedAt": "2026-03-15T09:00:00.000Z"
},
{
"tagId": "e5f6a7b8-c9d0-1234-ef01-345678901234",
"name": "latest",
"digest": "sha256:abc123...",
"size": 134217728,
"status": "ready",
"createdAt": "2026-03-15T09:00:00.000Z",
"updatedAt": "2026-03-15T09:00:00.000Z"
}
],
"totalCount": 5,
"page": 1,
"pageSize": 20
}
}
```
# List Scaleway Images
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/list-scaleway-images
GET /integrations/scaleway/container-registry/project/{projectId}/credentials/{credentialId}/images
List Docker images from a Scaleway Container Registry namespace
## Path Parameters
The UUID of the project
The UUID of the stored credential
## Query Parameters
Scaleway namespace UUID to list images from. Defaults to the namespace associated with the credential.
Page number (1-based). Default: `1`
Number of items per page. Default: `20`
## Authorization
Requires `read` permission on the project.
## Response
Whether the request succeeded
Scaleway image UUID
Image name
Namespace UUID the image belongs to
Number of tags for this image
Image size in bytes
Image visibility (`public` or `private`)
Image status
ISO 8601 creation timestamp
ISO 8601 last update timestamp
Total number of images
Current page number
Items per page
```json theme={null}
{
"success": true,
"data": {
"images": [
{
"imageId": "c3d4e5f6-a7b8-9012-cdef-123456789012",
"name": "my-api",
"namespaceId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"tagCount": 5,
"size": 268435456,
"visibility": "private",
"status": "ready",
"createdAt": "2026-02-10T14:00:00.000Z",
"updatedAt": "2026-03-15T09:00:00.000Z"
}
],
"totalCount": 12,
"page": 1,
"pageSize": 20
}
}
```
# List Scaleway Namespaces
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/list-scaleway-namespaces
GET /integrations/scaleway/container-registry/project/{projectId}/credentials/{credentialId}/namespaces
List container registry namespaces accessible with stored credentials
## Path Parameters
The UUID of the project
The UUID of the stored credential
## Query Parameters
Page number (1-based). Default: `1`
Number of items per page. Default: `20`
## Authorization
Requires `read` permission on the project.
## Response
Whether the request succeeded
Scaleway namespace UUID
Namespace name
Scaleway region
Registry endpoint URL
Number of images in the namespace
Total size in bytes
Namespace status (e.g., `ready`, `deleting`)
ISO 8601 creation timestamp
ISO 8601 last update timestamp
Total number of namespaces
Current page number
Items per page
```json theme={null}
{
"success": true,
"data": {
"namespaces": [
{
"id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"name": "production-registry",
"region": "fr-par",
"endpoint": "rg.fr-par.scw.cloud/production-registry",
"imageCount": 12,
"size": 5368709120,
"status": "ready",
"createdAt": "2026-01-15T08:00:00.000Z",
"updatedAt": "2026-03-17T10:30:00.000Z"
}
],
"totalCount": 1,
"page": 1,
"pageSize": 20
}
}
```
# Start Scaleway Container Scan
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/start-scaleway-container-scan
POST /integrations/scaleway/container-registry/project/{projectId}/scan
Start a container vulnerability scan for an image in Scaleway Container Registry
## Path Parameters
The UUID of the project
## Authorization
Requires `start_scan` permission on the project. The `container_scanning` feature must be enabled for your plan.
## Request Body
The UUID of the stored Scaleway credential to use for authentication
Full image name with tag (e.g., `my-api:v1.2.0` or `my-api:latest`)
Git branch name for tracking purposes
Whether the scan is private. Default: `false`
Filter results by severity levels (e.g., `["CRITICAL", "HIGH"]`). If omitted, all severities are returned.
```json theme={null}
{
"credentialId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"imageName": "my-api:v1.2.0",
"branch": "main",
"severities": ["CRITICAL", "HIGH", "MEDIUM"]
}
```
## Response
Whether the scan was started successfully
UUID of the created scan
Status message
Languages detected in the container image
```json theme={null}
{
"success": true,
"data": {
"scanId": "f6a7b8c9-d0e1-2345-f012-456789012345",
"message": "Container scan started successfully",
"detectedLanguages": ["javascript", "python"]
}
}
```
The scan runs asynchronously. Use the [Get Scan by ID](/latest/api-reference/endpoint/scan/get-a-scan-by-id) endpoint to check scan progress and retrieve results once completed.
Before scanning, CybeDefend validates that the specified image exists in the namespace associated with the credential. If the image is not found, the request will fail with a `404 Not Found` error.
# Store Scaleway Container Registry Credentials
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/scaleway-container-registry/store-scaleway-credentials
POST /integrations/scaleway/container-registry/organization/{organizationId}/credentials
Store Scaleway API credentials for container registry access
## Path Parameters
The UUID of the organization
## Authorization
Requires `manage_integration` permission on the organization.
## Request Body
The UUID of the CybeDefend project to associate the credentials with
Scaleway region where the container registry is hosted. One of: `fr-par`, `nl-ams`, `pl-waw`
The name of the Scaleway Container Registry namespace
Scaleway API secret key for authentication
Optional description to identify this credential
```json theme={null}
{
"projectId": "550e8400-e29b-41d4-a716-446655440001",
"region": "fr-par",
"namespaceName": "my-production-registry",
"secretKey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"description": "Production registry credentials"
}
```
## Response
Returns the stored credential details (secret key is **not** included in the response).
Whether the request succeeded
Credential UUID
Scaleway region
Resolved Scaleway namespace UUID
Namespace name
Registry endpoint URL (e.g., `rg.fr-par.scw.cloud/my-production-registry`)
Credential description
ISO 8601 creation timestamp
ISO 8601 last update timestamp
```json theme={null}
{
"success": true,
"data": {
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"region": "fr-par",
"namespaceId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"namespaceName": "my-production-registry",
"registryEndpoint": "rg.fr-par.scw.cloud/my-production-registry",
"description": "Production registry credentials",
"createdAt": "2026-03-17T10:30:00.000Z",
"updatedAt": "2026-03-17T10:30:00.000Z"
}
}
```
Credentials are validated against the Scaleway API before being stored. If the secret key is invalid or the namespace does not exist, the request will fail with a `400 Bad Request` error.
# Resolve enterprise SSO connectors by email domain
Source: https://docs.cybedefend.com/latest/api-reference/endpoint/sso/resolve-enterprise-sso-connectors-by-email-domain
get /auth/sso/connectors
Returns SSO connectors configured for the email domain. Used by the login page to bypass the SSO email screen.