-
Notifications
You must be signed in to change notification settings - Fork 0
Add vulnerabilities check in the CI + SECURITY.md file #627
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #627 +/- ##
=======================================
Coverage 87.62% 87.62%
=======================================
Files 65 65
Lines 2999 2999
=======================================
Hits 2628 2628
Misses 371 371 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi @FedericoNegri! I think what bandit is trying to tell you is to avoid silently ignoring exceptions. Rather than a security concern this one is more related to best practices - unless it's intended. Would adding a message to the logger (with debug level?) make sense? I don't know how often and under what circumstances you might end up going down the exception path - but maybe it makes sense to let the users know that happened. If it doesn't make sense, then let's ignore it. However, I would suggest, in that case, that you only ignored that specific rule and added an explanatory comment - for example: try:
# do something
except Exception:
# Ignoring exceptions because ...
pass # nosec B110 |
|
@RobPasMue made the nosec marker more specific and added comments |
RobPasMue
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome - thanks @FedericoNegri!
Adding vulnerabilities check in the CI + SECURITY.md file as requested by the PyAnsys team in the linked issues.
Bandit flagged two cases of B110 try_except_pass. Reviewed the code and don't see how that can be a security concern. These are not places with any relevant logic.
I think they're acceptable and propose to mark those two instances as
# nosec.