Add missing Bandit config file and rules path options

[CAM-Gerlach]

Is your feature request related to a problem? Please describe.

I am unable to configure Mega-Linter to recognize my existing repository-root Bandit config file (.bandit.yml), either by manually specifying the path to it, or by using the LINTER_DEFAULT option, as the relevant PYTHON_BANDIT_CONFIG_FILE config variable is missing. Therefore, Mega-Linter reports errors I've ignored there. Furthermore, PYTHON_BANDIT_RULES_PATH is not present as well; these two config variables exist for every other linter I could find, but not Bandit. I confirmed they aren't just undocumented, as I tested adding them and Bandit's behavior didn't change.

As a result, given the duplication that would occur with maintaining two different config files for the same tool at two different paths and filenames, I've unfortunately had to refrain from running Bandit with Mega-Linter until this issue is resolved.

Presumably related to PR #533 .

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add the two relevant config file path related variables, like all the other linters have.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Not adding the variables; there appears to be no clear motivation for this given all the other linters have them and bandit has a config file like all the others, so it would only make sense to have them as well.

Additional context
Add any other context or screenshots about the feature request here.

Thanks for your consideration!

[nvuillam]

True, i forgot to define a default config file name, that's what lead to the missing features + the missing variables in auto-generated doc :)

PR in progress

[CAM-Gerlach]

Thanks @nvuillam !

[nvuillam]

Released in latest/insiders, please can you confirm that it's ok now ?

Note: this CI job must be completed before testing is available with latest/insiders tag

[CAM-Gerlach]

Hey @nvuillam , thanks for your quick work on this! Unfortunately it doesn't seem to have worked all the way, though its quite possible I did something wrong. I set the action to uses: nvuillam/mega-linter@insiders as the Readme instructs, and I could see in the build output that the latest builds were getting pulled and I verified #680 is now fixed, and I'm also no longer getting an error due to the config file being incorrect and having a spurious option. I also see - Rules config: identified by [bandit] in the log, which indicates it seems to be getting picked up.

However, the option does not appear to be honored, as I nevertheless appear to be getting the same set of bandit errors (lots asserts in my tests, plus subprocess.run() without shell=True) that my .bandit.yml silences and my other local and CI runs of bandit don't pick up. You can check out what I have so far on r-spacex/submanager#11 ... Let me know if there's something else I should try. Thanks!

[nvuillam]

Indeed , - Rules config: identified by [bandit] indicates that there is no call to --config .bandit.yml

Please could you add LOG_LEVEL: DEBUG in your .mega-linter.yml config file ?

This will output veru chatty logs, but within them it will show the exact calls to bandit with arguments , so maybe from that we can see what's wrong

[CAM-Gerlach]

Sure, done as requested.

Pretty and raw format logs on r-spacex/submanager#11 .

Looks like nothing is being passed to the bandit command except for the executable name and the list of files; from line 1325:

bandit] command: ['bandit', '/github/workspace/setup.py', '/github/workspace/src/submanager/__init__.py', <SNIP> '/github/workspace/tools/enable_praw_typehints.py', '/github/workspace/tools/generate_requirements_files.py']

[CAM-Gerlach]

BTW, I'm assuming the secretlint hit is due to a log file that the debug mode created? It didn't appear in the last run and it doesn't look like any actual file I have checked into the repo.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.