Coder Legion - Recent posts tagged dependencies

Why Dependencies Are Your Biggest Security Risk

Mon, 27 Jul 2026 13:28:06 +0000

You install a package. It solves a problem. You move on.

You do not think about it again. But that package is now part of your application. It has access to your data. It runs in your environment.

If that package has a vulnerability, so do you.

The Numbers

A typical Node.js project has over 500 dependencies. A Python project has over 100. A Rust project has over 50. Most developers do not know what is in their dependencies. They know the top-level packages. They do not know the transitive ones. The packages that are three levels deep. The ones that were installed by a package that was installed by a package.

Those are the dangerous ones.

The Problem Is Not The Maintainers

Most maintainers are doing their best. They fix vulnerabilities when they are reported. The problem is the volume. There are over 2 million packages on npm. Hundreds of new vulnerabilities are discovered every month.

You cannot manually track all of them. You need automation.

What I Do Now

Here is what I do.

Weekly: I run a dependency scan. I look at the output. I fix critical and high severity issues.

Before every release: I scan again. I make sure nothing new was introduced.

On PRs: I scan new dependencies before they are merged.

It takes 5 minutes per week. It saves me from CVEs that could have taken hours to fix later.

The "It Is Just A Dev Dependency" Trap

People say: "It is just a dev dependency. It does not matter."

But it does matter.

Some dev dependencies run in CI. Some run during build. Some run during testing. If a dev dependency is compromised, your CI environment is compromised. Your build artifacts are compromised. Your secrets are exposed.

Do not ignore dev dependencies.

What You Can Do Today

You do not need to buy anything. You do not need to spend hours.

Run a dependency scan today.

If you use npm: npm audit
If you use Python: pip-audit
If you use Rust: cargo audit
If you use Go: govulncheck

It takes 30 seconds. It tells you what is broken. Fix the critical things. Fix the high severity things. Ignore the rest.

Then do it again next week.

The Bottom Line

Your dependencies are your biggest security risk. Treat them that way. Scan them. Fix them. Ship.

Discussion Question

What is the worst CVE you have found in a dependency? How did you find it?

Automatically update GitHub Action versions

Mon, 29 Jun 2026 14:49:47 +0000

You don't notice your GitHub Actions versions until you start getting warnings about things like "Node 20 is no longer supported". When you think about it, GitHub Actions are yet another dependency that needs to be kept up to date and present supply chain risks.

Get Dependabot to do the work

The good news is, you can get Dependabot to keep your GitHub Actions up to date for you. You can add instructions for this to your .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

In my case I already had configuration for my npm dependencies:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

But it's trivial to add multiple updates to the same file:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Automatic pull requests

When you first commit this file, you'll notice pull requests start appearing for your review.

- name: Setup pnpm cache
    uses: actions/cache@v4 (-)
    uses: actions/cache@v5 (+)

This is a simple example of how you can use Dependabot to keep your GitHub Actions up to date. You can find more information about Dependabot in the GitHub documentation.

Getting up-and-running with Dependency-Track

Mon, 04 May 2026 21:24:20 +0000

Since its inception in 2013, OWASP Dependency-Track has been at the forefront of analysing Software Bill of Materials (SBOM) for cybersecurity risk identification and reduction. Dependency-Track allows organisations and governments to operationalise SBOM in conformance with U.S. Executive Order 14028 and more recently the European Union's Cyber Resilience Act.

In a previous blog post I briefly discussed how the EU's CRA requires SBOM generation across the software developer lifecycle, should be generated at build time, and should enrich the SBOM with vulnerability data in order to demonstrate whether a given software dependency or library is likely to be exploited or not. When talking about SBOMs, there are 2 industry-recognised formats - SPDX (under the Linux Foundation) and CycloneDX (maintained by OWASP). Dependency-track specifically supports the OWASP CycloneDX BOM format, which is defined in the NTIA Minimum Elements for SBOMs.

So what does Dependency-Track do?

Dependency-track consumes and analyses the SBOMs we just mentioned for known security, operational, and license-related risks. The tool is ideal for use in procurement and continuous integration and delivery environments - which is crucial when trying to meet the requirements of the US EO14028 or the EU CRA. Dependency-track supports the OWASP CycloneDX Vulnerability Exploitability Exchange (VEX) format exceeding the existing VEX requirements defined by CISA.

In short, dependency-track is an intelligent Component Analysis platform that allows organisations to identify and reduce risk in the software supply chain. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of the existing SBOM, an approach that provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organisation. The platform has an API-first design and is ideal for use in CI/CD environments. And that's what we'll demonstrate in this short blog post.

How to install Dependency-Track

There are a bunch of ways to install or deploy dependency-track - either as a Kubernetes workload via Helm, or as a standalone executable. I opted for the simple Docker Compose quickstart.

curl -LO https://dependencytrack.org/docker-compose.yml
docker-compose up -d

This install was super quick. I was then able to access to the locally-hosted GUI via the below URL. By default, the dependency-track frontend runs on port 8080.

URL: http://localhost:8080
Username: admin
Password: admin

First Step: It will immediately force you to change that password. Pick something secure and log back in.

Building an SBOM

Since this is a quickstart guide, we will go down the manual workflow. But realistically you will be looking to automate this entire workflow through CI/CD. The first thing we need to do is create an SBOM. There are various scanners such as Trivy and Grype to achieve this, so I'll be using Grype.

In the below command, the Grype scanner pulls the Ollama image from Docker Hub, on version 0.1.32. Notice how the report is exported in output (-o) of CycloneDX JSON.

grype ollama/ollama:0.1.32 -o cyclonedx-json > ollama_v0.1.32.json

The file itself is called ollama_v0.1.32.json - I decided to add the full SBOM output for one random Docker Image SBOM just to give you an idea of how much information is contained within these SBOMs. In the below snippet, we can the format, and version of the format that created this SBOM. We get a component for the scanned image, but also for the scanner itself. What makes the SBOM so long, and ultimately hard to read, is all the software dependencies and transitive dependencies of those software dependencies that we ultimately did not write. They are just small chunks of code baked into the layers of this Ollama Docker Image.

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:fc5a8286-c9dc-4785-8de0-7ff703ebcf98",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-04T12:17:33+01:00",
    "tools": {
      "components": [
        {
          "type": "application",
          "author": "anchore",
          "name": "grype",
          "version": "0.100.0"
        }
      ]
    },
    "component": {
      "bom-ref": "56a120ff045b7287",
      "type": "container",
      "name": "ollama/ollama",
      "version": "0.1.32"
    },
    "properties": [
      {
        "name": "syft:image:labels:org.opencontainers.image.ref.name",
        "value": "ubuntu"
      },
      {
        "name": "syft:image:labels:org.opencontainers.image.version",
        "value": "22.04"
      }
    ]
  },

Pushing an SBOM to dependency-track

To publish CycloneDX BOMs, use a valid API Key and Project UUID. Finally, Base64 encode the BOM and insert the resulting text into the ‘bom’ field. Since this is a test workflow, and we don't have any project's created, and therefore no associated Project UUID, we can create all this only the fly without any need for Base64-encoding. We simply push the ollama_v0.1.32.json file to the dependency track API with our newly-created API;

curl -X "POST" "http://localhost:8081/api/v1/bom" \
     -H 'Content-Type: multipart/form-data' \
     -H "X-Api-Key: $DTRACK_API_KEY" \
     -F "autoCreate=true" \
     -F "projectName=ollama" \
     -F "projectVersion=0.1.32" \
     -F "bom=@ollama_v0.1.32.json"

For GitHub workflow environments the Dependency-Track GitHub Action is recommended.

Vulnerability Intelligence

If using a vulnerability scanner like Grype, you might notice that the vulnerability data doesn't always match exactly the same in dependency-track. As you can see from the output of Grype scanner, I have 3 Critical and 22 High severity vulnerabilities associated with that Ollama docker image.

In the dependency-track UI, we see 4 Critical and 15 High. Definitely not the same result from our Grype scanner during SBOM generation.

It usually boils down to a difference in Vulnerability Databases and Matching Logic. While both tools are looking at the same SBOM, they are using different informed data to interpret it.

Uses its own proprietary database (vunnel), which aggregates data from the NVD, GitHub Advisories, and specific Linux distro feeds (like Ubuntu or Alpine security trackers). Whereas, dependency-track usually relies on the [NVD][17] (National Vulnerability Database) via API and the GitHub Advisory Database - which probably explains why the data is not correct. Happy for people to provide surrounding context here in the comments.

My other theory is that a vulnerability might be a critical (9.8) in one tool using CVSS v3.1, but the other tool might still be displaying the CVSS v2 score, which might only be a High (7.5). Dependency-track apparently allows you to toggle which scoring method you want to prioritise in its settings, so this is something I will explore further.

Exploit Prediction Scoring System (EPSS)

The EPSS (exploitability) vs. CVSS (generic vulnerability scoring) might be a little confusing at first. While a CVSS score is a point-in-time score, and is often not updated in those NVD records, the EPSS score is designed as an ML Model to continuously update on a daily basis, globally, to look at the likelihood of being exploited - based on evolving environmental factors. If a specific CVE is getting exploited in the wild, the chances of this CVE being exploited in your environment naturally goes up - even if the CVSS score never changes. I wrote a dedicated Cloudsmith blog post on the difference between these existing scoring systems.

VEX Reporting

The [VEX documentation][20] is kinda limited in the official dependency-track docs. As a result, I will write a separate, dedicated blog post on VEX that goes outside of the scope of this similar getting started guide. We'll talk about VEX in more details, and why applying analyses from a VEX document to this project is critical will help us meet the requirements of CRA without constantly panicking about new CVE IDs.

Unlike EPSS alone, understanding the genuine impact of vulnerabilities is essential for risk management, and CycloneDX achieves this by representing exploitability data through VEX. Unlike general vulnerability disclosures, VEX focuses on whether a vulnerability in a component can actually be exploited in its specific context. This clarity helps organisations prioritise responses, reducing unnecessary mitigation efforts and ensuring resources are focused on critical risks.

Hope you enjoyed this blog post!

DevLog 20250706: Analyzing (C#) Project Dependencies

Sun, 06 Jul 2025 19:26:37 +0000

When a code project grows complex it's going to be difficult to understand which depends on which - developers familiar with the C# ecosystem can look at NuGet Package Manager and use .csproj to try to study things but when the hierarchy gets complex it can feel inconvenient.

For instance, say I have a top-level entry program that I know ultimately depends on Mathnet.Numerics - now I need to figure out which subproject references it.

The General Approach

To view which project depend on which package in C#, below are some approaches using existing tools.

1. Using the .NET CLI

This approach only shows the NuGet packages the projects depend on.

a) List packages per project

Run, for each project:

dotnet list path/to/MyProject.csproj package

We'll get an "Installed" section showing direct references.

b) Include transitive dependencies

dotnet list path/to/MyProject.csproj package --include-transitive

This will also show packages pulled in by other packages.

c) Script it for the entire solution

On bash (Linux/macOS/git-bash):

for proj in $(find . -name '*.csproj'); do
  echo "== $proj =="  
  dotnet list "$proj" package --include-transitive | grep MathNet.Numerics -B2 -A2
done

On PowerShell (Windows):

Get-ChildItem -Recurse -Filter *.csproj |
  ForEach-Object {
    Write-Host "== $($_.FullName) =="
    dotnet list $_.FullName package --include-transitive |
      Select-String "MathNet.Numerics" -Context 2,2
  }

2. Grep / Select-String on `.csproj` files

Since NuGet package references live in <PackageReference> items, we can search directly:

bash:

grep -R "PackageReference.*MathNet\.Numerics" -n .

PowerShell:

Get-ChildItem -Path . -Filter *.csproj -Recurse | Select-String -Pattern 'MathNet\.Numerics' -List
  
# Or
Get-ChildItem -Recurse -Filter *.csproj | Select-String -SimpleMatch 'MathNet.Numerics' -List

That will show us exactly which project files reference it.

Alternatively, just do a full text search in VS Code with file type filter.

3. Visual Studio / Rider UI

Right-click on the Solution → Manage NuGet Packages for Solution…
Go to the Installed tab, find MathNet.Numerics in the left panel.
On the right, we'll see checkboxes or project-scoped lists showing which projects have it installed.

Once again, this method doesn't show the complete picture or the hierarchy of dependencies.

4. MSBuild Dependency Graph (advanced)

If we need to audit transitive and project-to-project dependencies in one go, we can generate a restore graph:

dotnet msbuild /t:GenerateRestoreGraphFile /p:RestoreGraphOutputPath=graph.dg

This produce a fairly comprehensive output that contains absolute paths and a bit too much irrelevant information.

Then inspect graph.dg (JSON) for entries where "PackageId":"MathNet.Numerics" and note the "ProjectPath" fields.

Custom Tool

Above methods work but if you don't like the output format, CLI syntax, or just want something more straightforward - then it's time for a custom tool.

The C# Dependency Analyzer is a tool that can quickly help identify dependencies of a source code project. This is useful in identifying unwanted nuget dependencies from any given entry assembly. It is equivalent to manually searching through .csproj to find which projects depend on which and debug NuGet dependencies.

It can do those three things:

Print an exhaustive dependency tree with a root node at each source project level down to all dependent projects and most importantly the root NuGets
Given a single target project/nuget, prints a filtered tree of all projects that depend on that assembly
Given a single target project/nuget and a source assembly, it prints the tree paths that lead from the source assembly to the target - showing clearly the path from the source assembly to the ultimate dependency.

Below is an example output with command: path --path <solution path> --source Transcriber --target SkiaSharp

References

Methodox Dependency analyzer: visit Github

Improving Maven's dependency:analyze... or not

Mon, 10 Mar 2025 15:55:22 +0000

Recently, my good friend Richard Fichtner advised using the mvn dependency:analyze command to get rid of declared but unused dependencies:

There is another use case for mvn dependency:analyze It can show you the dependencies you use in your code but have not declared in your pom.xml. This works because you have a transitive dependency on your classpath. Either don't use the dependency or declare it.

[image or embed]
— Richard Fichtner ????☕ (
@richard.fichtner.dev
)
December 10, 2024 at 2:00 PM

While it was a great idea years ago, it's dangerous advice today. In this post, I'd like to explain what the plugin does and why you shouldn't use it but in the most straightforward projects.

The `mvn dependency:analyze` command

Maven uses a plugin architecture; in the above command, the plugin is maven-dependency-plugin. A plugin hosts several related goals. Here, it's analyze.

>Analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. This goal is intended to be used standalone, thus it always executes the test-compile phase - use the dependency:analyze-only goal instead when participating in the build lifecycle.
>By default, maven-dependency-analyzer is used to perform the analysis, with limitations due to the fact that it works at bytecode level, but any analyzer can be plugged in through analyzer parameter.
>-- dependency:analyze

maven-dependency-analyzer is a shared Maven component. Its description is quite descriptive:

>Analyzes the dependencies of a project for undeclared or unused artifacts.
>Warning: Because analysis is done on the bytecode rather than the source, some cases are not detected including constants, annotations with source-only retention, and links in Javadoc. This can lead to incorrect results when these are the only uses of a dependency.
>The main component is ProjectDependencyAnalyzer, which uses ClassAnalyzer and DependencyAnalyzer.
>-- maven-dependency-analyzer

The warning clearly shows that it works at the bytecode level. In particular, it explicitly mentions that it doesn't consider source-level annotations.

Spring Boot starters

I described how to design your own Spring Boot starter a long time ago, and it didn't change a lot since then. If you're new to Spring Boot starters, here's a summary.

SpringBoot relies on AutoConfiguration classes. AutoConfiguration classes are regular configuration classes, i.e., they contribute to the application classes. You can set specific activation criteria, such as the presence of a Spring property, but these are not specific to auto-configuration.

Here's a very simplified flow:

The JAR that automatically comes with Spring Boot is org.springframework.boot:spring-boot-autoconfigure. You can check the content of its META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports:

...
org.springframework.boot.autoconfigure.web.client.RestClientAutoConfiguration
org.springframework.boot.autoconfigure.web.client.RestTemplateAutoConfiguration
org.springframework.boot.autoconfigure.web.embedded.EmbeddedWebServerFactoryCustomizerAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.HttpHandlerAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.ReactiveMultipartAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.ReactiveWebServerFactoryAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.WebFluxAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.WebSessionIdResolverAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.error.ErrorWebFluxAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.function.client.ClientHttpConnectorAutoConfiguration
org.springframework.boot.autoconfigure.web.reactive.function.client.WebClientAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.HttpEncodingAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.MultipartAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration
org.springframework.boot.autoconfigure.websocket.reactive.WebSocketReactiveAutoConfiguration
org.springframework.boot.autoconfigure.websocket.servlet.WebSocketServletAutoConfiguration
org.springframework.boot.autoconfigure.websocket.servlet.WebSocketMessagingAutoConfiguration
org.springframework.boot.autoconfigure.webservices.WebServicesAutoConfiguration
org.springframework.boot.autoconfigure.webservices.client.WebServiceTemplateAutoConfiguration

As an example, here's the RestClientAutoConfiguration:

@AutoConfiguration(after = { HttpClientAutoConfiguration.class, HttpMessageConvertersAutoConfiguration.class }) //1
@ConditionalOnClass(RestTemplate.class)                //2
@Conditional(NotReactiveWebApplicationCondition.class) //3
public class RestTemplateAutoConfiguration {

    // Class body
}

Set the order of auto-configuration classes
Activate if the RestTemplate class is on the classpath
Activate if we aren't in a reactive web app context

Note that the class loader loads the RestTemplateAutoConfiguration class just fine, regardless of whether the RestTemplate class is on the classpath or not! Spring leverages this mechanism to its fullest, as seen above. In effect, the resolution of classes configured in annotations is deferred until they are explicitly accessed.

Bringing the `maven-dependency-analyzer` into the modern age

Committers designed the analyzer in 2007: here's how it looked like then. Spring Boot started later, in 2010. For this reason, the analyzer didn't take deferred class loading in annotations. Note that this is still not the case; the project doesn't get a lot of love.

When using the plugin on a Spring Boot project, you'll get a lot of false positives. I tried it with a simple Spring Boot project, using WebFlux and R2DBC on PostgreSQL.

Here's a slight excerpt of the output when I run mvn analyze:dependencies:

[WARNING] Unused declared dependencies found:
[WARNING]   org.springframework.boot:spring-boot-starter-data-r2dbc:jar:3.4.0:compile
[WARNING]   org.testcontainers:postgresql:jar:1.20.4:test
[WARNING]   org.testcontainers:r2dbc:jar:1.20.4:test

If I remove any of these dependencies, tests don't run.

What would be necessary to make the analyzer work with Spring Boot projects?
Let's analyze the analyzer.

The plugin allows configuring another analyzer:

>
>Specify the project dependency analyzer to use (plexus component role-hint). By default, maven-dependency-analyzer is used. To use this, you must declare a dependency for this plugin that contains the code for the analyzer. The analyzer must have a declared Plexus role name, and you specify the role name here.
> Type: java.lang.String
> Since: 2.2
> Required: No
> User Property: analyzer
>* Default: default
>-- dependency:analyze

We can create an overall analyzer that reuses the above but adds one specific to Spring Boot.

Conclusion

The current state of the Maven analyzer doesn't offer any benefit to modern Spring Boot projects. The existing code is open to configuration and even extension. However, we would need to embed a lot of Spring Boot logic. For Quarkus and Micronaut projects, we would require dedicated code as well.

I don't know if it's worth the time and effort. If you think it is, I hope this blog post can serve as an early-stage analysis.

To go further:

Originally published at A Java Geek on March 9^th, 2025