Vibe check your vibe code! Signals for safer dependencies from deps.dev
Modern software development relies heavily on the open-source ecosystem. Releasing software at scale means managing an increasingly complex web of third-party dependencies. While this accelerates innovation, it also introduces significant supply chain risks that can be difficult to track manually.
Today, we are incredibly excited to announce the launch of GOSSIP signals (Google Open Source Security Intelligence Platform) into the deps.dev API, providing security and dependency health findings. These signals are already used internally, including powering security integrations for Antigravity. We’re excited to be publishing them publicly, to power wider security improvements!
Whether you are a maintainer trying to keep your project clean, an enterprise consumer navigating a sea of dependencies, or an AI developer trying to make sure your LLM isn’t hallucinating you into trouble, GOSSIP signals are here to help you make safer dependency choices.
Signals
The new GOSSIP signals available through the deps.dev API are:
Dynamic Cooldown
When a new package version is released, it is often picked up by dependency algorithms immediately. But there is often a lag between a version’s release time and when security tools or manual reviewers can thoroughly inspect it. Malicious actors frequently exploit this window.
A ‘cooldown’, sometimes known as minimumReleaseAge, stabilityDays,
exclude-newer, soakTime, or bakingDelay, is a holding period during which that
version shouldn’t be used. Essentially, this signal flags and holds new
releases, giving security researchers and automated tooling time to run checks,
analyse code, and spot anomalies.
But a blanket delay can cause other problems. There are some instances when it pays to update quickly. Vulnerability patches for critical CVEs are one such important example. You don’t want a cooldown period delaying you from patching security vulnerabilities and hindering your ability to meet vulnerability SLOs.
This is where a Dynamic Cooldown can help. We modify the length of a package version’s cooldown based on a number of factors, including ecosystem, metadata, vulnerabilities, and patch information.
We prioritise critical patches for expedited scanning, and reduce the cooldown
time in certain cases, marking them with the PATCH_VERSION signal. This can
help determine whether a rapid update is a necessary security fix or an
unnecessary risk.
Malicious Packages
If a package or version has been flagged as malicious by the security community
through the OSSF Malicious Packages Project, GOSSIP flags it as MALICIOUS,
and extends the cooldown infinitely, to prevent people from using it.
Packages with Critical Vulnerabilities
When an open-source package is found to have a critical vulnerability affecting
it, it becomes a high-priority target for malicious actors looking to exploit
known security gaps. We mark versions affected by critical vulnerabilities as
VULNERABLE.
Low-Usage Packages
High usage doesn’t inherently mean a package is safe, but low usage is a statistical risk factor. Fewer eyes on the code means fewer people to notice when something goes wrong. For very low usage packages, it’s also possible that that package isn’t actually the one you intended, but is instead a similarly named package (or a typosquatting attempt).
The rise of AI-assisted coding has introduced a novel risk here: LLM hallucinations. Large Language Models occasionally generate code containing fictitious package names that sound plausible. Malicious actors actively monitor for these patterns and register these hallucinated names. Essentially typosquatting, but slopsquatting.
GOSSIP identifies packages with suspiciously low usage that look almost identical to highly popular packages, and suggests the popular alternatives you probably meant to install. GOSSIP signals act as a validation layer for AI-generated manifests, allowing automated pipelines to verify whether a suggested package actually exists, examine its usage history, and assess its accumulated risk before execution.
Not every package identified as LOW_USAGE will be bad, however. Some packages
are new, niche, or could even be your own libraries. LOW_USAGE is intended as
a broad-strokes preventative measure to encourage extra verification.
Archived Packages
When an open-source project is archived, deprecated, or abandoned by its maintainers, it rarely disappears from downstream dependency trees immediately.
An archived status has serious security implications. If a critical vulnerability is discovered in an abandoned package, it is highly unlikely to receive an official patch. This creates a compounding risk profile over time. GOSSIP highlights these inactive projects so teams can proactively plan migrations to viable, actively maintained alternatives.
Get started with GOSSIP
To get started, check out our technical documentation to integrate the GOSSIP signals into your existing supply chain verification workflows. Or take a look at the SKILL.md file on the deps.dev GitHub repository for an agent-centric implementation guide.
Stay tuned for upcoming ecosystem integrations, and if you have questions, comments, or ideas, stay in touch! We’re excited to see your ideas, implementations, and iterations!