Don't Wait for a Package Attack to Protect Your Team
The LiteLLM package compromise shows why software updates, safe builds, and access protection must be routine leadership priorities.
By Julian
Installing a package is easy. Most developers see it as a routine task. Trusting it is just as easy, and that's the problem.
It runs where your credentials live, on your development machine, with access to your internal systems, inside your VPN and with browser credentials convenient in one file, so it can see what your process can see.
The OSV advisory MAL-2026-2144 names three compromised litellm releases: 1.82.7, 1.82.8, and 1.107.0.
All of these releases install a credential stealer, which can exfiltrate sensitive information from your development environment,
- SSH keys (all servers that trust those keys),
- Cloud credentials (where your infra/prod lives)
- Browser-stored passwords (passwords to all internal or external apps that are stored there)
- Application-specific credentials
What leaders should do now
Put an owner on it at C level or just below. Create and enforce security policies, assign clear responsibilities, and ensure accountability for maintaining a secure development environment.
Never assume that your development environment is inherently safe or that developers will always follow best practices without oversight. \
Lead engineers make it routine: dependencies update on schedule, dev environments that are sandboxed or away from critical data (including SSH key and browser stores) and vulnerability and package-integrity checks run in every pull request, check what your developers are doing and guide them accordingly, and enforce security best practices consistently.
Ensure all access to sensitive systems is tightly controlled, monitored and never exposed to the internet.
This is not only to protect your compnay & company assets, but also to safeguard your developers and customers from potential security incidents.
Isolate the work where packages actually run
Day work stays in disposable dev containers or github codespaces or virtual machines.
NEVER let someone install untrusted packages on a machine that has access to sensitive data or credentials.
Always assume that any environment where untrusted code runs could be compromised and take steps to limit its reach and impact.
Protect access to your systems
- Audit who access which system
- Make sure you can revoke and rotate credentials quickly when needed
- Make sure you always know which users have access to which systems and what level of access they possess
- Regularly review and update access controls to ensure that only authorized personnel have the necessary permissions
- Enforce the principle of least privilege, ensuring users have only the access necessary to perform their tasks
- Use multifactor authentication (MFA) wherever possible to add an extra layer of security beyond just passwords
How we protect our developers and our customers at Flotte
Security for Flotte is one of our top priorities and is deeply integrated into our development and operational processes.
We keep dependencies current and scan them automatically, with AI-assisted review (we use strix and anthropic harness).
Build systems get small permissions, we monitor dependencies, enforce strict access controls, all our developer work in disposable environments, so even if compormises occur, the impact is contained (and no third party can publish malicious code or version of our software).
We also review all code atleast once before it is merged, ensuring that multiple sets of eyes have evaluated changes for potential security risks and adherence to our internal standards and we use automated tools to catch common security issues and enforce coding best practices.
Put it on paper
Other useful references: