Yes. Convention plugins, buildSrc and build-logic are code that runs on every developer machine and CI job, with direct access to the Gradle API. A change there can alter repositories, versions and tasks for the whole build. Give those directories the same review rules, owners and scanning as application code.
What these pieces are
Gradle's docs describe convention plugins as build script files, such as a java-common-conventions file, applied as plugins in subprojects. They hold shared dependencies and configuration so a change is made once.
buildSrc is a special directory in the root project. Gradle treats it as an independent build, compiles it before evaluating other build scripts, and puts its compiled classes on the classpath of all build scripts. Only one is allowed per multi-project build.
build-logic is a standalone build, usually a directory of that name, included through the settings file. It does the same job as buildSrc through a different door.
Why this deserves review
Because the code is shared by every subproject, it is an efficient place to hide a mistake or a malicious change. A single edit can add a repository, loosen a dependency rule or add a task that runs on every build. The Gradle docs also advise against cross-project configuration with allprojects and subprojects because it hides injected logic, and suggest convention plugins instead. That is good for clarity, and it also gives you one place to watch.
Controls to add
- Code owners. Assign a small group as required reviewers for buildSrc, build-logic and the settings file.
- No silent repository changes. Flag any diff in these directories that touches a repositories or pluginManagement block.
- Pinned versions. Pin the plugins and libraries that build logic itself depends on, and lock or verify them.
- Scan it. Build logic has its own dependencies. Include the directory in dependency scanning and SBOM generation so those components are not invisible.
- Keep it boring. Avoid network calls, file writes outside the build directory, and reading secrets in build logic unless there is a documented reason.
- Test changes in a throwaway branch with a clean cache before merging.
What to look for in a diff
| Diff pattern | Question to ask |
|---|---|
| New repository URL | Who owns it, and is it filtered to specific groups? |
| New plugin or classpath entry | Who maintains it, and why is it needed? |
| Exec, download or file write code | Does it need to run on every build? |
| Version loosened to a range or plus | Why is the pin being removed? |
| Credentials or environment reads | Where do they go? |
A note on speed
The docs mention that changes to buildSrc invalidate the configuration phase and force all tasks to re-execute. Some teams prefer build-logic partly for that reason. Whichever you choose, the review rule is the same.
For the plugin source question, see where Gradle plugins come from, and for subproject coverage, scan Gradle multi-project builds subproject by subproject.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and see how a code scanner points to the line. Build logic is code too, so it can be scanned the same way.
Safeguard's SBOM and dependency scanning can cover build logic dependencies, and the free scan at gold.safeguard.sh/scan is a quick way to see what a repository declares.
Quick check
Is build-logic safer than buildSrc?
Not inherently. Both are code that shapes the whole build. The Gradle docs present buildSrc as the primary approach and build-logic as an alternative, so choose on structure and speed, then review either one.
Do build logic dependencies show up in an SBOM?
Only if your scanner reads those directories. Check that buildSrc or build-logic is in scope.
Sources
Last reviewed: 19 October 2026.
