StepSecurity now supports cooldown and group attributes for Dependabot configuration management. These additions give organizations precise control over how dependency updates are batched and how frequently they arrive, across npm, pip, Docker, GitHub Actions, and other Dependabot supported ecosystems.
If you are already familiar with StepSecurity's npm Package Cooldown check, which blocks PRs that introduce recently published packages, think of this as the other half of the cooldown story. The npm Package Cooldown check controls when a new package version is safe to adopt. Dependabot cooldown controls how often update PRs are proposed in the first place. Together, they give organizations a complete framework for managing the pace and safety of dependency updates.
The group attribute lets you define rules for combining related dependency updates into one PR instead of many. You can group by update type (minor and patch together), by package name patterns, or by dependency scope.
A typical setup might batch all non-major production dependency updates into a single weekly PR, while keeping major version bumps as individual PRs for closer review. This works across all ecosystems Dependabot supports.
The cooldown attribute controls the minimum interval between new Dependabot PRs. Instead of receiving every update the moment it is available, you set a cadence that matches your team's capacity to review.
This prevents the common scenario where a burst of transitive dependency updates floods your PR queue and causes your team to stop reviewing dependency PRs altogether.
Both attributes are available through StepSecurity's centralized Dependabot configuration. You can define grouping and cooldown policies once and apply them consistently across every repository in your organization. StepSecurity can also automatically generate or enhance dependabot.yml files for repositories that lack proper configuration.
StepSecurity already offers the npm Package Cooldown check as part of its GitHub Checks suite. That feature serves a different but complementary purpose.
The npm Package Cooldown check is a PR-level security gate. When a pull request introduces or updates a dependency to a version published within a configurable window (default: 2 days), the check fails and blocks the merge. The logic is straightforward: most supply chain attacks are discovered within the first 24 hours of a malicious package being published. A short waiting period before adoption dramatically reduces the risk of pulling in a compromised version before anyone has had time to flag it.
This proved its value during the Shai-Hulud attack in 2025. When compromised npm packages were published, the cooldown check automatically failed PRs that attempted to adopt the malicious versions, because they had been published only hours earlier. Customers with cooldown enabled were fully shielded from accidentally merging the malicious updates.
The new Dependabot cooldown serves a different layer of the same problem. Where the npm Package Cooldown check asks "is this specific package version old enough to be trusted?", Dependabot cooldown asks "is this team receiving updates at a pace they can actually process?" One is a security gate on individual packages. The other is a workflow control on the volume of proposed changes.
They work together. Dependabot cooldown ensures your team is not overwhelmed with update PRs, so they actually review the ones that arrive. The npm Package Cooldown check ensures that the versions in those PRs have been published long enough to have been vetted by the ecosystem. Between the two, you get sustainable update velocity with a built-in safety net against freshly compromised packages.
March 2026 was one of the most active months for software supply chain attacks in recent memory. Our team detected and responded to a series of incidents that hit in rapid succession.
TeamPCP compromised 76 of 77 version tags of the Trivy GitHub Action, embedding credential stealers that harvested secrets from CI/CD runners. Days later, the Checkmarx KICS GitHub Action was hit with the same playbook. The stolen npm tokens from those compromised pipelines fueled CanisterWorm, a self-propagating npm worm that published backdoored patch versions across every namespace it could reach, including 16+ packages in the @opengov scope. The same threat actor planted credential stealers in the litellm and telnyx PyPI packages using WAV steganography.
Then came the axios compromise. A state-sponsored actor, later attributed to North Korean group UNC1069, hijacked the most popular HTTP client on npm. Over 100 million weekly downloads. Malicious versions published with a hidden dependency that dropped a cross-platform remote access trojan. When we created GitHub issues to warn the community, the attacker used the compromised maintainer's account to delete them roughly 20 times before GitHub suspended the account.
Every one of these attacks targeted dependency trust. And in every case, the organizations best positioned to respond were those with current dependency trees and functioning update workflows. They could immediately answer the question: what versions are we running, and are any of them compromised?
Organizations where Dependabot PRs had been piling up unreviewed for weeks could not answer that question.
Dependabot is widely enabled. It is not widely effective.
Without grouping, a modest repository can generate dozens of individual PRs per week. A minor bump to a test utility gets the same treatment as a critical security patch. The signal-to-noise ratio collapses, and developers stop reviewing dependency updates entirely.
Without cooldown controls, updates arrive on Dependabot's default schedule regardless of whether anyone has capacity to review them. After a period of inactivity or a cascade of transitive updates, the queue becomes unmanageable. Teams mute the notifications, close the PRs in bulk, or disable Dependabot.
The result is the worst possible outcome: the tool is technically enabled, but no updates are getting merged. Patch velocity drops. Known vulnerabilities sit unaddressed. And when the next supply chain incident hits, the organization has no clear picture of its dependency state.
This is the gap that group and cooldown close. Grouping reduces volume so each PR gets actual attention. Cooldown makes the flow sustainable so teams keep reviewing instead of giving up.
When an attack like CanisterWorm targets patch versions specifically because they get auto-installed silently, you need your team to be reviewing patch updates, not ignoring them because there are forty identical-looking PRs in the queue. And when those grouped, paced PRs arrive, the npm Package Cooldown check is there as the final safety net, blocking any version that was published too recently to be trusted.
If you are already using StepSecurity Policy Driven PRs in your configuration, you can update the Dependabot configuration to include the cooldown and group attributes
This interactive demo walks through configuring cooldown and group attributes for a repository using Policy Driven PRs
If you have repositories without a dependabot.yml file, StepSecurity can generate one with grouping and cooldown policies already configured.
If you have not yet enabled the npm Package Cooldown check, you can do so under GitHub Checks in your StepSecurity dashboard. The default cooldown window is 2 days, configurable between 1 and 30 days based on your organization's risk tolerance. We recommend enabling both the Dependabot cooldown for workflow pacing and the npm Package Cooldown check for package-level safety.
If you are not yet using StepSecurity, you can start free or request a demo to see how these capabilities fit into your supply chain security strategy.
Detection matters. We proved that over the past month with axios, CanisterWorm, and the rest. But detection is reactive by definition. The upstream discipline of keeping dependencies current, reviewing updates consistently, and maintaining visibility into what versions are running across your organization is what determines how exposed you are before an incident and how fast you recover after one.
StepSecurity now covers the full dependency update lifecycle. Dependabot group and cooldown ensure updates arrive at a manageable pace and in a reviewable format. The npm Package Cooldown check ensures that the versions being proposed have been published long enough to be vetted. The npm Package Compromised Updates check blocks versions that are known to be malicious. And when an incident does happen, npm Package Search tells you exactly which repositories are affected.
Dependency management is not overhead. It is a security control. These enhancements are designed to make it one that actually works.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。