Skip to content

Validate security report schema using the latest ADDITION version available

Why are we doing this work

As discussed, this work allows additive changes to the schemas in preceding versions of GitLab without the need to bump the pinned version of SAT analyzers.

When Rails is performing validation of security schemas, and the version declared in the report being ingested is not vendored within gitlab-org/gitlab (i.e. ee/lib/ee/gitlab/ci/parsers/security/validators/schemas/$VERSION), then the validation logic will look for schemas with the same MODEL-REVISION and use the latest ADDITION.

For example:

  • Versions vendored in GitLab: 14.0.0, 14.0.1, 14.0.2, 14.1.0
  1. Version in the report: 14.1.1
    • Result: report is validated against 14.1.0
  2. Version in the report: 14.0.32
    • Result: report is validated against 14.0.2
  3. Version in the report: 14.2.1
    • Result: report is rejected as not supported

Relevant links

  • This issue is a lot simpler to implement (i.e. weight 1) if done after #355628 (closed). It's not necessarily blocked by it, but there will be less complexity to deal with, and fewer unit tests to write.

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing: Unit tests should cover examples mentioned above - MR can be reviewed by counterpart SET

Implementation plan

  • backend Create a new schema versioning class that inherits from Gem::Version. This prevents us from having to reinvent the version parsing/comparison wheel. We could create our own version validation class that would utilize code that already exists.
  • backend Use the above schema versioning class to determine validity of ADDITION version.
Edited by Harsha Muralidhar