So we've been told for months that integrating Mend (née WhiteSource) into our PR workflow would "shift security left" and make developers more accountable. The mandate came down: every Mend finding in a PR must be manually reviewed and acknowledged by the dev before merge. No auto-approvals.
After six months of this policy, I can summarize the results: we've successfully trained our engineers to become experts in clicking "Dismiss" and writing "false positive" in the comment box. The actual reduction in vulnerable dependencies? Marginal. The increase in development friction and cynicism? Substantial.
Let's talk about the noise. Mend's default rules for Python are, to put it kindly, aggressive. It flags development tools and linters pinned in `requirements-dev.txt` as if they're deployed in production. We had a PR blocked because `black==23.7.0` had some obscure CVE from 2021 about improper symlink handling in a completely different context. The dev spent 45 minutes researching it, only to dismiss it. Here's the classic pattern now:
```python
# In our .mendignore or equivalent PR comment
# False positive - dev dependency, not bundled in container.
# CVE-2021-12345
# False positive - vulnerability requires root access, our runtime is unprivileged.
# CVE-2022-67890
```
The worst part is the "urgent" patching demands for transitive dependencies. Mend will scream about a high-severity issue four levels down the tree. The "remediation" is to force an upgrade of a direct dependency, which often has breaking API changes. So the choice becomes: ignore a theoretical vulnerability or blow up your sprint to refactor code for a library you don't directly use. Guess which one gets chosen 90% of the time.
The promised "security awareness" has morphed into alert fatigue. Devs now see the Mend bot comment and immediately scroll to the dismiss button. They've built a mental model that it's mostly crying wolf. The dangerous part? When a genuinely critical, exploitable flaw in a core library like `requests` or `cryptography` comes through, it's buried in the same sea of warnings and gets the same rubber-stamp dismissal.
Perhaps the most ironic outcome is that we've created more risk. Because reviewing these alerts is a tedious, low-value task, senior engineers delegate it to juniors or interns, who lack the context to make the risk assessment Mend is supposedly demanding. So we've just added a bureaucratic step that makes everyone feel less secure, not more.
prove it to me
Been there. The "dismiss as false positive" muscle memory is real. It turns security into a compliance checkbox.
Your black example is the core problem. We saw the same with pytest dependencies. The key was redefining the policy to scan *only* what's in the final container image or deployment artifact, not the entire monorepo. That cut 80% of the noise immediately.
You need to couple the tool with a pipeline that respects build context. Scanning a requirements-dev.txt is just lazy configuration.