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

The "actual, executable playbook" you're asking for is exactly what I've automated. My process runs in a CI stage triggered when Aider touches any dependency file.

The playbook is a hardened pipeline:
1. `pip install` the new requirement into a fresh, ephemeral container.
2. Run `pip-audit` and `safety check` to get the automated CVE baseline. This fails the build on any criticals.
3. My own script then hits the PyPI API to pull the release history and downloads the last three months of releases for the package and its direct dependencies, feeding them into a local tool that looks for sudden author changes or contributor drop-off. It outputs a simple bus factor score.
4. The final report gets appended to the pull request. If the bus factor is 1 or the last release is >18 months with open critical issues, it's a hard stop.

The key is baking the social check into the same automated flow as the security scan. It treats the project's health as a first-class vulnerability.

Your immediate red flags list is the right instinct, but automating the manual checks is the only way to scale. You can't be the human-in-the-loop for every `package-of-the-day`.

Take that manual package age check and bake it into your PR gates. A small script that rejects any suggested dependency with its last release older than, say, 18 months unless it's a foundational library. That filters out the stale garbage immediately.

For the attack surface paranoia, you need a concrete rule for your domain. For a lead routing system, I'd auto-reject any new dependency that introduces network I/O or data serialization unless it's from a vetted, enterprise-backed project. Let Aider suggest `flask-socketio`, but your pipeline should flag it for mandatory manual review because it opens a websocket layer.

Your "unsustainable" process is the whole point. It's supposed to be painful. That pain is your brain telling you not to let an LLM make architectural decisions.

You can't automate away the core problem. Aider's suggestion for `flask-socketio` is a perfect example of a model seeing a pattern and replicating it, with zero understanding of your "lead routing" context. Automating CVE checks after the fact just gives you a false sense of security about a dependency you never needed.

The real step one is asking why it needs a library at all. Half the time it's suggesting a sledgehammer for a thumbtack job because that's what it saw on Stack Overflow in 2020. Push back. Tell it to use the stdlib. When it insists, that's your cue to turn it off and write the fifteen lines of code yourself.

That's the core tension, isn't it? The pain tells you to stop the process, but you still need a scalable *method* for that stop. You can't rely on everyone having the same instinct.

The `flask-socketio` example is perfect. The architectural mismatch is the real vulnerability, long before any CVE scan. A rule like "any suggestion for real-time comms in a batch lead system triggers an immediate manual review" is more valuable than an automated security pass. It codifies the "why do we need this?" question into a gate.

Exactly. The "why do we need this?" gate is what separates a review from just a checklist. Your example rule about real-time comms is spot on.

We tried a similar rule for auth packages. Any suggestion to bring in `flask-login` or `PyJWT` triggers a mandatory design review, because adding a new auth flow has huge implications for our session management. It's not about the package's CVEs, it's about our architectural boundaries.

The trick is keeping these rules lightweight. If the review process becomes a multi-hour meeting, people will just try to sneak the dependency past the bot.

You've hit on the critical friction point with these tools: they suggest dependencies the same way a chef tosses salt over their shoulder, based on habit not on your specific kitchen.

Your "immediate red flags" manual step is where you need to start codifying. You can't keep doing it by hand. That unsustainable feeling means your gut check needs to become a written rule, like others have mentioned. For lead routing, your rule might be "no new network I/O libraries without an architectural review."

Your revenue ops background is actually the perfect lens here. Treat each dependency suggestion like a new vendor onboarding. You wouldn't sign a contract without checking their financials and support SLA. The package's bus factor and release cadence are the engineering equivalent.

The vendor analogy is exactly right. A bus factor of one is the same as a single-point-of-failure vendor with no support staff. You wouldn't accept that contract, so don't accept that dependency.

But the vendor check doesn't stop at financials. You need to understand their roadmap and sunset policy. A package that hasn't had a release in 18 months is a vendor who stopped answering your emails. The code might work today, but you're now responsible for its security and compatibility indefinitely.

The architectural review rule is the equivalent of a procurement clause. Just like you'd require legal review for any contract touching customer data, you require a design review for any dependency touching network I/O. It formalizes the gut check.

Your vendor analogy in the following posts is the precise operational framework you need. The issue is you're still performing those manual checks post-suggestion, which creates the unsustainable bottleneck. The playbook must start earlier.

You need to embed your red flags into the context window of the AI tool itself. Before Aider even generates a suggestion, it should be operating with your procurement rules. This is a prompt engineering and retrieval-augmented generation problem. I maintain a curated, internal knowledge base of approved libraries and architectural principles that's injected as context. When Aider suggests a dependency, it's already been nudged by your own policy.

For example, the rule "no new network I/O libraries" should be a vector in your RAG system, causing the model to preferentially suggest `concurrent.futures` over `celery` for a background task, because it knows your system's profile. The vetting isn't a separate step, it's a precondition that shapes the suggestion. The manual process you described should only fire for truly novel suggestions that fall outside your pre-loaded policy.

Injecting the rules into the context is the dream, but my experience with RAG for this has been...patchy. The model gets nudged, sure, but it still hallucinates or creatively reinterprets the constraints.

We built a similar pre-flight layer that categorizes suggestions against a policy file. It still let `httpx` through as a "networking" library when the rule was "no new *server* networking libraries," because the model argued it was for *client* calls. The nuance bled right through.

Your approach moves the bottleneck upstream, which is smart, but now your bottleneck is maintaining and curating that internal knowledge base. Who's responsible when the policy vector is outdated and it nudges the model towards a deprecated lib? It's a different kind of toil.

You've pinpointed the core failure mode of the RAG approach: semantic drift. The model isn't parsing your policy as logic, it's treating it as another pattern to optimize against. Your `httpx` example is perfect - it performed a grammatical loophole exploit because "server networking" was a syntactic constraint, not a semantic one in the model's latent space.

This is why I treat such systems as stochastic policy engines, not deterministic ones. They require the same validation as their outputs. The maintenance burden you mention is the cost of that stochasticity - you now need a feedback loop to audit the model's interpretation of your rules, not just the rules themselves.

Who's responsible? The same team that owns the dependency review process. You've just shifted their work from scanning CVEs to scanning the classifier's training data and inference logs for policy drift. It's a more complex, but arguably more foundational, form of toil.