Support Shell SAST Scanning
Problem to solve
Many repositories have shell scripts, even if a project is not a shell-base project. Shell scripts can have incredible power as they are run directly on the server often with elevated permission. Writing shell scripts that are secure and linted is especially important.
Since the shell scripts are often hacked together and outside the typical development SDLC, adding a shell SAST scanner will help catch coding errors and potential vulnerabilities.
Intended users
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Further details
A handful of open source scanners are available that may be able to be wrapped.
Examples:
-
https://github.com/koalaman/shellchecklinting only -
https://github.com/anordal/shellhardenlinting only
Those tools need to be evaluated for technical and legal compatibility with GitLab.
GitLab recommends shellcheck as part of any pipeline for a project that has shell scripts. https://docs.gitlab.com/ee/development/shell_scripting_guide/index.html
Once the availability of a shell SAST scanner is available, GitLab can update its shell scripting guide to use the SAST scanner.
Proposal
Wrap an existing shell scanner tool.
Permissions and Security
Documentation
The SAST scanner page will need to be updated. https://docs.gitlab.com/ee/user/application_security/sast/ and the shell scripting guide will need to be updated https://docs.gitlab.com/ee/development/shell_scripting_guide/index.html
Testing
A sample shell project will need to be created to test the SAST scanner.
What does success look like, and how can we measure that?
Usage pings on a shell SAST scanner will show that the scanner is actively being used.
What is the type of buyer?
Links / references
--
Evaluation Checklist
-
TODO: identify candidate tool
Underlying tool
-
Has permissive software license -
Headless execution (CLI tool) -
Executable using GitLab Runner's Linux or Windows Docker executor -
Language identification method (file extension, package file, etc)
Minimal vulnerability data
-
name -
description (helpful but not mandatory) -
type (unique value to avoid collisions with other occurrences) -
file path -
line number