doc: Emphasize on the need for thorough review of changes from forks

doc/development/code_review.md

@@ -408,8 +408,19 @@ When ready to merge:
   circling back with the author about that. Otherwise, if the MR only has a few commits, we'll
   be respecting the author's setting by not squashing them.
 
-- **Start a new merge request pipeline with the `Run Pipeline` button in the merge
-  request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).** Note that:
+WARNING:
+**If the merge request is from a fork, review all changes thoroughly for malicious code before
+starting a [Pipeline for Merged Results](../ci/merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project).**
+Pay particular attention to new dependencies and dependency updates, such as Ruby gems and Node packages.
+While changes to files like `Gemfile.lock` or `yarn.lock` might appear trivial, they could lead to the
+fetching of malicious packages.
+If the MR source branch is more than 100 commits behind the target branch, ask the author to rebase it.
+Review links and images, especially in documentation MRs.
+When in doubt, ask someone from `@gitlab-com/gl-security/appsec` to review the merge request **before starting any merge request pipeline**.
+
+- Start a new merge request pipeline with the `Run Pipeline` button in the merge
+  request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).
+  Note that:
   - If **[master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
     do not merge the merge request** except for
     [very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master).
@@ -417,10 +428,6 @@ When ready to merge:
   - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results)** finished less than 2 hours ago, you
     might merge without starting a new pipeline as the merge request is close
     enough to `master`.
-  - If the **merge request is from a fork**, we can use [Pipelines for Merged Results from a forked project](../ci/merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project) with caution.
-    Before triggering the pipeline, review all changes for **malicious code**.
-    If you cannot trigger the pipeline, review the status of the fork relative to `master`.
-    If it's more than 100 commits behind, ask the author to rebase it before merging.
 - When you set the MR to "Merge When Pipeline Succeeds", you should take over
   subsequent revisions for anything that would be spotted after that.