Use platform() when you want a BOM's versions as recommendations that other dependencies may raise, which suits libraries. Use enforcedPlatform() when you want every BOM version pinned as strictly, which suits applications. Gradle's docs warn against enforcedPlatform in libraries because strict versions propagate to consumers.
What a platform is
A Gradle platform is a set of dependency constraints. You can write one with the java-platform plugin or import a published BOM, since Gradle can import any POM that has a dependencyManagement block and treats each entry as a constraint.
The difference in one table
| Aspect | platform() | enforcedPlatform() |
|---|---|---|
| Versions | Recommendations | Strict |
| Can transitive dependencies raise them? | Yes | No |
| Propagates strict versions to consumers? | No, normal recommendations | Yes |
| Typical use | Libraries and shared platforms | Applications |
With platform(), strictly constraints inside the BOM still apply, because Gradle endorses strict versions by default. You can opt out with doNotEndorseStrictVersions.
Why this matters for security
Imagine a vulnerability fixed in a later release. With platform(), a transitive dependency that asks for the fixed version wins, so the graph can move forward on its own. With enforcedPlatform(), nothing can move past the BOM, so the BOM itself must be updated. That is a feature if you want tight control and a risk if the BOM goes stale.
Here is the code from the Gradle docs for the strict case:
dependencies {
implementation(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE"))
implementation("com.google.code.gson:gson")
// Overridden by the version in the BOM
implementation("org.codehaus.groovy:groovy:1.8.6")
}
An old BOM version enforced like this holds old versions in place. Review the BOM version on a schedule.
A pitfall with partial overrides
The docs show a case where a BOM is imported with platform() and one module is overridden with a strictly range. That module moves to the newer version, but sibling modules from the same family can stay on the older BOM version, leaving mismatched versions in one group. The fix is to upgrade the BOM or use enforcedPlatform() with the newer BOM.
Check what you got
Run dependencyInsight for the module. For enforced versions, Gradle shows a strictly annotation next to the version. See why was this version selected for how to read the output, and force a patched transitive version with constraints for the lighter option.
Decision steps
- Are you publishing a library? Use platform().
- Building an application and want fixed versions? Use enforcedPlatform() and calendar a BOM review.
- Need only a patch for one module? Prefer a constraint over a platform.
- After any change, run dependencyInsight and a vulnerability scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Find a finding that has a fixed version and note which version it asks you to move to. That is the number to reflect in your BOM.
Safeguard's dependency scanning flags vulnerable versions, and autonomous remediation can open fix pull requests, which is off by default with every category set to Manual. The free scan is at gold.safeguard.sh/scan.
Quick check
Does a version catalog replace a platform?
No. Gradle's docs say catalogs centralize coordinates but, unlike platforms, do not affect dependency resolution.
Can I use enforcedPlatform in a library?
The docs advise against it, because the strict versions propagate to everyone who depends on your library.
Sources
Last reviewed: 19 October 2026.