You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue here is that there is no version >= 2.13.0 (latest is 2.12.2) so we can't fix this vulnerability until the Pylint maintainers release the next minor version (2.13.0). It appears they're working on it (milestone: https://github.com/PyCQA/pylint/milestone/49) but I haven't been able to find any ETA (it could be weeks/months). In the meantime, all of our CI/CD pipelines are broken and the only solution is to ignore this particular vulnerability by ID until the release of the new pylint version and then update and remove the ignore setting. This is not an ideal solution because it forces us to track the next pylint releases and change the configuration on dozens of repositories.
For example, it would be great if safety allowed us to ignore all unfixable vulnerabilities like trivy does. In this case, safety would not report vulnerabilities that can't be fixed updating to the latest versions. Another option is to report them but mark them as unfixable on the report and maybe use a special exit code so we can configure our pipeline to "pass with errors" if there are only unfixable vulnerabilities.
On the other hand, in this particular case, why is this bug marked as a security vulnerability anyway? Pylint crashing when some extension is used does not seem like a security vulnerability to me (it could be if you consider that every vulnerability is in fact a bug). Would it make sense to remove this vulnerability from the database?
What I Did
There's nothing we can do at the moment. There is no crash or bug really and the tool is working as intended, so updating it does not help.
The text was updated successfully, but these errors were encountered:
Not reporting vulnerabilities that can't be fixed updating to the latest versions would be a high-security risk. Imagine a critical vulnerability like the recent Log4Shell going through your pipelines because of this setting.
On the other hand, to report them with an especial exit code would also lead to dangerous situations.
However, we are about to release Safety 2.0 which will include some capabilities that may be useful for you:
-Filtering vulnerabilities by severity. For example, you may configure it to report only vulnerabilities with Critical, High, or Medium CVSS scores.
-Adding 'reason' and 'date' to vulnerabilities ignored by ID, for improving documentation and for determining in which date a particular vulnerability should be stopped being ignored.
About the vulnerabilities in our DB, we only include 'bugs' as vulnerabilities if they impact confidentiality, integrity, or the availability of a service. For this particular case, we understand that the crash may lead to a partial or full loss of availability of a service providing Pylint extensions usage.
Let me know if you have more questions or I can be of help with another issue.
Description
Safety reports the following bug on Pylint:
pylint-dev/pylint#5322
as a vulnerability:
The issue here is that there is no version >= 2.13.0 (latest is 2.12.2) so we can't fix this vulnerability until the Pylint maintainers release the next minor version (2.13.0). It appears they're working on it (milestone: https://github.com/PyCQA/pylint/milestone/49) but I haven't been able to find any ETA (it could be weeks/months). In the meantime, all of our CI/CD pipelines are broken and the only solution is to ignore this particular vulnerability by ID until the release of the new pylint version and then update and remove the ignore setting. This is not an ideal solution because it forces us to track the next pylint releases and change the configuration on dozens of repositories.
For example, it would be great if safety allowed us to ignore all unfixable vulnerabilities like trivy does. In this case, safety would not report vulnerabilities that can't be fixed updating to the latest versions. Another option is to report them but mark them as unfixable on the report and maybe use a special exit code so we can configure our pipeline to "pass with errors" if there are only unfixable vulnerabilities.
On the other hand, in this particular case, why is this bug marked as a security vulnerability anyway? Pylint crashing when some extension is used does not seem like a security vulnerability to me (it could be if you consider that every vulnerability is in fact a bug). Would it make sense to remove this vulnerability from the database?
What I Did
There's nothing we can do at the moment. There is no crash or bug really and the tool is working as intended, so updating it does not help.
The text was updated successfully, but these errors were encountered: