The CloudBees platform performs an implicit security analysis, automatically triggering scans on code assets when you create a component, or when you commit changes to a linked repository. It also automatically triggers scans on binary assets whenever a workflow runs successfully with the upload artifact build step.
Findings from security scans are displayed in the Component security center and in the components security summary.
Implicit code security assessment
To enable implicit code security analysis:
-
Select an organization. Optionally, select a component.
-
Select .
-
Toggle Implicit security assessment to active.
-
Activate one or more code security tools, such as Checkov or Gosec. The following code security tools are currently available in the CloudBees platform:
Code security scanners
For Coverity on Polaris, findings redirection to the exact line of code is not supported. CloudBees platform redirects to the file containing the issue, but does not highlight the line number, because this is not supported by the Coverity tool itself.
Security tool Description Supported languages Explicit or implicit Scan type Installation type Black Duck SCA
Scans open-source dependencies for known vulnerabilities and license risks.
Explicit
Code
Both single and multi tenant
Checkov
Scans cloud infrastructure configurations, including Terraform and Cloud Formation scripts.
Implicit
Code
Both single and multi tenant
Coverity on Polaris
Enterprise-grade static analysis for code security and quality.
Explicit
Code
Both single and multi tenant
Gitleaks
Scans Git repositories for sensitive content, such as credentials.
N/A (language agnostic)
Implicit
Code
Both single and multi tenant
Gosec
An open source Golang security scanner.
Implicit
Code
Both single and multi tenant
Njsscan
An open source Node.js security scanner.
Implicit
Code
Both single and multi tenant
SCC Scanner
An application software language analyzer. SCC Scanner is enabled on the CloudBees platform by default.
Implicit
Code
Single-tenant
SonarQube
Detects bugs, code smells, and security vulnerabilities across multiple languages.
-
C#
-
Go
-
Java
-
JavaScript
-
PHP
-
Python
-
Ruby
Explicit
Code
Both single and multi tenant
-
Once enabled, an implicit security scan is triggered automatically when you perform the following actions:
-
Create a component.
-
Commit a change, or create a branch, in any repository linked to a component.
Implicit code security assessment currently supports four source code management integrations: GitHub, Bitbucket Cloud, Bitbucket Data Center, and Gerrit.
Binary security analysis
The CloudBees platform also performs binary security analysis. It uses CloudBees platform workflows, and triggers a binary scanner such as Trivy or FindSecBugs whenever a configured workflow is invoked. The following binary security tools are currently available on the CloudBees platform:
Binary security scanners
| Security tool | Description | Supported languages | Explicit or implicit | Scan type | Installation type |
|---|---|---|---|---|---|
FindSecBugs |
An open source Java security scanner. Used in CloudBees to scan binary |
Implicit |
Binary |
Both single and multi tenant |
|
Grype |
A vulnerability scanner for container images, SBOMs, and file systems. |
Implicit |
Binary |
Both single and multi tenant |
|
Syft SBOM |
Generates software bills of materials (SBOMs) from containers and binaries. |
Implicit |
Binary |
Both single and multi tenant |
|
Trivy |
A Docker image scanner that supports OS packages and language-specific dependencies. |
Implicit |
Binary |
Both single and multi tenant |
| At this time, only a single binary scan per workflow can be performed. Triggering additional scans will override the results of the previous scan. |
Implicit ECR binary security analysis
CloudBees platform can be integrated with AWS Elastic Container Registry (ECR). Once the integration is configured, binary scans are triggered automatically whenever a workflow builds and pushes an image to ECR using a supported CloudBees action.
To set up implicit ECR binary security analysis, you must first create an AWS ECR integration. Once the integration is created, binary scans are triggered in the following ways:
-
Build and push with Kaniko: If the workflow uses the
cloudbees-io/kaniko@v1action and thedestinationis an ECR repository, a scan is triggered automatically after the build completes. No additional steps are required. For example:- id: build-container name: Build container image uses: cloudbees-io/kaniko@v1 kind: build with: destination: <your-account>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag> tar-path: container-image.tar build-args: USER=cbp,TOKEN=${{ secrets.GH_SECURITY_PAT }}For further information, refer to CloudBees action: Build and publish Docker images with Kaniko.
-
Register an ECR artifact: If the workflow produces an artifact and registers it with the
cloudbees-io/register-build-artifact@v2action, a scan is automatically triggered as long as the artifact’sdestinationis an ECR location.
Explicit binary upload (optional)
In addition to implicit scans triggered by Kaniko or artifact registration, a workflow can be configured to upload a binary file directly. This is useful when:
-
Scanning images that are not stored in ECR (for example, public images).
-
Scanning non-container binaries such as
.jarexecutables. -
Triggering the scan explicitly rather than rely on implicit ECR integration.
To trigger a binary security analysis of a file produced by a workflow, add the following to the workflow:
- id: upload-binary name: Upload binary using action uses: https://github.com/cloudbees-io/asset-chain-utils/upload-binary@v1 with: file-path: directory/subdirectory/container-image.tar(1) file-type: BINARY_CONTAINER(2)
| 1 | Replace the contents of file-path with the path to your binary file.
The path is relative to the CloudBees workspace.
file-path must always point to a file. |
| 2 | Two file types are supported:
|
Once added to your workflow, every time you upload a binary file to the specified path, upload-binary triggers a secondary workflow which scans the file.
It will also, if enabled, create a Software bill of materials (SBOM).
|
On very large repositories, scans can take longer than six hours. In standard workflows, the maximum time allowed is three hours, after which the job is terminated even if the scan is not complete. If the scan exceeds this limit, the job is terminated before it finishes. Currently, the only mitigation is to reduce repository size so the scan completes within the allowed time. |
Scan findings sit alongside the code security analysis results in the Component security center, attributed to a component branch.
| Binary findings in the security center only relate to the last produced binary. Unlike the code asset profile for a component or branch, which is retained over time and updated with the latest results, each produced binary becomes a separate asset profile with its own set of findings, so only the latest is important. |
Performance and resource considerations
When running implicit security analysis on large repositories, be aware of workflow time limits and memory constraints.
| Consideration | Description | Mitigation |
|---|---|---|
Workflow time limit (standard workflows) |
On very large repositories, scans can take longer than six hours. Currently, in standard workflows the maximum time allowed is three hours, after which the job is terminated even if the scan is not complete. |
Reduce repository size so the scan completes within the allowed time. |
Ephemeral container memory |
If memory use exceeds the container’s allocated memory, the job may be terminated. This is more likely with large repositories, where analysis loads substantial data in memory. |
Increase container memory allocation in your CI/CD platform, select a larger runner size, or adjust Kubernetes/Docker memory limits. |
Platform variability |
Timeouts and memory limits depend on your environment, for example, GitHub Actions, GitLab CI, or Kubernetes. |
Refer to your platform’s documentation for adjusting timeouts and container resources. |