Hi everyone. I’ve been using Mend (we still call it WhiteSource internally) for about six months now, mostly scanning our Python-based data pipelines and some dbt projects. I was put in charge of monitoring the dashboard because my team thought it would be "low risk" for me to learn on.
Honestly, I'm feeling a bit overwhelmed and I'm not sure what I should actually be acting on. My main worry is flagging something as urgent that ends up being a false positive and derailing the team for no reason.
Our dashboard shows a ton of "High" severity vulnerabilities, but when I drill down, many are in transitive dependencies or in libraries that our pipelines import but don't actively use in a vulnerable way (like a CLI tool imported for a single helper function). For example, we had a high severity in `urllib3`, but our use case is all internal, behind the firewall, and doesn't touch the affected component.
My question is: how do you all separate the signal from the noise? Is there a safe process you follow before creating a ticket for the data engineering team?
I'm trying to set up some filters, but I'm nervous about being too aggressive and letting something real slip through. Our current setup in the pipeline is just the basic scan step:
```yaml
- name: Mend SAST Scan
uses: mend-tech/action-sast-scan@v1
with:
mendApiKey: ${{ secrets.MEND_API_KEY }}
mendProjectName: ${{ github.event.repository.name }}
```
Should we be adding more granular configuration? Maybe via a `whitesource.config` file? I’d love to hear about any safe patterns or triage workflows that have worked for you, especially in a data engineering context where some dependencies are just for data processing and not external-facing services.
The feeling of being overwhelmed is very common when you first inherit a dashboard like this, especially with the volume of findings in dynamic ecosystems like Python's. Your instinct about not wanting to derail the team with false positives is correct and shows good judgment.
Your observation about transitive dependencies and imported-but-unused libraries touches on a core challenge. Many teams develop a "reachability" or "exploitability" assessment as a first filter. Before creating a ticket, ask: is the vulnerable function actually called by our code, or is the library merely present? For internal, firewalled services, the risk profile for something like a urllib3 vulnerability might be fundamentally different than for an external-facing web application, though you must consider defense in depth.
A safe starting process could be to, for any "High" finding, briefly document your contextual risk assessment in the ticket itself. Something like "High severity in urllib3, version X.Y.Z. Scanned service is an internal data pipeline with no user input flowing to the affected component." This shows due diligence and provides rationale if the team decides to defer the fix. It also creates a paper trail that can be reviewed later, which is valuable for audit purposes and for refining your filters over time.
Let's keep it constructive