-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Many vulnerabilities with dependent gems #26
Comments
+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’ You need to scan only your project’s Please adjust your security scan to ignore |
@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 See following resources for more context: |
Released version 1.3.1 with 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 :-( I really appreciate the new gem. I will have a play and see if AWS Inspector calms down. |
@womblep, was you able to check a new gem version? Just curious whether it helped. |
@Envek yes it fixed the issue completely |
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
The text was updated successfully, but these errors were encountered: