# Introducing the Gradle Security Subscription

DevFeed: [Introducing the Gradle Security Subscription](<https://devfeed.tech/articles/introducing-the-gradle-security-subscription-24634.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-security-subscription>)

Author: Gradle Build Tool

Published: 2026-08-31T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Security](<https://devfeed.tech/topics/security.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>)

Tags: [gradle](<https://devfeed.tech/tags/gradle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [releases](<https://devfeed.tech/tags/releases.md>), [security](<https://devfeed.tech/tags/security.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

## AI overview

Gradle announces the Gradle Security Subscription, which provides security fixes under a service-level agreement, maintenance for Gradle versions beyond the open source end-of-life policy, and advance notice of newly discovered vulnerabilities. The article explains build-tool security risks and argues that the subscription does not change the open source community offering.

## Source excerpt

The Gradle Security Subscription is available today. It provides security fixes under a service-level agreement, security maintenance for Gradle versions beyond the open source end-of-life policy, and advance notice of newly discovered vulnerabilities ahead of public disclosure. Coverage details are on our subscription page. The rest of this post explains why the subscription is important and what changes for the open source community (in short, nothing). The toolchain as an attack surface In 1984, while accepting the Turing Award, Ken Thompson described a compiler he had modified to insert a backdoor into the programs it compiled. Reviewing the source of the affected program revealed nothing. And reviewing the source of the compiler revealed nothing either. His conclusion was that you cannot fully trust code you did not create entirely yourself. Four decades later, we find ourselves facing the same dilemma. Software composition analysis scans the dependencies a project declares. Static analysis scans the source a team writes. But neither examines the build tool that turns that source and those dependencies into the artifact that goes to production. This gap has been exploited repeatedly. In 2015, XcodeGhost distributed a modified version of Apple's IDE that inserted malicious code into every application compiled with it, reaching thousands of App Store applications whose developers had written nothing malicious. In 2020, SolarWinds released a compromised version of their IT software, but the attackers modified no source code. They gained access to the build environment and installed malware that monitored the compilation process, injecting a backdoor into the resulting binary as it was produced. Approximately 18,000 organizations installed the signed update, including the U.S. Departments of Treasury, State, Defense, and Homeland Security. There are two more recent incidents. The Codecov Bash Uploader compromise ran undetected for roughly two months in 2021, exfilt