What to look out for today
If your business builds software (or has a website/app maintained by a third party), check how you handle automated dependency updates from GitHub Dependabot. GitHub has introduced a new option to wait at least three days after a package release before Dependabot opens an update pull request, intended to reduce adoption of potentially poisoned releases.
Why this matters to smaller businesses
Small teams often rely on automation to keep code up to date. That saves time, but it can also mean you pull in a brand-new library release before the wider community has spotted issues. If a harmful release gets adopted, it can create knock-on problems like data exposure, service disruption, or emergency rebuilds—especially if your site/app is business-critical.
Warning signs
- A sudden spike in dependency update pull requests, especially for less well-known packages.
- Updates that arrive immediately after a new version is published ("same day" updates).
- Updates that change a dependency in a way that seems unrelated to what you use it for (odd rename/replacement patterns).
- Pressure to merge “green tick” updates quickly without review because they look routine.
How attackers may exploit the situation
- Publish a malicious (or compromised) open-source package release and rely on automated tools to spread it quickly via “routine” update PRs.
- Target smaller teams and outsourced web/app maintainers who may have lighter review processes and merge updates faster.
- Exploit trust in automation (e.g., “Dependabot suggested it, so it must be safe”).
What to do today
- Confirm whether you use Dependabot (directly or via your web/app supplier).
- Set/confirm a cooldown policy for dependency updates so you’re not adopting brand-new releases immediately, unless there’s a clear business reason.
- Require human review for dependency updates before merging (even if tests pass).
- Prioritise critical systems: treat your customer-facing website/app, payment flows and integrations as higher risk—slower, more careful updates.
Ask your IT provider
- Do you use GitHub Dependabot (or similar) on our repositories, website, or apps?
- What cooldown or “minimum age” do you apply before taking dependency updates?
- What’s your review process for automated update PRs (who approves, what checks are done)?
- If a dependency release later turns out to be unsafe, how quickly can you roll back and verify we weren’t impacted?
Patch watch - only one short paragraph, and only if relevant
This isn’t a traditional “patch now” item. It’s about avoiding rushed adoption of newly released third-party code through automation. Treat dependency updates as a supplier-risk decision: update promptly when needed, but with sensible delay and review.
One action today
Check (or ask your supplier) whether Dependabot is enabled and set a policy to delay routine dependency update PRs so they aren’t merged immediately after a new release.
Related Actions On Cyber resource
Actions On Cyber checklist: “Supplier & SaaS security questions (for web/app and IT providers)”
Sources
- GitHub Adds 3-Day Dependabot Cooldown to Limit Poisoned Package Adoption (The Hacker News)
This brief is for general awareness and does not replace advice from your IT provider, legal adviser, insurer or incident response specialist.