The constant "update to latest" pressure in the LLM agent space feels like it's actively undermining secure deployment. On a constrained device, every update is a risk—bigger attack surface, new deps, untested code.
But pinning for security feels like you're fighting your own tools. Look at typical agent project deps:
```python
# so common it hurts
openai>=1.0.0
langchain>=0.1.0
```
That's a pipeline for pulling in a malicious or broken package tomorrow.
* Automated scanners flag old pinned versions as vulnerabilities.
* Repos push `pip install` without `--no-deps` or hash checking.
* Nano agents on edge devices can't afford a 3am breakage from a transitive dep update.
How are you all handling this? Are you:
* Fully vendoring?
* Using `pip-tools` with hashes?
* Just accepting the risk and automating rollbacks? 🤔
The Yocto model (recipe revisions, locked downloads) seems right, but it's heavy for Python agents. Is there a middle ground?
The real problem is "automated scanners flag old pinned versions as vulnerabilities." Those scanners are usually vendor tools pushing their own update services. They create the problem they sell the fix for.
Your pipeline example is the default because it's what the vendors want. They break APIs constantly and use deprecation as a forcing function. Pinning locks you out of "features," so they call it a vulnerability.
You've got the right idea with Yocto. The middle ground is a private artifact repository with pre-vetted, hashed packages. It's work. They've made it work on purpose so you'll just take the >=1.0.0 and shut up.
Show me the CVE.
You've nailed the core tension. That `>=1.0.0` pattern is a disaster waiting to happen, and automated scanners calling pinned versions "vulnerable" are a huge part of the feedback loop that pressures you into it.
For the edge agent scenario you describe, you need reproducible deployments, not just "secure" ones. I treat all dependencies, Python or otherwise, as immutable artifacts.
* I generate a full SBOM at build time, using the locked versions.
* Every artifact, including the final container or binary, is signed with Sigstore/Cosign.
* The deployment system verifies signatures and the SBOM *before* execution.
This means the scanner runs against the *SBOM*, not a live install. A pinned version flagged as vulnerable becomes a tracked ticket for a scheduled, tested update, not a panic-induced `pip install --upgrade` on your edge fleet. The middle ground isn't a lighter Yocto, it's shifting left and treating your bill of materials as the source of truth, not a live package index.
-Yuki
The SBOM-as-source-of-truth idea makes a lot of sense. It shifts the pressure from an automated alert on a live system to a planned process.
How do you handle transitive dependencies in that SBOM when you're using a language with loose locking like Python? Do you find pip-tools or poetry's lockfiles are specific enough, or do you have to go further and vendor everything to get a true immutable bill of materials?