Accuracy improvements for py/clear-text-logging-sensitive-data
- 主要语言
- CodeQL
- 星标
- 10.1k
- 派生
- 2.1k
- 平均合并
- 2 天 15 小时
- 30 天内合并 PR
- 141
描述
**Description of the issue**
Hey, I found two common cases where the rule doesn't match in my codebase. One creates noise, the other misses a real leak.
First, `SecretStr` masks text automatically (e.g., prints '**********'). Logging these objects is safe, but the rule flags them.
```python
from pydantic import SecretStr
password = SecretStr("super_secret")
logging.info("Login: %s", password) # Flagged, but actually safe
```
2. Logging an exception object leaks its message (via __str__), but the rule misses this if the secret is inside the exception.
```python
secret_token = "secret_123"
# logging.error("Auth failed: %s", secret_token) # Detected ✅
try:
raise ValueError("Auth failed: {}".format(secret_token))
except ValueError as e:
# Currently NOT flagged, but leaks 'secret_123' via __str__ ❌
logging.error("Auth failed: %s", e)
```
Maybe we should add the first pattern to the sanitizers and add the second one as a propagator in the taint tracking config.
贡献指南
调研方向
Start with the py/clear-text-logging-sensitive-data query and its taint-tracking configuration, then trace how sanitizers and propagators are defined. Confirm that logging SecretStr is not flagged and that logging an exception containing a secret is flagged, using the issue's examples as regression cases.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- python
- 领域
- security
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 52/100