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.

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 ECR integration for automatic scanning

CloudBees Unify integrates with AWS Elastic Container Registry (ECR) to trigger binary scans automatically when workflows build and push container images.

Prerequisites:

Create an AWS ECR integration.

ECR binary scans trigger automatically in the following scenarios:

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.

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.

Handle performance and resource considerations

When configuring implicit security analysis for large repositories, consider workflow time limits and memory constraints that may affect scan completion.

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.

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.