Scanning job is triggered but SAST, DS analyzer finds no compatible project (no DinD setup)
Summary
In some cases SAST and Dependency Scanning scanning jobs are triggered but fail with a No match
error and exit code 3
, which indicates that the project is not supported. This happens when the conditions implemented in the search package of the common library don't match the rules
of the scanning job. This undocumented, inconsistent behavior is likely to make both users and developers confused.
CLOSED: After long discussions, we concluded that the rules
syntax cannot accurately describe when a scanning needs to run. So there might be cases where the scanning job is triggered, even though there's nothing to scan. The job rules
should be considered as an optimization, to avoid running a scanning job for a project that's not compatible.
Further details
The search
is configured by 3 environment variables named SEARCH_MAX_DEPTH
, SEARCH_IGNORED_DIRS
, and SEARCH_IGNORE_HIDDEN_DIRS
. See search/flags.go to see their default values.
Note that command/search implements project detection, and not file filtering. Once the scan is triggered, a file might be scanned even if it is excluded by the filters defined in command/search. File exclusion is implemented in common/pathfilter.
Steps to reproduce
- create a project with files supported by some Dependency Scanning (DS) or SAST analyzer
- make sure the files supported by the DS or SAST analyzer are ignored based on
SEARCH_MAX_DEPTH
,SEARCH_IGNORED_DIRS
, orSEARCH_IGNORE_HIDDEN_DIRS
- enable DS or SAST in the CI configuration file ("no DinD" setup)
- trigger a pipeline
The compatible scanning job is triggered and shows up in the pipeline, but there is no scan and the job exits with code 3
.
Example Project
See #208715 (closed)
What is the current bug behavior?
The scanning job fails with a No match
error.
What is the expected correct behavior?
All scanning jobs that have been triggered should scan the repository. The scanning jobs that don't match are not triggered, and don't show up in the pipeline.
Relevant logs and/or screenshots
See #208715 (closed)
Possible fixes
Update the run
command so that it uses the match function instead of the search
package:
- remove the search flags
- do not use the
search
package -
when
cfg.AnalyzeAll
is false and the scan is executed in a sub-directory, usecfg.Match
(the match function) to find a compatible file, and use that the directory of that file as thetarget
directory; the walk must exclude files that match_EXCLUDED_PATHS
otherwise the scan might be executed in the context of a directory that's been explicitly excluded - if there's no match, fail with search.ErrNotFound error
Also, update the job . Out of scope. This depends #34859 or #198688, and currently none of these issues has been scheduled.rules
so that the paths listed in SAST_EXCLUDED_PATHS
and DS_EXCLUDED_PATHS
are ignored
Alternatively, we can change the search
package to implement this new behavior.
For this to work, SAST_EXCLUDED_PATHS
and DS_EXCLUDED_PATHS
have to match the current value of SEARCH_IGNORED_DIRS
. So this issued depends on #220014 (closed)
After implementing this fix, we might still be in the situation where the scanning job is triggered but there's nothing to scan because the paths that match rules:exists
are excluded by SAST_EXCLUDED_PATHS
or DS_EXCLUDED_PATHS
(vulnerability filters). It's still an improvement though. See discussion.
Note that SEARCH_IGNORE_HIDDEN_DIRS
is not covered by this proposal, so a discrepancy will persist until we introduce a vulnerability filter that filters out hidden directories.