Skip to content

Add a new CI template to enable Dependency Scanning using SBOM by default

Problem to solve

As part of Dependency Scanning: full scan on SBOM changes ... (&15961) we need an enablement solution that uses the new DS analyer by default rather than an opt-in approach.

This can't be achieved using the current stable edition of the Dependency-Scanning CI template without breaking existing users' CI configuration and we can't migrate these automatically. Additionally we can't yet use CI/CD components as our primary enablement solution due to its current limitations and UX in self-managed and offline deployments.

Proposal

As suggested in Add versioning and spec:inputs to AST CI/CD tem... (#523986) we can add versioning to our current CI template to allow us to deliver breaking changes without impacting existing customers. This way, new customers can start using the new feature by default and existing customers can migrate to the newer version of the template at their own pace.

This issue mainly serves as a placeholder in the DS GA epic but most of the work will likely happen in Add versioning and spec:inputs to AST CI/CD tem... (#523986), which is set as a blocker.

SEP Compatibility Implementation

In order to make Scan Execution Policy transition smooth, we will accept variables needed for the dependency-scanning job in the latest template as a fallback.

The following variable support will be needed.

  • DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN
  • DS_MAX_DEPTH
  • DS_EXCLUDED_PATHS
  • DS_INCLUDE_DEV_DEPENDENCIES
  • DS_STATIC_REACHABILITY_ENABLED
  • SECURE_LOG_LEVEL

This ensures:

  • SEP can continue using CI/CD variables without changes
  • Direct template usage can use modern spec:inputs
  • Variable precedence: CI/CD variables > inputs > defaults

Note: Initial version looked at using this structure for backwards compatibility with v1 variables:

variables:
  SECURE_LOG_LEVEL: "${SECURE_LOG_LEVEL:-$[[ inputs.secure_log_level]]}"
  DS_MAX_DEPTH: "${DS_MAX_DEPTH:-$[[ inputs.max_depth ]]}"
  # ... other variables with same pattern

This was not possible because of the different ways in which variables and inputs are expanded.

File existence checks

v1 of the Dependency Scanning template uses file existence checks to decide whether the DS job runs. This is removed in v2. If DS is included it will show up in the pipeline regarding of whether a supported file exists.

Feature enabled checks

v1 of the Dependency Scanning template checks whether Dependency Scanning feature is available in the project. This check is moved from the template to the analyzer. With v2 if a user includes the Dependency Scanning job but doesn't have the feature available, the pipeline will get a failing DS job indicating this rather than not appearing at all.

Artifacts supported

In addition to the sbom report, v2 will also export a dependency scanning report in support of on-demand scanning.

Intended users

Users will be both developers adding Dependency Scanning to a project's CI config and AppSec members adding support via Scan Execution Policies.

Feature Usage Metrics

TBC

Does this feature require an audit event?

No

Implementation plan

Create new template under Jobs

  • Use current DS job as template
  • Use singular dependency-scanning job with spec:inputs section
  • Convert variables to spec inputs with SEP fallback mechanism
  • Named as existing but v2 (Dependency-Scanning.v2.gitlab-ci.yml)

Availability & testing

Unit tests

  • Template parsing and validation
  • Input parameter handling and defaults
  • Variable fallback mechanism and precedence
  • Rules evaluation for MR pipelines

Acceptance tests

v1 vs v2 Comparison Testing:

  • SEP Integration (Enhanced):
    • Current v1: Works with variables only (DS_EXCLUDED_PATHS: "node_modules/")
    • New v2: Works with both variables (SEP) AND inputs (direct usage)
    • Test Cases:
      • SEP policy with variables → verify fallback works
      • Direct template with inputs → verify modern approach works
      • Mixed usage → verify precedence (variables > inputs > defaults)
      • Variable override testing in policy context
  • PEP Integration (Maintained):
    • Push Event Policies compatibility maintained
    • Same variable support as v1 template
  • Language Coverage:
    • v2 Testing: Single unified analyzer handles all languages

Migration Path Testing:

  • Side-by-side Comparison: v1 and v2 results on same codebase
  • Report Format Evolution: JSON schema evolution handling
  • Configuration Migration: Variable → Input mapping validation
  • Performance Comparison: Scan time v1 vs v2
Edited by Igor Frenkel