Remove end-of-support analyzers from the offline page

Andrew Dunnrequested to merge
docs/offline-deployments-end-of-support-analyzers into master

What does this MR do?

The offline deployment page told operators that the mirroring template downloads bandit, brakeman and gosec by default, and its example scripts packaged bandit, eslint and gosec. All four reached End of Support, and the template no longer mirrors them by default. An operator who followed the page would mirror images no current scan requests.

This MR starts the documented default with the analyzers the template does mirror. It points the example scripts at semgrep and spotbugs, each with the version the SAST template pulls, and fixes their loop, which treated the whole list as one image name.

What changed and how we checked
  • Default value. The template's default list starts with gitlab-advanced-sast, gitlab-advanced-sast-cpp and gitlab-advanced-sast-ext, and a comment above it lists bandit, brakeman, gosec and eslint among the analyzers that reached End of Support. The table now shows those three, then ..., as it did before.
  • End of Support. The SAST analyzers page lists bandit, eslint and gosec at GitLab 15.4 and brakeman at 17.0, and links the deprecation announcements. The registry images bandit:2, eslint:2 and gosec:3 were last built in 2022, and Jobs/SAST.gitlab-ci.yml keeps a job for each of the four that never runs.
  • Versions. Jobs/SAST.gitlab-ci.yml runs semgrep at version 6 and spotbugs at 5, which stays supported for Groovy, and registry.gitlab.com/security-products serves both tags. Each analyzer has its own version, so the scripts take name:version entries, which is easy to change if you would rather the example named one analyzer. The semgrep job in Secure-Binaries.gitlab-ci.yml still pulls version 5 on master, and !260570 (merged) moves it to 6.
  • The loop. "${analyzers[@]}" on a plain string is one item, so the old packager ran docker pull registry.gitlab.com/security-products/bandit eslint gosec:2 once. With docker, scp, ssh and sudo replaced by commands that print their arguments, the old packager made that single pull. The new packager makes a pull and a save, and the new loader a copy, load, tag and push, for each entry, whether the list is the default semgrep:6 spotbugs:5 or three name:version entries set in SAST_ANALYZERS. The loader's tag step ran its image lookup on the bastion host, inside double quotes, not on the offline host the tag applies to, so it now tags registry.gitlab.com/security-products/<name>:<version>, the name docker load restores.

Related issues

Related to #537016 (closed), which asked the template to exclude the End of Support analyzers by default.

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change. The assistant also read each linked file at master, ran the old and new example scripts with the commands they call replaced by ones that print their arguments, checked the image tags against the registry, and ran the project's Vale and markdownlint configuration on the changed page.

Merge request reports