### Summary The [scan execution policy documentation](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/#cicd-variables) states that a set of preconfigured CI/CD variables is applied to any project on which a scan execution policy is enforced, and that: > Preconfigured values are used for the following CI/CD variables in any project on which a scan execution policy is enforced. Only policies can override these values. Group or project CI/CD variables cannot override these variables: `SAST_EXCLUDED_PATHS` is listed among those variables. In practice, when the policy does **not** explicitly define `SAST_EXCLUDED_PATHS`, a project-level CI/CD variable of the same name is honored by the policy-enforced SAST job and changes the scan results. This contradicts the documented behavior. When the policy **does** explicitly define `SAST_EXCLUDED_PATHS`, the policy value wins as documented. Only the preconfigured default appears to be unprotected. This means either the enforcement of preconfigured policy variables is not working as intended, or the documentation overstates the guarantee for variables the policy does not set explicitly. ### Steps to reproduce - A scan execution policy enforcing SAST is configured on the group. - The policy does not define `SAST_EXCLUDED_PATHS`, so the preconfigured value documented as `spec, test, tests, tmp` is expected to apply and to be unoverridable. - A project below that group inherits the policy, and SAST runs as expected. - Setting a project CI/CD variable `SAST_EXCLUDED_PATHS` (for example `*.py`) and re-running the pipeline changes the scan results: the project level `SAST_EXCLUDED_PATHS` is honored instead of the preconfigured policy value. Not yet verified whether the same applies to the other preconfigured variables listed in the documentation. ### Example Project This was reported by a customer and reproduced on both GitLab.com (SaaS) and GitLab Self-Managed 19.3.1. This is the example project in GitLab.com: https://gitlab.com/kkamiya_gl_ultimate_group/scan-policy-test/749157-test ### What is the current _bug_ behavior? The policy-enforced `semgrep-sast-0` job runs with the project-level value of `SAST_EXCLUDED_PATHS` instead of the preconfigured policy value. Files matching the project-level value of `SAST_EXCLUDED_PATHS` are excluded from the scan, and the resulting findings differ from a run without the project variable. This happens only when the scan execution policy does not define `SAST_EXCLUDED_PATHS` in its `variables` block. When the policy defines the variable explicitly, the policy value is applied and the project variable is ignored, as documented. ### What is the expected _correct_ behavior? Per the [documentation](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/#cicd-variables), `SAST_EXCLUDED_PATHS` is one of the variables for which a preconfigured value is used in any project where a scan execution policy is enforced: > Only policies can override these values. Group or project CI/CD variables cannot override these variables The project-level `SAST_EXCLUDED_PATHS` variable should therefore be ignored, and the scan should run with the preconfigured value, regardless of whether the policy sets the variable explicitly. If instead the intended design is that the preconfigured defaults are overridable and only explicitly-declared policy variables are protected, the documentation should be corrected to say so, because the current wording gives a guarantee that does not hold. ### Relevant logs and/or screenshots * Test project has "test.py" file. This file contains vulnerabilities. {width="571" height="255"} * Policy ``` scan_execution_policy: - name: SAST test description: '' enabled: true policy_scope: projects: excluding: [] actions: - scan: sast variables: SECURE_ENABLE_LOCAL_CONFIGURATION: 'false' template: latest rules: - type: pipeline branch_type: default - type: pipeline branch_type: target_default pipeline_sources: including: - merge_request_event skip_ci: allowed: true ``` * Job before I set `SAST_EXCLUDED_PATHS` variable in the project. ([Link](https://gitlab.com/kkamiya_gl_ultimate_group/scan-policy-test/749157-test/-/jobs/16281585375)) {width="526" height="414"} * Project-level `SAST_EXCLUDED_PATHS` {width="383" height="307"} * Job after I set `SAST_EXCLUDED_PATHS` variable in the project. ([Link](https://gitlab.com/kkamiya_gl_ultimate_group/scan-policy-test/749157-test/-/jobs/16282318975)) {width="691" height="432"} We can see the 1 file was skipped. ### Output of checks This bug happens on GitLab.com <!--This bug happens on GitLab.com--> <!--and uncomment below if you have /label privileges--> <!--/label ~"reproduced on GitLab.com"--> <!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not--> #### Possible fixes Not verified, but a possible starting point. In [`ee/app/services/security/security_orchestration_policies/scan_pipeline_service.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/security/security_orchestration_policies/scan_pipeline_service.rb), the preconfigured `SAST_EXCLUDED_PATHS` is not a literal value but a reference to another variable: ```ruby sast: { 'DEFAULT_SAST_EXCLUDED_PATHS' => 'spec, test, tests, tmp', 'SAST_EXCLUDED_PATHS' => '$DEFAULT_SAST_EXCLUDED_PATHS', ... } ``` A policy value declared explicitly is reported to work, while this preconfigured default is not, so the indirection may be relevant. The documentation also lists this variable as the literal spec, test, tests, tmp, which does not match the implementation. This may be related to the known fragility of the scan execution policy variable precedence implementation described in #581954 and #462746, and is the inverse of the precedence bug fixed in #479820. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->