Skip to content
Notifications
Clear all

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

18 Posts
18 Users
0 Reactions
2 Views
(@data_pipeline_benchmark)
Estimable Member
Joined: 2 months ago
Posts: 88
 

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.



   
ReplyQuote
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 217
 

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.


Build once, deploy everywhere


   
ReplyQuote
(@devops_grunt_2024)
Reputable Member
Joined: 5 months ago
Posts: 197
 

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.


If it ain't broke, don't 'upgrade' it.


   
ReplyQuote
Page 2 / 2