Configure implicit security analysis

Configure implicit security analysis to automatically trigger security scans when code or binary assets change, without requiring explicit workflow configuration. Implicit analysis operates transparently within existing development workflows, ensuring comprehensive security coverage while maintaining development velocity.

Implicit security analysis triggers automatically when developers create components, commit changes, or build artifacts, eliminating the need for manual security tool invocation while ensuring consistent security coverage across all development activities.

For conceptual information about implicit security analysis, refer to Understanding application security posture management.

You need organization Admin permissions to enable implicit security assessment and activate security tools. For permission details, refer to RBAC permissions reference.

Enable implicit security assessment

Enable implicit security assessment at the organization level to activate automatic security analysis across all components and workflows.

To enable implicit security assessment:

Select an organization from the organization selector.
Select Security Marketplace.
Toggle Implicit security assessment to active.

Once enabled, implicit security analysis triggers automatically for both code and binary assets based on development activities.

Disabling implicit security assessment turns off automatic security analysis for all components associated with the selected organization and its child organizations. For organization hierarchy behavior, refer to application-security:explanation/understanding-application-security-posture-management.adoc#organizational-hierarchy-inheritance.

Performance and resource considerations

When running implicit security assessment on large repositories, be aware of workflow time limits and memory constraints.

Consideration	Description	Mitigation
Workflow time limits	Large repositories may require scan times exceeding standard workflow limits (typically 3 hours).	Reduce repository size, optimize scan configuration, or request extended timeout limits for your environment.
Container memory	Security analysis tools may exceed allocated container memory when processing large codebases or binary artifacts.	Increase container memory allocation, select larger runner sizes, or configure memory limits appropriately for your platform.
Platform variability	Timeout and memory limits vary across CI/CD platforms (GitHub Actions, GitLab CI, Kubernetes).	Consult your platform documentation for adjusting resource limits and timeout configurations.

Consideration

Description

Mitigation

Workflow time limits

Large repositories may require scan times exceeding standard workflow limits (typically 3 hours).

Reduce repository size, optimize scan configuration, or request extended timeout limits for your environment.

Container memory

Security analysis tools may exceed allocated container memory when processing large codebases or binary artifacts.

Increase container memory allocation, select larger runner sizes, or configure memory limits appropriately for your platform.

Platform variability

Timeout and memory limits vary across CI/CD platforms (GitHub Actions, GitLab CI, Kubernetes).

Consult your platform documentation for adjusting resource limits and timeout configurations.

If scans exceed time limits, jobs terminate before completion, resulting in incomplete security analysis. Monitor scan performance and adjust resource allocation as needed.

Configure code security analysis triggers

Code security analysis automatically triggers when developers create components or make repository changes, providing immediate feedback on security issues without disrupting development workflows.

To configure code security analysis:

From the Marketplace, ensure Implicit security assessment is enabled.
Activate one or more code security tools:
- Select tools appropriate for your technology stack (such as Checkov, Gosec, or SonarQube).
- Configure tool-specific settings if required. For tool configuration details, refer to Configure security tools.

Code security analysis triggers automatically when you:

Create a component.
Commit changes to any repository linked to a component.
Create branches in repositories linked to components.

Implicit code security assessment currently supports GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center, and Gerrit source code management integrations.

Findings from code security analysis appear in the component security center and in the component’s security summary.

Configure binary security analysis

Binary security analysis automatically triggers when workflows produce artifacts, scanning container images and executable files for vulnerabilities and compliance issues.

To configure binary security analysis:

From the Marketplace, ensure Implicit security assessment is enabled.
Activate binary security tools appropriate for your artifact types:
- Container scanning tools, such as Trivy or Grype, for container images.
- Static analysis tools for executable artifacts.

Currently, only a single binary scan per workflow can be performed. Triggering additional scans will override the results of the previous scan.

Binary security analysis uses workflows and triggers automatically when configured workflows complete successfully with artifact publication steps.

Configure Implicit ECR binary security analysis

CloudBees Unify can be integrated with AWS Elastic Container Registry (ECR). CloudBees platform can be integrated with AWS Elastic Container Registry (ECR). After the integration is configured, binary scans are triggered automatically whenever a supported CloudBees workflow builds and pushes a container image to ECR using a supported CloudBees action.

Unify workflow: When a Unify workflow publishes a container image to Amazon ECR, a binary scan is triggered automatically. The scan results are displayed in the component-level security dashboards, including Security Overview and Security Center. After the container image is deployed to an application environment, the scan results are also available in the application-level Security Overview and Security Center dashboards.

id: register-artifact
name: Register the artifact
uses: cloudbees-io/register-build-artifact@v2
with:
name: qa-go-repo
version: 0.1
url: <ECR_Location>▼

The following CI/CD platforms support implicit ECR binary security analysis:

GitHub Actions, using the register-build-artifact action.
CloudBees CI (CBCI), using the "Registering build artifact" stage.
Jenkins OSS, using the "Registering build artifact" stage.

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:

GitHub Actions with register-build-artifact: When a GitHub Actions workflow publishes a binary image to ECR using the register-build-artifact action, a binary scan is triggered automatically after the publish operation succeeds. No additional configuration is required. The scan results appear in the component-level security dashboards (Security Overview and Security Center), and when the artifact is deployed to an application environment, the results are also reflected in the application-level dashboards (Security Overview and Security Center).
CloudBees CI (CBCI): When a CloudBees-managed Jenkins pipeline publishes a binary image to ECR using the "Registering build artifact" stage, a binary scan is triggered automatically. The artifact is automatically linked to its source commit and branch for traceability. Scan results appear in component dashboards and are updated in application dashboards upon deployment.
Jenkins OSS: When a Jenkins open source pipeline publishes a binary image to ECR using the "Registering build artifact" stage, a binary scan is triggered automatically. The artifact is enriched with source metadata (commit SHA and branch when available) to enable reliable linking between code and binary profiles. Scan results appear in component dashboards and are updated in application dashboards upon deployment.

Build and push with Kaniko: When workflows use the cloudbees-io/kaniko@v1 action with an ECR destination, scans trigger automatically after successful builds. No additional configuration is required.

Example workflow configuration:

- 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▼

For complete Kaniko configuration, refer to Build and publish container images.

Register ECR artifacts: When workflows register artifacts with the cloudbees-io/register-build-artifact@v2 action using ECR destinations, scans trigger automatically.

Configure explicit binary upload

Configure explicit binary upload for scenarios where automatic ECR integration is not suitable, such as scanning public images or non-container binaries.

Use explicit binary upload when:

Scanning images not stored in ECR.
Scanning non-container binaries such as .jar executables.
Requiring explicit scan triggering rather than implicit integration.

To configure explicit binary upload, add the following step to your workflow:

- id: upload-binary
  name: Upload binary for security scanning
  uses: cloudbees-io/asset-chain-utils/upload-binary@v1
  with:
    file-path: path/to/your-binary-file.tar
    file-type: BINARY_CONTAINER▼

Supported file types:

BINARY_CONTAINER: Container image files.
BINARY_JAR: Java executable files.

The file-path must point to a file relative to the CloudBees workspace directory.

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 Configure SBOM analysis.

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.

Binary scan findings appear in the component security center attributed to the component branch.

Binary findings relate only to the most recently produced binary. Each produced binary becomes a separate asset profile with its own findings set.

Manage security tool inheritance

Security tool configuration follows organizational hierarchy patterns, enabling centralized governance with local flexibility. Understanding inheritance behavior helps you plan effective security coverage across complex organizational environments.

Organization-level tool activation:

Root organization changes affect all child organizations.
Child organization changes create override records that prevent parent changes from affecting that organization.

For example:

Enable a security tool for the root organization → enables for all child organizations.
Disable the tool for Child Organization 1 → also disables for Child Organization 3 (if it inherits from Child Organization 1).
Activate a different tool for Child Organization 1 → activates for Child Organization 3, unless Child Organization 3 has override records.

Deactivating a security tool for the root organization disables it for all child organizations, regardless of override records.

For detailed inheritance behavior, refer to application-security:explanation/understanding-application-security-posture-management.adoc#organizational-hierarchy-inheritance.

Troubleshoot common scanning issues

Address common issues that may prevent implicit security analysis from completing successfully.

Scan timeouts: If scans consistently timeout, reduce repository size by excluding unnecessary files from security analysis or splitting large repositories into smaller components.

Memory exhaustion: If containers run out of memory during analysis, increase memory allocation for your workflow runners or select instance types with more available memory.

Missing findings: If expected security findings don’t appear, verify that:

Implicit security assessment is enabled for the organization.
Appropriate security tools are activated for your asset types.
Repository integrations are configured correctly for code analysis.
Workflow configurations include proper artifact registration for binary analysis.

For additional troubleshooting guidance, refer to Configure security tools.