Hey folks! 👋 I've been experimenting with the new "security lens" plugin for our AI assistants—you know, the one that's supposed to flag vulnerabilities in generated code before you run it. It sounds great in theory, but I ran into something pretty ironic.
I asked my assistant to write a simple Python function that hashes a password using `hashlib`. The plugin flagged it as "potentially insecure" because it was using MD5 (fair!), and suggested using `bcrypt` instead. But then the *suggested fix* from the plugin itself had a glaring error. Here's the exchange:
**My prompt:**
```
Write a secure password hashing function in Python.
```
**Assistant output (with security lens flag):**
```python
import hashlib
def hash_password(password: str) -> str:
# Security lens: MD5 is cryptographically broken. Consider bcrypt or argon2.
return hashlib.md5(password.encode()).hexdigest()
```
**Plugin's suggested fix:**
```python
import bcrypt
def hash_password(password: str) -> str:
salt = bcrypt.gensalt()
return bcrypt.hashpw(password.encode(), salt).decode()
```
The problem? `bcrypt.hashpw()` returns a bytes object, and `.decode()` will fail unless you specify an encoding. Worse, `bcrypt` expects the password as bytes, but the example might mislead someone about error handling. The correct version should handle the bytes properly and likely catch exceptions.
**What it should look like:**
```python
import bcrypt
def hash_password(password: str) -> bytes:
password_bytes = password.encode('utf-8')
salt = bcrypt.gensalt()
hashed = bcrypt.hashpw(password_bytes, salt)
return hashed # or store as bytes, or optionally encode to hex/base64
```
So the security lens correctly identified a weak algorithm, but its own "fix" introduced a runtime error. 😅
Has anyone else tried this plugin? I'm curious if you've seen similar cases where it catches one issue but introduces another—especially around:
- Library API hallucinations
- Missing error handling in security-critical code
- Incomplete refactors that break type consistency
It feels like we need a "security lens for the security lens" sometimes. Would love to hear your experiences!
Clean code is not an option, it's a sanity measure.
That decode error is the least of it. The plugin missed the real issue: no work factor configured for bcrypt.gensalt(). That means it's using the default, which is probably too weak for your actual security needs. So the fix it offered is both broken and insecure.
You've found the core problem with these automated scanners. They spot the obvious, textbook vulnerability but fail on the implementation details and the actual security posture. I've seen similar tools approve code with hardcoded secrets because the variable name didn't match a pattern.
What did the plugin flag when you fed it its own suggested fix?
Don't panic, have a rollback plan.
Exactly. The plugin saw nothing wrong with its own output. It only flags patterns it's trained to recognize.
These tools are glorified linters. They miss context and create a false sense of security. I've had a scanner pass a bcrypt call with a work factor of 4 because "bcrypt" was in the function name.
You're better off with a dedicated SAST tool in the pipeline. Even a simple unit test checking the work factor would catch this.
You've hit on the real danger. That false sense of security is the product killer. I once watched a team get compliance sign-off because their pipeline had a scanner like this, but it never flagged the same five lines of debug code logging API keys to a file because the keys were concatenated from two environment variables. The pattern wasn't in its dictionary.
A dedicated SAST tool is the right call, but you still need to tune it. They all have blind spots. The unit test idea is crucial - it's the only way to encode your actual security requirements, like that minimum work factor, into something that breaks the build. A scanner looks for bad patterns; a test defines what 'good' actually is.