In the Safeguard JetBrains plugin, choose Balanced for everyday fixes, Safe when a release is close, and Aggressive only on a throwaway branch with good tests. Safe means minor version updates only, Balanced means minor and patch updates, and Aggressive means the latest available version. You review the diff before anything is applied.
Where do the strategies appear?
Per Safeguard's IDE support documentation, you place the cursor on a flagged dependency, press Alt plus Enter (Option plus Return on a Mac) and choose Fix with Safeguard AI. The plugin then asks for a strategy and shows a diff. To fix a whole package or project, right-click its node in the Safeguard tool window and choose Fix All Vulnerabilities. Balanced is the documented default.
The plugin covers IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, Rider, GoLand, RubyMine, CLion, DataGrip and Android Studio, from IDE version 2023.3 with JDK 17 or later.
How do the three strategies differ in practice?
The docs define the strategies in one line each. Here is what those definitions mean when you are the one who has to ship.
Safe: minor updates only. The documentation's wording is minor version updates. Choose it when you cannot afford surprises: a release freeze, a service with thin tests, or a dependency you suspect is fragile. The cost is that some fixes will not be on offer, because the patched version may sit outside the allowed range. When that happens, the finding stays open and you need a deliberate decision, not a quiet bump.
Balanced: minor and patch updates. This covers most vulnerability fixes, since maintainers often backport security fixes into patch or minor releases. It is a sensible default because the set of changes is limited to versions that should stay compatible.
Aggressive: the latest available version. This can cross a major version. That can fix a vulnerability that has no backport, and it can also break your build. Use it where you can afford to find out: a feature branch, a service with strong tests, a dependency you were going to upgrade anyway.
A note on wording: "should stay compatible" is the expectation of semantic versioning, not a guarantee. Maintainers sometimes break things in minor releases. The tests, not the label, decide.
A simple decision table
| Situation | Strategy | Why |
|---|---|---|
| Normal weekly cleanup | Balanced | Limited change, most fixes available |
| Release in a few days | Safe | Minimal risk of behavior change |
| No minor or patch fix exists | Aggressive, on a branch | A major bump may be the sole path |
| Library with weak tests | Safe, then manual | Tests cannot catch a bad upgrade |
| Dependency already due for upgrade | Aggressive | You are paying the cost anyway |
What should you check in the diff?
Do not approve a diff because the tool produced it. Look at:
- Which files changed. The manifest and lockfile are expected. Anything else needs a reason.
- Version jumps. A major jump needs a read of the changelog.
- Transitive changes. A lockfile can move several packages for one fix.
- Peer dependencies. A new version may require a newer framework version.
Then run your tests before you commit. If you use a pull request workflow, remember the plugin is not a merge gate: the JetBrains docs describe scanning, viewing and fixing, so enforcement belongs in CI or in a review step.
What about VS Code and Cursor?
The extension for VS Code and Cursor uses the same three names through a setting called safeguard.remediationStrategy, defaulting to balanced. It also has a setting that applies fixes on save, which the docs say to enable with caution. Do not turn that on in a repository you have not tested with automated fixes.
What to do
- Keep Balanced as the team default.
- Switch to Safe during release freezes and write the reason in the pull request.
- Use Aggressive only on a branch, with the full test suite.
- Read every diff, especially version jumps and lockfile changes.
- Run tests before committing.
Quick check
What is the default fix strategy?
Balanced, which allows minor and patch updates, per Safeguard's IDE support docs.
Does Aggressive always pick a major version?
It picks the latest available version, which may or may not be a major jump. Read the diff to see.
Sources
Last reviewed: 18 October 2026.
