// Copyright (C) 2025 Gradle, Inc.
//
// Licensed under the Creative Commons Attribution-Noncommercial-ShareAlike 4.0 International License.;
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      https://creativecommons.org/licenses/by-nc-sa/4.0/
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[security_gradle]]
= Securing Gradle Builds

Every Gradle build pulls in code from external repositories, executes tools you didn’t author, and publishes artifacts that others will trust. Each step is a potential attack surface.

For a typical Gradle build, the supply chain has three main components:

1. *Dependencies* – Libraries and plugins your project consumes.
2. *Repositories* – Where artifacts are stored and served.
3. *Build Tool* – Gradle itself.

Attacks can originate at any layer and then propagate downstream through published artifacts, transitive dependencies, or compromised tools.

Even the build tool itself is an attack vector.

image::securing-builds-1.png[]

Common issues and attacks include:

. *Dependencies*
.. Typosquatting
.. Compromised artifacts
.. Silent version drift

. *Repositories*
.. Using unauthorized public repositories
.. Leaking secure package names
.. Artifacts from unauthenticated repositories

. *Build Tool*
.. Poisoned caches
.. Compromised CI
.. Compromised wrapper

Gradle provides features to harden each part of this chain:

1. *Dependencies* – Validate libraries and plugins using checksums and signatures.
2. *Repositories* – Centralize repository definitions and use trusted mirrors.
3. *Build Tool* – Verify the Gradle distribution and Wrapper JAR file using checksums.
