Clarify interaction between GitLab SAST config options and upstream project config options
Problem to solve
When users try to customize SAST behavior—for example, by excluding a path from scanning—they can fall into a particular path that we don't intend. To quote a user:
I naturally will:
- check what scanner is being used (in this case, semgrep for python)
- follow the documentation (which links from https://docs.gitlab.com/ee/user/application_security/sast/ to the semgrep homepage)
- then I'm surprised when following the semgrep documentation does not work - it's only now that I've seen SAST_EXCLUDED_PATHS that I searched the page for it (and whilst I appreciate comprehensive documentation, an entry 2/3 of the way into a page that I'm not likely to read in its entirety means that I'm likely to miss it)
(from a community MR to the Semgrep analyzer)
We intend for them to prefer generic options that apply to all analyzers, but the page structure can lead them to leave our documentation, discover options available in upstream scanner projects, and expect them to work in GitLab SAST.
Further details
Proposal
- Consider whether analyzer names and projects should be front-and-center in the Supported languages and frameworks section. Could this be reserved for the Analyzers sub-page, with "For details of the analyzers used to scan each language, see SAST analyzers" or similar text?
- Consider adding some explanatory text that clearly explains that users should look for the available CI/CD config options rather than going upstream.
- Other improvements? Open to suggestions.
Who can address the issue
Anyone
Other links/references
gitlab-org/security-products/analyzers/semgrep!121 (comment 1002153495)