Deckhouse Code adds integrations of its own for the tools behind its mandated security scans and for the system that collects their findings. A scanner integration holds what a scan job needs and a policy must not carry in a repository: the server address, the token, the certificate trust and the defaults for every scan of the project. The DefectDojo integration holds the connection to the server the security reports of a pipeline are sent to.
| Integration | What it serves | Configured on |
|---|---|---|
| “CodeScoring” | The codescoring scan | A project or a group |
| “Positive Technologies Application Inspector” | The ptai scan | A project or a group |
| “DefectDojo” | Every scan that publishes a security report | The instance, a group or a project |
A project or group integration is opened from “Settings” → “Integrations”. A group integration applies to every project below the group that has not set its own. Opengrep and Trivy, the scanners behind the SAST scan and the Trivy scan, have nothing to configure and are absent from these lists.
The scan itself is set in the scan execution policy: which modules run, what is scanned and what fails the pipeline. The policy editor offers the PT AI and CodeScoring scans only while an integration of that scanner is active for the project or for a group above it; the greyed-out choice links to the integration page. An integration’s variables reach every job of the pipeline; its secrets — tokens, passwords, cookies — reach only the scan job a policy mandated for that scanner. A variable the policy sets outranks the same variable from the integration. The policy editor and the options of the SAST scan are described on the SAST scanning page.
Opengrep
Opengrep is the scanner behind the mandated SAST scan, opengrep_sast. It is a command-line tool that runs inside the job: there is no server to reach, no token to hold and no certificate to trust. Everything about the scan belongs to the policy, including the image the scan runs in, so there is no integration to set up: “Opengrep” is absent from the “Integrations” lists, from the settings pages and from the REST API, and the scan jobs receive no variable from an integration record.
The image the scan runs in is resolved by the server while the job is rendered and written into the job as a literal value. The server takes:
- the reference in the “Scanner image” field of the
opengrep_sastaction, when the policy names one; - otherwise the image named in the instance environment variable
FE_SCANS_OPENGREP_IMAGE; - otherwise the image this release pins,
opengrep-scan:1.30.0-fe2from the product registry.
The image never becomes a CI/CD variable, so the scanned project’s own settings cannot point the scan at another scanner. The “Scanner image” field of the policy shows the image an empty field runs, and the hint beside it names the Opengrep version and the rule set that ship with this product.
The rules, the rule levels, the subjects left out, the blocking threshold, the ignored paths and the additional arguments are the “Rules”, “Rule levels”, “Subjects to leave out”, “Blocking threshold”, “Ignored paths” and “Additional arguments” groups of the same action. The scan, its jobs and these groups are described on the SAST scanning page.
Trivy
Trivy is the scanner behind the mandated trivy scan. It runs inside the job and reaches no server of its own, so there is no integration to set up: “Trivy” is absent from the “Integrations” lists, from the settings pages and from the REST API, and the scan jobs receive no variable from an integration record.
Everything about the scan belongs to the policy: the modules it runs, their options and the image it runs in. The server writes the image into the job while the job is rendered: the reference in the “Scan image” field of the trivy action, or, when the policy names none, the image this release pins, trivy-with-db:0.74.0 from the product registry. The container module reads registry credentials from the CI/CD variables of the scanned project.
The scan, its modules and their options are described on the Scanning with Trivy page.
CodeScoring
The full setup, the SCA and Secrets modules and the troubleshooting of this integration are on the CodeScoring integration page.
The CodeScoring integration connects a project to a CodeScoring server and delivers the johnny agent to the jobs of the codescoring scan. The scan has two modules, each turned on in the policy: composition analysis, which the codescoring_sca job runs and which publishes the dependency scanning report, the code quality report, the test report and the CycloneDX SBOM gl-sbom.cdx.json; and the secret search, which the codescoring_secrets_gitleaks, codescoring_secrets_trufflehog and codescoring_secrets_kingfisher jobs run, one per engine, and which publishes a secret detection report. The findings reach the vulnerability report, the dependency list and DefectDojo like those of every other scanner; the SBOM is what the Dependency list and license compliance pages read.
The integration is configured on a project or a group, in “Settings” → “Integrations” → “CodeScoring”. The policy editor offers the codescoring scan while the integration is active for the project or a group above it. The form holds the connection, the trust and the defaults of the scan jobs; what the agent scans and how is set in the policy:
| Field | Content |
|---|---|
| “Server URL” | Base URL of the CodeScoring server, for example https://codescoring.example.com. Required. Section “Connection”. |
| “API token” | Token the jobs authenticate with and download the johnny agent by. Required. Section “Connection”. |
| “Scan stage” | The policy stage the scan reports as on the server: build, dev, source, stage, test or prod. Default: build. The agent takes one stage, so the scan reports as one. Section “Connection”. |
| “Certificate trust” | How the scan job decides whether to trust the server: “Trust what the job already trusts” (default), “Trust the certificate authority below”, “Do not verify the certificate”. The setting applies to the requests the job makes with curl — downloading the agent — and to the connection test; the johnny agent verifies no certificate and offers no way to make it. Section “Certificate trust”. |
| “Certificate authority” | PEM certificate of the authority that signed the server’s certificate. Read only with “Trust the certificate authority below”, and required then. Section “Certificate trust”. |
| “Scan job image” | Image the CodeScoring scan jobs run in, with registry and tag or digest. It needs curl, ca-certificates, jq, ruby and git; the agent is downloaded into it at run time. Empty: codescoring-scan:2026.08.30 from the product registry, the image this release ships. Section “Scan jobs”. |
| “SBOM format” | CycloneDX version the SBOM is written in: cyclonedx_v1_4_json, cyclonedx_v1_5_json, cyclonedx_v1_6_json, cyclonedx_v1_6_ext_json (CodeScoring’s extension of 1.6 with its GOST properties) or cyclonedx_v1_7_json. Every version lists the same components. Empty here and in the policy: CycloneDX 1.6 JSON. Section “Scan jobs”. |
“Test settings” asks the server for the agent version with the token and the trust setting of the form, so the address, the token and the certificate are checked at once.
The jobs receive FE_SCANS_CODESCORING_URL, FE_SCANS_CODESCORING_TLS_MODE and, with an authority named, FE_SCANS_CODESCORING_CA_CERT; FE_SCANS_CODESCORING_SCAN_STAGE and FE_SCANS_CODESCORING_BOM_FORMAT when the fields are filled in. FE_SCANS_CODESCORING_TOKEN is masked and reaches the mandated CodeScoring jobs only. Every job downloads the agent from the server on each run, so the agent version is the one the server publishes. The composition analysis reports into the CodeScoring project named after the project path slug and creates it when it is missing.
“Scan job image” is read while the job is rendered and written into the job as a literal value; only the integration on a group that mandates the scan — the group the policy is linked to, or a group above it — names the image, and a value on the scanned project’s own integration is ignored. “Scan stage” and “SBOM format” are project-wide defaults: a policy that names its own value wins, and the policy’s “SBOM format” list carries “Take it from the integration” to hand the decision back.
The policy’s “SCA” group sets the scan mode and target, the ignored paths, whether the dependency tree is resolved on the server, the stage, the SBOM format and extra agent arguments; the “Secrets” group picks the engines — gitleaks, trufflehog, kingfisher — and gives each a configuration and an ignore list.
PT AI
The “Positive Technologies Application Inspector” integration serves the ptai scan. Its job, ptai_scan, uploads the sources of the commit to a PT AI server, where the project is created after the project name and the branch after the branch name when they are missing, and publishes a test report and a SAST security report, so the findings reach the vulnerability report and DefectDojo. White box and black box are two modules of one scan: the job uploads the sources whatever else is set, and a website address turns the black box on in the same run.
The integration is configured on a project or a group, in “Settings” → “Integrations” → “Positive Technologies Application Inspector”. The policy editor offers the ptai scan while the integration is active for the project or a group above it. Everything past the connection reaches the agent through a settings file the job writes, so the form offers what the agent accepts and no more; with none of the scan and black box fields set, the scan runs on the settings the server already holds for the project.
| Field | Content |
|---|---|
| “Server URL” | Base URL of the PT Application Inspector server, for example https://ptai.example.com. Required. Section “Connection”. |
| “API token” | Token the job authenticates with. Required. Section “Connection”. |
| “Certificate trust” | How the scan job decides whether to trust the server: “Trust what the job already trusts” (default) or “Trust the certificate authority below”. The agent has no way to skip verification, so that choice is absent. Section “Certificate trust”. |
| “Certificate authority” | PEM certificate of the authority that signed the server’s certificate. Read only with “Trust the certificate authority below”, and required then. Section “Certificate trust”. |
| “Scan modules” | Modules of the white box, comma-separated, as PT AI names them: Configuration, Components, BlackBox, PatternMatching, StaticCodeAnalysis, SoftwareCompositionAnalysis, SecretDetection, MaliciousCodeDetection. Empty: Configuration, PatternMatching, StaticCodeAnalysis. BlackBox is added on its own once a website address is set. Section “Scan”. |
| “Programming languages” | Languages of the project, one per line, as PT AI names them: Java, CSharp (Windows, Linux), CSharp (Windows), Php, JavaScript, Python, ObjectiveC, Swift, CAndCPlusPlus, Go, Kotlin, Sql, Ruby, Solidity, Scala, OneC, Dart. Required once anything else in “Scan” or in the black box sections is set, unless “Settings file” is named. Section “Scan”. |
| “Apply the security policy” | Checks the result against the policy held on the server; the agent then exits with a non-zero code when the policy is broken, and the job fails. Section “Scan”. |
| “Skip files listed in .gitignore” | Keeps build output and vendored trees out of the upload. Section “Scan”. |
| “Apply all pattern-matching rules” | Runs every pattern-matching rule the server holds, and the rules the project’s languages select. Section “Scan”. |
| “Do not download dependencies” | Stops the analysis kernels fetching the project’s packages before they read the code. Set it where the server cannot reach the package registries: there the fetch fails the whole scan, and no report is written. Section “Scan”. |
| “Settings file” | Path in the repository to a project settings file written by hand, for example .ptai/settings.json. It is used as it is, and every other field of the “Scan” and black box sections is ignored. Section “Scan”. |
| “Website address” | Address of the running application the black box scans, for example https://staging.example.com; a private address is accepted. Setting it turns the black box on. Section “Black box”. |
| “Search mode” | How thoroughly the site is explored: None, Fast, Normal, Full. Default: Normal. Section “Black box”. |
| “Scan scope” | How far from the address the scan may go: Domain, Folder, Path. Default: Path. Section “Black box”. |
| “Verify the site certificate” | Off for a site with a self-signed certificate. Section “Black box”. |
| “Run autocheck after the scan” | Tries what the static analysis found against the running site and reports which of it is reachable. Section “Black box”. |
| “Additional HTTP headers” | One per line, as Name: value. Section “Black box”. |
| “Allowed addresses”, “Blocked addresses” | One per line. A pattern by default; address|ExactMatch and address|RegExp name the other two forms. The blocked list is where a sign-out link goes. Section “Black box”. |
| “Authentication” | How the black box signs in: “No authentication”, “Sign-in form”, “HTTP Basic”, “Cookie”. Section “Black box: authentication”. |
| “User”, “Password” | Credentials for the sign-in form and HTTP Basic. Section “Black box: authentication”. |
| “Cookie” | The session cookie to present, for cookie authentication. Section “Black box: authentication”. |
| “Validation address”, “Validation template” | A page only a signed-in user reaches, and text that appears on it when signed in; the scan asks for the page to find out whether it is still signed in. Section “Black box: authentication”. |
| “Sign-in form URL”, “Form detection”, “Sign-in form XPath”, “User field name”, “Password field name” | The sign-in form: its address; whether it is found on its own (Auto, the default) or described by hand (Manual); and, for a form described by hand, its XPath and the names of the user and password fields. Section “Black box: authentication”. |
| “Proxy address”, “Proxy port”, “Proxy type”, “Proxy user”, “Proxy password” | The proxy the black box reaches the site through. An address turns the proxy on; the port is a number from 1 to 65535; the type is Http, Socks4 or Socks5. Section “Black box: proxy”. |
The form refuses a module or a language PT AI does not know and names the entries it refused.
The job receives FE_SCANS_PTAI_SERVER_URL, FE_SCANS_PTAI_TLS_MODE and, with an authority named, FE_SCANS_PTAI_CA_CERT, and every filled-in option as FE_SCANS_PTAI_<FIELD>: FE_SCANS_PTAI_MODULES, FE_SCANS_PTAI_LANGUAGES, FE_SCANS_PTAI_BLACKBOX_SITE and so on. FE_SCANS_PTAI_TOKEN, FE_SCANS_PTAI_BLACKBOX_AUTH_PASSWORD, FE_SCANS_PTAI_BLACKBOX_AUTH_COOKIE and FE_SCANS_PTAI_BLACKBOX_PROXY_PASSWORD are masked and reach the mandated ptai_scan job only. The policy editor offers the same options in its “Scan”, “Black box”, “Black box: authentication”, “Black box: proxy” and “Certificate trust” groups, without the token, the passwords and the cookie: those stay in the integration.
The image the job runs in is not a field of the integration. It comes from the FE_SCANS_PTAI_IMAGE variable of the ptai action, $CI_REGISTRY/infra/ci-images/aisa:latest by default: an image carrying the aisa agent that the installation builds and publishes in its own container registry. Another registry is named in the variables of the action in the policy; a CI/CD variable of the project does not apply. On an installation whose container registry is switched off, a policy with a ptai action is refused on save until the action names FE_SCANS_PTAI_IMAGE.
DefectDojo
The full setup, the entity mapping and the troubleshooting of this integration are on the DefectDojo integration page.
The DefectDojo integration sends the security reports of a pipeline to a DefectDojo server. The reports go as the jobs published them, in the native report formats, through the server’s reimport endpoint:
| Report type of the artifact | Scan type in DefectDojo |
|---|---|
sast | GitLab SAST Report |
secret_detection | GitLab Secret Detection Report |
dependency_scanning | GitLab Dependency Scanning Report |
container_scanning | GitLab Container Scan |
dast | GitLab DAST Report |
The mandated scans publish these types — Opengrep and PT AI a sast report, Trivy dependency_scanning, secret_detection and container_scanning, CodeScoring dependency_scanning and secret_detection — and a job of the project’s own .gitlab-ci.yml that publishes one is uploaded the same way.
The integration is configured on a project or a group in “Settings” → “Integrations” → “DefectDojo”, and for the whole instance in “Admin” → “Settings” → “Integrations” → “DefectDojo”. Its “Import defaults” are the mapping every upload uses:
| Field | Content |
|---|---|
| “DefectDojo URL” | Base URL of the DefectDojo server, for example https://defectdojo.example.com. Required. Section “Connection”. |
| “API token” | Token the uploads authenticate with. Required. Section “Connection”. |
| “Certificate trust” | How this instance decides whether to trust the server: “Trust what this instance already trusts” (default), “Trust the certificate authority below”, “Do not verify the certificate”. The connection is made from the instance, so verification can be switched off; the upload is then open to interception, and the reports carry everything the scanners found. Section “Certificate trust”. |
| “Certificate authority” | PEM certificate of the authority that signed the server’s certificate. Read only with “Trust the certificate authority below”, and required then. Section “Certificate trust”. |
| “Product name” | The DefectDojo product the reports go into. Empty: the full path of the project. Section “Import defaults”. |
| “Product type name” | The product type a product is created in when it is missing. Section “Import defaults”. |
| “Engagement name” | The engagement the reports go into. Empty: the branch or tag the pipeline ran on. Section “Import defaults”. |
| “Minimum severity” | Findings below it are left out of the import: Info (default), Low, Medium, High, Critical. Section “Import defaults”. |
| “Auto-create context” | “Create the product and engagement if they do not exist”. On by default. Section “Import defaults”. |
| “Imported findings” | “Mark imported findings as active”. On by default. Section “Import defaults”. |
| “Verified findings” | “Mark imported findings as verified”. Off by default. Section “Import defaults”. |
| “Close old findings” | “Close findings that are no longer reported”. On by default. Section “Import defaults”. |
Saving a form with settings of its own asks the server whether the mapping can be used: a rejected token, a missing product while “Auto-create context” is off, a missing product type while it is on, and a missing engagement while it is off are each refused with a message naming the product or the engagement. A server that cannot be asked does not block the save. “Test settings”, offered on a project integration, asks the same questions and reports a server that cannot be asked as well.
An upload starts when a job that published one of the report types above finishes in a project with an active DefectDojo integration, its own or inherited. One upload runs per pipeline; a further job finishing in the same pipeline reruns it once. Every report of the latest run of each job goes into the product and engagement of the form, into a test named after the job, dated by the day the job finished, so a rerun of a scan updates the same test, and its findings are not filed twice. The commit, the branch, the pipeline number, the short commit as the version and the project address are written onto the engagement. A report of a scan that did not run — a placeholder the job published so that the pipeline widgets show something — is not imported, because “Close old findings” would otherwise close every finding of the last real scan.
A server answer of 429 or 5xx and a timeout are retried after 60, 120 and 240 seconds; an upload waits up to 600 seconds for one report. Any other refusal is final, and only the project can act on it: the pipeline page shows the alert “Security report upload warnings” with one line per report that did not reach the server:
DefectDojo did not receive the report of job "opengrep_sast_junit" (GitLab SAST Report): DefectDojo returned HTTP 400: Product "group/project" does not exist and no product_type_name provided to create the new product inThe reason is the server’s own message, up to 500 characters, or one of blocked URL: … for an address the instance is not allowed to reach, certificate authority: … for a certificate that could not be read, and the scan did not run, so its placeholder report was not imported. Once the retries are spent, the page shows one more line: DefectDojo upload of this pipeline's security reports failed and the retries are spent: …. A line about a report is removed when a later run delivers that report. The full answer of the server is in the application log.