Skip to content
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

Ensure that each #nosec usage has an accompanying explanation #478

Open
ericwb opened this issue Apr 12, 2019 · 1 comment
Open

Ensure that each #nosec usage has an accompanying explanation #478

ericwb opened this issue Apr 12, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@ericwb
Copy link
Member

ericwb commented Apr 12, 2019

Transfer of OpenStack blueprint:
https://blueprints.launchpad.net/bandit/+spec/nosec-has-comment

#nosec tags should not just be used to make problems go away. Every time somebody uses #nosec it should be accompanied by an explanation for why this really isn't a security issue.

@ericwb ericwb added the enhancement New feature or request label Apr 12, 2019
@ericwb ericwb added this to the Distant Future milestone May 9, 2019
@andren
Copy link

andren commented Nov 23, 2020

@ericwb my team has an interest in this feature and I'm willing to contribute if we can agree on a format and if you would accept it of course.

Regarding formats

  1. Suppressing Individual Lines:
# The following hash is not used in any security context. It is only used
# to generate unique values, collisions are acceptable and "data" is not
# coming from user-generated input
the_hash = md5(data).hexdigest()  # nosec
  1. nosec-has-comment proposal:
# nosec(sigmavirus24): This is example text
  1. We could also use a slightly more complex hybrid system:
# The following hash is not used in any security context. It is only used
# to generate unique values, collisions are acceptable and "data" is not
# coming from user-generated input
the_hash = md5(data).hexdigest()  # nosec(sigmavirus24)

Point 1. might be harder to implement but would make it easier to follow PEP 8 - Maximum Line Length guidance. (in this case, max. of 72 chars for comments)

Point 2. seems to be easier to implement, but much fewer characters would be available for the justification if one would be following PEP 8. It also seems to have some sort of alias or ID tracking.

Point 3. is a bit more complex than 1. but it's easier to follow PEP 8 and has that alias/ID tracking thing.


What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants