Skip to content
Notifications
Clear all

How do I vet Aider's dependency suggestions for security vulns?

2 Posts
2 Users
0 Reactions
1 Views
(@crm_hopper_2027)
Reputable Member
Joined: 2 months ago
Posts: 169
Topic starter   [#22646]

Alright, let's get this annual migration started, but this time it's not between CRMs—it's into my codebase. I've been trialing Aider for a few weeks now, and while the promise of "AI pair programming" is predictably intoxicating, I'm hitting the same old wall: trust.

Specifically, trust in its dependency suggestions.

When you ask it to build something, and it blithely suggests adding `pip install flask-socketio` or `npm install some-package-of-the-day`, what's your actual process for vetting that? My revenue ops background has left me with a permanent twitch about data integrity and attack surfaces. I can't just let a language model, trained on the entirety of GitHub's sometimes-glorious, sometimes-garbage public repos, decide what goes into the project that handles our lead routing.

So, community, I'm looking for your actual, executable playbook. The theoretical "check the CVE database" is a given. I'm talking about the gritty, repetitive steps you've automated or the mental checklist you run through before hitting 'y' to that `requirements.txt` change.

My current, admittedly paranoid, process is becoming unsustainable:

* **Immediate Red Flags:** I manually check the package name for typosquats (looking at you, `python-dateutil` vs `python-dateutill`). I look at the last release date. If it's from 2018 and the AI is suggesting it for a modern async task, I'm already skeptical.
* **The Deep Dive:** I open a separate browser, search "[package name] vulnerabilities," and skim a few results. I check the repo's issue count vs. contributor count. A thousand open issues and one maintainer? Hard pass.
* **The Integration Risk:** I then have to consider the transitive dependencies. Aider suggests `cool-tool`. `cool-tool` pulls in `ancient-library` and `bad-crypto`. Now I'm down a rabbit hole.

This defeats the purpose of the speed boost Aider is supposed to provide. I've considered a few half-baked solutions:

* Pre-seeding a `denylist.txt` of known-bad or deprecated packages for Aider to reference (does it even respect such a thing?).
* Running every suggested install in a sandbox first with `safety check` or `npm audit`, but that breaks the "flow."
* Just accepting that using this tool requires a secondary, real-time security linter in my brain, which is exhausting.

Is there a smarter way? Have you built a script that intercepts Aider's suggestions and runs them through a vulnerability scanner API before you even see them? Do you only use Aider for projects where the dependency tree is locked down from the start?

I'm here for the efficiency gains, but not if they come with a side of compromised customer data. Let's hear how you're managing this, or if you've just accepted a certain level of risk as the cost of doing business with an AI coder.



   
Quote
(@dianaf)
Estimable Member
Joined: 2 weeks ago
Posts: 110
 

Yeah, that twitch is 100% warranted. I'm newer to this but I've been forcing myself to treat Aider's suggestions like a junior dev's PR - you wouldn't approve it without a review, so why would you here?

My emerging step zero is to ask it *why* it picked that specific dependency. Sometimes it'll name alternatives it considered, which can be telling. If its reasoning is just "it's popular," that's a different signal than "this one has a smaller API surface and is actively maintained."

Beyond CVEs, I've started checking the "health" metrics that aren't always automated: last commit date vs. release date, how many open issues are security-adjacent, and the ratio of maintainers to dependents. A huge user base with two maintainers makes me sweat.

What's your threshold for stepping away from a suggestion and just writing the minimal code yourself instead?



   
ReplyQuote