PyCQA / PyCQA/bandit

Flag logging/printing of likely sensitive information

Open
#1,371 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
8.3k
Forks
836
Avg merge
5d 3h
Merged PRs (30d)
1

Description

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

It is impossible to flag sensitive information leaks to console logs in the general case (e.g. the debugging call in #201 is just a generic kwargs printer, with no information available at static analysis time to indicate it might be exposed to sensitive information like basic auth passwords or API keys).

However, some information leaks are blatant enough that they do show up under static analysis, as in something like logging.debug("Password: %s", password).

Describe the solution you'd like

A call alert that flags situations where a logging or printing call appears to be directly referencing sensitive information (whether by accessing variables with names like password, credentials, api_key, private_key, etc, or by calling secret retrieval APIs like keyring.get_password(...)).

Describe alternatives you've considered

Brute force regex searches for suspicious looking patterns (this may actually be one of those cases where the additional structure of an AST makes pattern detection for problematic cases harder to formulate)

Additional context

My actual assumption is that this idea has previously been considered and discarded as being far too prone to false positives to be feasible to implement as a general rule outside a specific application or organisational context. I didn't see anything obvious along those lines when searching the issue tracker for "sensitive" though, in which case even a closed issue may serve as a searchable record of the reasoning for not including such a check.


Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file, test, or entry point is identified. Start by reviewing existing issue-tracker discussions for “sensitive” and the scope of logging or printing calls, including variable names such as password and API-key names and APIs such as keyring.get_password(...). Done would require an agreed, tested detection rule with acceptable false-positive behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.