# Reverse Dependencies A software dependency relationship viewed from the depended-on component: the packages or projects that rely on it. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Avoiding the Next Supply Chain Disaster with GitHub and Gradle DevFeed: [Avoiding the Next Supply Chain Disaster with GitHub and Gradle]() Original publisher: [Read original article]() Author: Tom Tresansky Published: 2026-02-25T05:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [supply-chain-security](), [Gradle](), [GitHub](), [Vulnerabilities](), [Reverse Dependencies](), [Java](), [Android](), [Maven](), [npm](), [Logging]() Tags: [dependencies](), [developers](), [github](), [gradle](), [java](), [locking](), [logging](), [npm](), [security](), [supply-chain](), [supply-chain-attacks](), [supply-chain-security](), [vulnerabilities]() ### AI overview This article explains how GitHub and Gradle can help Android and JVM developers reduce software supply-chain risk. It covers dependency drift, vulnerability exposure, resolved dependency visibility, continuous monitoring, automated fixes, and Build Scan® analysis, with Shai-Hulud and Log4Shell as examples of supply-chain threats. ### Source excerpt Supply chain security is a big deal, and it's dangerously easy to ignore. For Android or JVM developers, the sheer scale of the ecosystem is our greatest strength, and our greatest risk. When you build an application, you aren't just responsible for your own code; you're responsible for a massive, invisible tree of dependencies. This presents two distinct security challenges: Dependency Drift: Resolved dependencies can appear, disappear, or change versions without you ever touching your build.gradle.(kts) file. A bad actor can slip a malicious artifact into your dependency graph unnoticed. Vulnerability Exposure: Even locking your dependencies to avoid unexpected changes doesn't absolve you from monitoring their state. A library you've used for years might have a critical vulnerability (CVE) discovered tomorrow. We've recently seen this play out in the wild with attacks like the Shai-Hulud npm supply-chain exploit, where attackers poisoned popular packages to execute arbitrary code downstream, and the critical Log4Shell vulnerability, which demonstrated the catastrophic risk posed by an exploit in a foundational Java logging library. We recently outlined our defense against supply chain attacks in our deep dives on continuous GRC and our Nx vulnerability response. The good news: if your Gradle projects live on GitHub, you already have everything you need to minimize your known vulnerability count, without manually auditing resolved dependencies all day. In this post, we'll walk through how GitHub and Gradle work together to: Give you a complete, accurate view of your resolved dependencies Continuously monitor those dependencies for vulnerabilities Automatically propose and validate fixes Use our free Build Scan® service to understand what changed and why Why dependency monitoring is harder than it looks Unlike more traditional build tools like Maven, which rely on relatively static dependency declarations, Gradle is a dynamic, highly programmable build engine. While ## Exploitability Isn't the Answer. Breakability Is. DevFeed: [Exploitability Isn't the Answer. Breakability Is.]() Original publisher: [Read original article]() Author: Bryan Sullivan Published: 2026-02-12T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Vulnerabilities](), [Reverse Dependencies]() Tags: [ai](), [americas](), [application-security](), [awareness](), [blog](), [code-security](), [developer](), [developers](), [devops](), [devsecops](), [engineering](), [interest](), [javascript](), [node-js](), [open-source-security](), [security](), [snyk-learn](), [snyk-open-source](), [supply-chain-security](), [tech](), [updates](), [vulnerabilities](), [vulnerability-insights]() ### AI overview Snyk introduces Breakability Risk for Snyk Open Source to help developers prioritize vulnerability fixes by estimating whether dependency updates could break an application. The article argues that confidence in low-risk updates can speed remediation and reduce security debt. ### Source excerpt AppSec is often stalled by a lack of trust: will this fix break my app? Snyk's new Breakability Risk feature solves this by identifying which security updates are safe to merge and which require caution. By focusing on low-risk fixes first, developers can clear backlogs four times faster and reduce security debt without increasing their workload. ## How Chainguard Libraries for Java Secures Dependencies at Maven Central Scale DevFeed: [How Chainguard Libraries for Java Secures Dependencies at Maven Central Scale]() Original publisher: [Read original article]() Published: 2025-06-25T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard libraries](), [Java](), [Reverse Dependencies](), [Maven](), [Open Source]() Tags: [central](), [chainguard-libraries](), [chainguard-libraries-for-java](), [dependencies](), [graph](), [java](), [java-libraries](), [java-packages](), [libraries](), [maven-central](), [open-source](), [supply-chain]() ### AI overview This article explains how Chainguard is building Chainguard Libraries for Java to secure open-source JVM dependencies from Maven Central. It describes the repository's scale and the initial selection strategy, which uses dependency-graph data to identify popular libraries and prioritizes newer projects. ### Source excerpt Chainguard Libraries for Java is Chainguard's repository of malware-resistant Java dependencies. Learn how we are building and maintaining over 50,000 projects. ## Finding and fixing exposed hardcoded secrets in your GitHub project with Snyk DevFeed: [Finding and fixing exposed hardcoded secrets in your GitHub project with Snyk]() Original publisher: [Read original article]() Author: Chandler Mayo Published: 2024-06-25T17:00:00Z Content type: tutorial Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Security](), [GitHub](), [Vulnerabilities](), [Open Source](), [Node.js](), [Reverse Dependencies](), [Boilerplate]() Tags: [awareness](), [blog](), [code](), [code-security](), [dependencies](), [developer](), [devrel](), [github](), [javascript](), [node-js](), [open-source](), [secrets](), [snyk](), [snyk-code](), [vulnerabilities]() ### AI overview This tutorial explains how to use Snyk to find hardcoded secrets and credentials in a GitHub project, then refactor the code to store those secrets with Doppler. It uses the open source Snyk goof Node.js boilerplate project and also covers dependency analysis, vulnerability reporting, and automated fix pull requests. ### Source excerpt In this blog, we'll show how you can use Snyk to locate hardcoded secrets and credentials and then refactor our code to use Doppler to store those secrets instead. ## DependenTree, Graph Visualization Library DevFeed: [DependenTree, Graph Visualization Library]() Original publisher: [Read original article]() Author: Amogh Kambale Published: 2022-03-23T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Graphs](), [Library](), [Reverse Dependencies](), [API](), [data](), [Front end](), [JSON](), [Code]() Tags: [api](), [d3-js](), [data-lineage](), [dependency](), [engineering](), [front-end](), [graph](), [graphs](), [json](), [library](), [mapping](), [scale](), [visualization]() ### AI overview DependenTree is a D3.js-based visualization library for representing large dependency graphs as collapsible trees. It supports upstream and downstream dependencies, cyclic graphs, and client-side dependency mapping to avoid oversized server-to-client payloads. ### Source excerpt Visualize dependency graphs at scale ## Did I Break You? Reverse Dependency Verification DevFeed: [Did I Break You? Reverse Dependency Verification]() Original publisher: [Read original article]() Published: 2021-05-25T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Reverse Dependencies](), [Back end](), [Tooling](), [Finagle](), [Microservice](), [Rails](), [Ruby](), [Architecture & Design](), [Documentation](), [Data Science](), [Mobile](), [PWA]() Tags: [analysis](), [automation](), [backend](), [collaboration](), [configuration](), [dependency](), [development](), [engineering](), [framework](), [jvm](), [microservices](), [rails](), [reverse-dependencies](), [ruby](), [tech-stack](), [testing](), [tooling](), [verification](), [web-development]() ### AI overview SoundCloud describes how its evolving technology stack and team autonomy created fragmentation across languages, frameworks, processes, and documentation. It presents Golden Paths as opinionated, reusable recommendations that simplify development while preserving flexibility, including a JVM backend path built around Finagle and supporting tooling. ### Source excerpt SoundCloud was founded 13 years ago, and throughout its history, the company and much of its tech stack has changed. We started with a... ## Smarter dependency downgrades DevFeed: [Smarter dependency downgrades]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2020-03-12T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Maven](), [Library](), [Reverse Dependencies]() Tags: [build](), [compare](), [dependencies](), [dependency](), [gradle](), [graph](), [libraries](), [upgrade]() ### AI overview This article explains how Gradle handles transitive dependency version conflicts and why semantic version downgrades matter. It introduces Gradle 6's strict version feature and compares Gradle's dependency resolution with Maven's order-dependent behavior, using Google Guava as an example. ### Source excerpt One of the biggest challenges when dealing with transitive dependencies is to keep their versions under control. Popular libraries will show up as transitive dependencies in multiple places in your dependency graph. And it is quite likely that the version information will be different on each path. Through multiple blog posts, you have learned that Gradle offers a rich feature set for expressing complex dependency requirements. In this post, we will discuss why semantics matter when downgrading a dependency version. And you will learn about the strict version feature of Gradle 6 that provides this semantic information and effectively gives you a powerful and precise tool for dealing with this complex issue. In this post, we will use Google's Guava again as an illustrating example because: It is a very popular library, used by over 20,000 other libraries It has a complex history in terms of API stability which results in sometimes difficult upgrades in large dependency graphs In the dependency view below, taken from this build scan, we can see that many Guava versions are in play: The dependency declaration for this build is however quite simple: dependencies { implementation("org.optaplanner:optaplanner-core:7.24.0.Final") implementation("com.spotify:folsom:1.5.0") } With only two direct dependencies, we already have a conflict between four Guava versions. It will always resolve to 25.0-jre in this example. This is the result of Gradle accounting for all versions in a dependency graph and optimistically choosing the highest matching the constraints, 25.0-jre in our example. If we compare this Gradle project with a matching Maven project, we get a somewhat different result. With Maven, the first of the shortest path to a dependency will be used to determine the version. This means that, in our example, the Guava version is effectively order dependent since both libraries have a direct dependency on Guava. If com.spotify:folsom:1.5.0 is declared first in a Maven POM f ## Building Infrastructure in Parallel DevFeed: [Building Infrastructure in Parallel]() Original publisher: [Read original article]() Author: Remind Published: 2018-03-05T00:00:00Z Content type: tutorial Language: en Sources: [Remind]() Topics: [Reverse Dependencies](), [cloud-infrastructure](), [AWS CloudFormation](), [Amazon Web Services](), [Algorithms](), [Computer science](), [make](), [systemd](), [Terraform](), [coding]() Tags: [algorithms](), [building](), [cloudformation](), [computer-science](), [dependency](), [graphs](), [infrastructure](), [make](), [parallel](), [parallelism](), [postgresql](), [refactor](), [systemd](), [terraform](), [vpc]() ### AI overview This tutorial explains how Remind improved stacker, its infrastructure deployment tool, to update CloudFormation stacks in parallel. It models stack dependencies as a directed acyclic graph and reports reducing execution time from about 10 minutes to under 1.5 minutes; the change was included in stacker 1.2. ### Source excerpt In the early days of stacker at Remind, the number of stacks that we were managing was just a handful. CloudFormation stacks were updated sequentially, without any parallelism, and everyone was happy. Today, stacker manages 153 CloudFormation stacks that build out all of the AWS infrastructure that makes remind.com work. As you can imagine, attempting to update 153 stacks without any parallelism takes a long time, about 10 minutes to be precise. When you consider that most stacks don't ever change, 10 minutes feels like an eternity, and prevents a quick feedback loop. Over the last couple of weeks, I took it upon myself to refactor the core issues in stacker that made implementing parallelism difficult, and dropped our total execution time from 10 minutes, to under 1.5 minutes. This work is now included in stacker 1.2 so everyone can benefit. Thinking in Graphs Before I dive into how we implemented parallelism in stacker, I think it's important to take a step back, and look at what stacker is, at it's core; a tool for linking infrastructure together as a dependency graph. Let's take a look at a hypothetical stacker config to build out some infrastructure. stacks: - name: vpc class_path: blueprints.VPC - name: cluster class_path: blueprints.Cluster variables: VpcId: ${output vpc::Id} - name: db class_path: blueprints.DB variables: VpcId: ${output vpc::Id} - name: app class_path: blueprints.App variables: DBUrl: ${output db::URL} Cluster: ${output cluster::Id} When described in this way, the output lookup creates an explicit dependency relationship between stacks. The "app" stack depends on a "db" stack and a "cluster" stack, the "db" stack depends on a "vpc" stack, etc. We can visualize the resulting dependency graph using dot. digraph { cluster -> vpc; db -> vpc; app -> db; app -> cluster; } $ cat graph.dot | dot -Tpng > graph.png In fact, creating dependency graphs like this isn't really a new concept in computing; make does it, systemd does it, and programing lang ## I wish I knew my consumers - Maven Reverse Dependency DevFeed: [I wish I knew my consumers - Maven Reverse Dependency]() Original publisher: [Read original article]() Author: roar Published: 2013-01-31T12:49:05Z Content type: article Language: en Sources: [Finn.no]() Topics: [Reverse Dependencies](), [Maven](), [Neo4j](), [graph-database](), [Library](), [bug]() Tags: [bug](), [dependency](), [graph-database](), [libraries](), [maven](), [reverse-dependencies]() ### AI overview The article describes a Maven plugin that records project dependencies in a Neo4j graph database and examines reverse dependencies to identify applications using a Maven project, including the versions they use. The plugin was created to help developers notify users when shared libraries are fixed or changed. ### Source excerpt At FINN.no being a developer fixing bugs in a library is a breeze. Getting every user of your library to use the fix, however, is a different story. How to know who to notify? I mean, I know my library's dependencies, but who "out there" has dependency to the component where I just fixed a bug? I wish. Enter maven-dependency-graph. The idea was born on the plane back home from a Copenhagen hosted conference. Graph database. Download neo4j and start dabbling at a maven plugin. Flying time Copenhagen - Oslo was too short, all of a sudden. From there, the idea slept for a couple of years. Until the need arose somewhere among the developers. With 100+ different applications running with common core services and libraries, everybody suddenly needed to know who depended on their code which had recently been bugfixed. So the old idea was dusted off and once more saw the light of day. We needed to upgrade the server installation and the API to neo4j - which took some time to grasp; but after some playing around, it became obvious and easy. The idea was to have every project report its dependencies to a graph database, building the tree of dependencies on each commit. This constitutes one half of the plugin. Over time, all projects will have reported their dependencies, and from there on part two of the plugin comes into use. It will examine the reverse dependencies to the current maven project, and report all incoming dependencies to it in the maven log. Hey, presto! We now know who out there uses us! And even which version they are using, thanks to two different keys into the built-in lucene index engine. The plugin is published on github @ Finn Technology's account. Feel free! @gardleopard and @roarjoh Usage examples Dependencies to current maven project: mvn no.finntech:dependency-mapper-maven-plugin:read [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building greenpages thrift-client 3.4.5-SN