Embed Semgrep Community Rule javascript/exec/rule-child_process.yml
Why are we doing this work
As per https://gitlab.com/gitlab-org/gitlab/-/issues/425704 and https://gitlab.com/gitlab-org/gitlab/-/issues/4257041 we are working towards improving the coverage and efficacy of our SAST rules.
This Rule
This issue is aimed at embedding https://semgrep.dev/playground/r/javascript.lang.security.detect-child-process.detect-child-process?editorMode=advanced
Implementation Plan
Preparation
Look through community rules in the Semgrep registry, i.e. for Python https://semgrep.dev/r?lang=Python, and do the following:
-
If enhancing a GitLab SAST Rule, look for rules in Semgrep Community, PyCQA Bandit, etc that focus on the same issue in order to draw inspiration from them. -
If embedding a rule from the Semgrep Community repository, look for rules in the GitLab SAST rules that focus on the same issue. -
Verify if the rule in question currently exists or ever existed in our GitLab SAST Rules -
Familiarise yourself with the intent and efficacy of the rule(s), past and present, and gather that information as references in the description of the rule's implementation issue. -
Research and understand thoroughly the nature of the problem to be addressed, for example why, when, how it arises and why, when, how it doesn't. -
Create a list, based on the above, of the most relevant scenarios in which the issue the rule should address arises. -
If the rule does not exist in our GitLab SAST Rules and never did, use publicly available rules and code examples found previously as inspiration, copying them when their licence allows us to do so or replicating them when that isn't possible. -
If there is an existing rule in GitLab SAST Rules aimed at the same problem, compare it to the community ones and combine them as appropriate to reach the best possible true positive and true negative rate. If this is a small amount of work, Vulnerability Research should do it. If it is more than that, add to Add or overhaul SAST rules to cover additional ... (&10971 - closed) so the SAST contractor team can do it with Vulnerability Research's support.
Implementation
-
Create an simple but realistic Minimal Runnable Example(MRE), in e.g. mre/
, which captures the representative variant of the problem to be addressed by the rule. -
Create a Semgrep rule, i.e. rule-foobar.yml
, that identifies the issue as present in yourmre/
and place it in the language, framework and variant folder most suited for it, i.e.python/...
. -
For each instance of the problem to be found or ignored within your MRE, add two comments above each occurrence: -
One comment, optional if obvious, should explain the rationale behind the test-case, its pitfalls and anything you deem relevant. -
The second comment should follow Semgrep's rule testing guidelines, making it clear whether the code area or snippet represents a true positive ( ruleid: rule-foobar
) or a true negative (ok: rule-foobar
).
-
-
Continuously use your MRE to test said rule: semgrep scan --config rule-foobar.yml mre/
-
Continue to enhance and extend your MRE with all variants and corner cases, own or otherwise, of the same problem which are syntacticly and semantically different enough to warrant doing so and likely wouldn't be identified by your initial rule. -
Fix or update as well as test your rule as your MRE becomes more complex while also continuing to add comments and Semgrep test annotations to the latter. -
Once you are satisfied with the level of detail in your MRE as well as the coverage of your rule and its test results, distill your mre/
into arule-foobar.py
file or a series ofrule-foobar-<...>.py
files and place them into the same folder of your rule. -
Clone our Real World Test Projects and extend it with your MRE demonstrating the problem. Alternatively, discuss the creation of a new folder or repository if none fits. -
Push the changes to sast-rules-apps
as a feature branch to gitlab-org/security-products/tests/sast-rules-apps if you have access; otherwise push it to a personal fork of the project. -
Create the MR -
Assign for review to someone in the CODEOWNERS file -
Push the changes to sast-rules
as a feature branch to gitlab-org/security-products/sast-rules if you have access; otherwise push it to a personal fork of the project. -
Create the MR -
Update CHANGELOG.md detailing briefly the changes performed and their intent. -
Update the !<merge request id>
in the CHANGELOG.md if necessary after the MR is created -
Assign for review to someone in the CODEOWNERS file