Skip to content

refactor: remove config item gitlab.securityScans.serviceUrl

Jason Leasure requested to merge jleasure/security-scans-serviceurl-config into main

Description

Security scanning should now route to the GitLab API, as per refactor: security scanner uses gitlab api (gitlab-org/editor-extensions/gitlab-lsp!840 - merged) • Jason Leasure • 17.5, so the serviceUrl config item is no longer necessary.

This MR removes it.

Related Issues

Use SAST scan API endpoint in IDE extension (gitlab#479212 - closed) • Jason Leasure • 17.5 • On track

How has this been tested?

  • Run GDK in SaaS simulation mode with SCANNER_SERVICE_URL set to http://localhost:8080

    e.g. in gdk/env.runit include

    export GITLAB_SIMULATE_SAAS=1
export SCANNER_SERVICE_URL=http://localhost:8080

  • run sast-scanner-service locally on the branch we plan to merge next week

    checkout the repo

    git clone -b jleasure/accept-json git@gitlab.com:gitlab-org/secure/sast-scanner-service.git
cd sast-scanner-service

    download a ruleset and unzip

    curl https://gitlab.com/gitlab-org/security-products/sast-rules/-/package_files/146701454/download | bsdtar -xf -

    and start the server with the local GDK instance as OIDC provider

    go run . serve -c ./dist --auth GitLabOIDC --oidc-provider http://localhost:3000

  • the endpoint used is currently SaaS only for Ultimate customers, so select an appropriate user and project in GDK

    in .vscode/settings.json include

      "gitlab.featureFlags.remoteSecurityScans": true,
  "gitlab.securityScans.enabled": true,

    copy a file with some vulnerabilities, e.g. any of the source files with an accompanying .yml rule file in the sast-rules project.

    it doesn't need to be added to the repo, just in the project directory.

  • in the workflow extension using this language server branch...

    add your GDK account on localhost:3000.

    run the command Run Security Scan with an active document containing

    NOTE: the request requires an instance version 17.6.0, which should be temporarily backed down to e.g. 17.4 when testing.

Screenshots (if appropriate)

What CHANGELOG entry will this MR create?

  • fix: Bug fix fixes - a user-facing issue in production - included in changelog
  • feature: New feature - a user-facing change which adds functionality - included in changelog
  • BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
  • None - other non-user-facing changes

Merge request reports