Many vulnerabilities with dependent gems
Closed this issue · 7 comments
Several of the dependent gems have open CVE records suggesting to upgrade. For example:
CVE-2023-22799 - globalid
CVE-2022-23516 - loofah
Could a new gem version be pushed with the latest working versions?
It is triggering lots of false positives in security scanning of a docker image we use this gem in.
Thanks
+1, although possibly you can just remove & .gitignore Gemfile.lock here? I see a lot of other gems' repos don't have this file.
@womblep In general (and for this gem in particular) Ruby gem repositories’ Gemfile.lock files contains development dependencies which are used only during gem development and aren't used during runtime. So you shouldn't look at it at all.
You need to scan only your project’s Gemfile.lock which contains versions of your dependencies actually used in your app.
Please adjust your security scan to ignore Gemfile.lock files for Ruby gems.
@skolsuper Historically, many Ruby gems didn't have lockfiles committed into version control, but it was frequently leading to cases when new contributors couldn't set up development environment due to unexpected dependencies updates. Now it is considered a best practice to keep Gemfile.lock in version control for gems.
See following resources for more context:
Released version 1.3.1 with Gemfile.lock excluded from packaging among with other development-specific files.
Please upgrade and enjoy!
@Envek I would love to stop scanning the Gemfile but unfortunately AWS Inspector does it automatically and you cant stop it :-(
AWS Inspector is also annoying in that it looks at the Gemfile.lock but not if the actual gems are installed. So it was warning about issues that were not actual issues.
I really appreciate the new gem. I will have a play and see if AWS Inspector calms down.