Dependency Scanning with V2 template always trigger the CI job, even on unsupported projects
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
When delivering the v2 of the Dependency Scanning CI template, we purposely removed the rules:exists that condition the job execution to the presence of specific files in the repository.
This means the DS CI job now always run as soon as the v2 template is included.
This is problematic for customers who enable the features at scale using Scan Execution Policies and now have failing DS jobs on many unsupported projects.
This is also possibly impacting how the Security Inventory (Beta) displays the information.
Current behavior
If a scan runs on a project that doesn't have any supported project files at all, the scan fails with an error. An example would be a repository with Terraform (TF) or OpenTofu files.
Customer Feeback: We shouldn't expect this to fail because the project doesn't really have any application/language dependencies managed by a package manager or build system.
Expected behavior
TODO
Customer expectation: A scan runs on a project with only TF/OpenTofu files, and runs without error. No CycloneDX components are reported in the CDX report, and no vulnerabilities are reported in the security report.
Further details
This new approach was meant to align with some other AST scanners and defer such logic to the analyzer. The main benefit is that we can provide better feedback to the user about why a scan doesn't run in a given situation.
For instance, we similarly removed the CI job rule that checks for the ultimate license. So now, instead of silently skipping the job, we run it and the analyzer fails with an explicit warning message in the logs. Later, we can normalize specific exit codes and error messages that could be processed in the rails backend to provide further feedback in the UI.