Custom Advisories: the unsung hero of dependency-management-data

Featured image for sharing metadata for article

NOTE: This post is now unmaintained, and you should check out the official docs for up-to-date info.

As part of my work on dependency-management-data, I've found that having access to the raw dependency data for your organisation is a powerful thing. But on top of just having the data, being able to mould the data to your organisation's needs is even more important.

At Deliveroo, I was part of the Go Team, a group of folks working to shape and improve the usage of Go across the organisation. As part of this, we had some libraries that we tried to steer away from, for instance because there were known vulnerabilities in them, or it was an internally developed library that was no longer being maintained.

To get an understanding of which teams were affected and would need upgrades, I found myself re-writing the same SQL queries against the database, which could at least be shared around, but was suboptimal to keep tweaking the same base query.

In June, I decided enough was enough, and I added the ability to define custom Advisories. These integrated in with the existing Advisories concept - a way of flagging up package(s) for having known issues around maintenance, security, or otherwise - but provided a means to define your own, without modifying the code in dependency-management-data.

These advisories are defined in an SQLite table custom_advisories, which allows you to insert a row like:

-- examples taken from and respectively
INSERT INTO custom_advisories (
  'pkg/errors was archived in 2021, and is unmaintained since'
  'Amazon does not recommend the use of the v1 Go image, which is based off of Amazon Linux (v1)'

This produces a report that looks like:

PlatformOrganisationRepoPackageVersionDependency TypesAdvisory TypeDescription / v0.9.1["indirect"]UNMAINTAINEDpkg/errors was archived in 2021, and is unmaintained since

By being an arbitrary table, users can insert their own rules as necessary, giving them the visibility over which package(s) they feel shouldn't be in use, or that at least should be considered.

In July, I followed this up with the dependency-management-data-contrib project, which allows for community-sourced package advisories to be shared with all users of dependency-management-data, and was borne out of creating some package advisories at Deliveroo that weren't specific to Deliveroo's needs and therefore could be Open Source'd.

Users of dependency-management-data have found this to be a great feature, and I'm sure you may too!

Written by Jamie Tanna's profile image Jamie Tanna on , and last updated on .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.


This post was filed under articles.

Interactions with this post

Interactions with this post

Below you can find the interactions that this page has had using WebMention.

Have you written a response to this post? Let me know the URL:

Do you not have a website set up with WebMention capabilities? You can use Comment Parade.