Unsupported `yarn.lock` file in Gemnasium when using GitLab CI template will crash `analyser`

Summary

Unsupported yarn.lock file in Gemnasium when using GitLab CI template will crash analyser.

Newer versions of Yarn have a different format of yarn.lock file. These files start with:

__metadata:
  version: 6
  cacheKey: 8

# ...

Gemnasium crashed when this file is found in the repo.

[FATA] [Gemnasium] [2023-02-24T19:49:39Z] ▶ scanning file /some_path/yarn.lock: parsing file /some_path/yarn.lock: invalid spec: __metadata

Steps to reproduce

Created simple test repo to reproduce error: https://gitlab.com/df_storyteller/yarn-test

Create a repo with the following a yarn.lock file:

# This file is generated by running "yarn install" inside your project.
# Manual changes might be lost - proceed with caution!

__metadata:
  version: 6
  cacheKey: 8

# Other dependencies are optional

Setup a GitLab ci file with default template:

stages:
 - repo_scan

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

dependency_scanning:
  stage: repo_scan

Commit to repo and let pipeline run. This will result in the following job log:

Running with gitlab-runner 15.9.0~beta.115.g598a7c91 (598a7c91)
  on blue-3.shared.runners-manager.gitlab.com/default zxwgkjAP, system ID: s_284de3abf026
Resolving secrets 00:00
Preparing the "docker+machine" executor
Using Docker executor with image registry.gitlab.com/security-products/gemnasium:3 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/security-products/gemnasium:3 ...
Using docker image sha256:939758bc7f6e8a1fafc0e7f58f4f81caac42f226807ee2db15df17df0286a141 for registry.gitlab.com/security-products/gemnasium:3 with digest registry.gitlab.com/security-products/gemnasium@sha256:06d6999d101a9c723b13ea186bdf09352cf14193ec8ae3abe283c4247e4f16d3 ...
Preparing environment 00:03
Running on runner-zxwgkjap-project-43825594-concurrent-0 via runner-zxwgkjap-shared-1677268085-a3476ca3...
Getting source from Git repository 00:02
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/df_storyteller/yarn-test/.git/
Created fresh repository.
Checking out a351e841 as detached HEAD (ref is main)...
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:02
Using docker image sha256:939758bc7f6e8a1fafc0e7f58f4f81caac42f226807ee2db15df17df0286a141 for registry.gitlab.com/security-products/gemnasium:3 with digest registry.gitlab.com/security-products/gemnasium@sha256:06d6999d101a9c723b13ea186bdf09352cf14193ec8ae3abe283c4247e4f16d3 ...
$ /analyzer run
[INFO] [Gemnasium] [2023-02-24T19:49:37Z] ▶ GitLab Gemnasium analyzer v3.11.3
[INFO] [Gemnasium] [2023-02-24T19:49:39Z] ▶ Using commit ee096ed8997218c45aab8de448dbed67192a71d8
 of vulnerability database
[FATA] [Gemnasium] [2023-02-24T19:49:39Z] ▶ scanning file /builds/df_storyteller/yarn-test/yarn.lock: parsing file /builds/df_storyteller/yarn-test/yarn.lock: invalid spec: __metadata
Uploading artifacts for failed job 00:01
Uploading artifacts...
WARNING: **/gl-sbom-*.cdx.json: no matching files. Ensure that the artifact path is relative to the working directory (/builds/df_storyteller/yarn-test) 
ERROR: No files to upload                          
Uploading artifacts...
WARNING: gl-dependency-scanning-report.json: no matching files. Ensure that the artifact path is relative to the working directory (/builds/df_storyteller/yarn-test) 
ERROR: No files to upload                          
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: exit code 1

Example Project

https://gitlab.com/df_storyteller/yarn-test

Pipeline job: https://gitlab.com/df_storyteller/yarn-test/-/jobs/3832370353

What is the current bug behavior?

Pipeline step crashes, so pipeline job fails. It is allowed to fail so other steps should continue.

gemnasium-dependency_scanning - failed - (script failure) (allowed to fail)

What is the expected correct behavior?

The file should be parsed and dependencies should be checked. Or
The parser should report the file is not supported and skip parsing the file and look for other files to check.

Relevant logs and/or screenshots

See logs above.

Output of checks

This bug happens on GitLab.com