Enabling Private Vulnerability Reporting

Tue, 26 May 2026 00:00:00 +0000

With the rise of LLM usage, the number of vulnerabilities being found in Open Source Software libraries is climbing – perhaps more than you might think. Finding vulnerabilities is getting easier, but reporting them to maintainers can be a bottleneck. One way to help streamline the process is by enabling “Private vulnerability reporting” on your GitHub repositories. This gives reporters a private, official channel to reach out to you with details about exploits (both confirmed and unconfirmed).

"Crayons" by echilds41 is licensed under CC BY 2.0 .

You might think “just email me – I’m not hard to find”, but you’d be surprised how often nailing down the right email and the right contact person is a source of friction. If you’re able to toggle this switch, you are opening up a pathway for reporters to let you know about a possible CVE so that they can either help you remedy the situation or move on to the next CVE on their list.

If you have GitHub’s “gh” tool installed, this is trivial to do:

#!/usr/bin/env bash

set -eu -o pipefail

# Enable "Private vulnerability reporting" for all repos you have admin access to.
# Optionally pass an org name to target that org's repos instead of your own.
#
# Filters applied to `gh repo list`:
# --no-archived skip archived repos (can't change settings on them)
# --visibility public skip private and internal repos
# --source skip forks (PVR is configured on the upstream)
# --limit 1000 cap result set; raise if you have more repos

owner=${1:-}

gh repo list ${owner:+"$owner"} --limit 1000 --no-archived --visibility public --source --json nameWithOwner --jq '.[].nameWithOwner' | \
 while IFS= read -r repo; do
 echo "Enabling private vulnerability reporting: $repo"
 gh api "repos/$repo/private-vulnerability-reporting" -X PUT --silent \
 || echo " failed: $repo"
 done

echo "Done."

Run it with no arguments to target your own repos, or pass an org name to target an org you administer:

./enable-pvr.sh # your repos
./enable-pvr.sh some-org # repos in some-org

Thanks for helping to make the OSS landscape a better place, but be warned: this could take up to three minutes of your time!

Read on website

On Cooldowns and Dependabot Tuning

Tue, 19 May 2026 00:00:00 +0000

"Iceberg" by longhorndave is licensed under CC BY 2.0 .

Dependabot’s defaults can make it look like an agent of chaos. There are a couple of things you can do to turn down the churn from 11.

Cooldowns
#

The idea behind cooldowns is essentially that unless you’re constantly in YOLO mode, you probably don’t need something that was released to the world 5 minutes or even 5 days ago. Yes, there are exceptions (security updates, some brand new thing, etc). Just waiting a few days (or a week) can reduce your exposure to supply chain attacks because a large percentage of compromised packages will have been discovered in the hours/days after a release. It’s not a silver bullet, but it mitigates your exposure to some extent.

Dependabot groups
#

The idea behind Dependabot groups is that you have an escape hatch out of Dependabot pull request hell, where X pull requests are opened that all touch the same files, generally require rebasing if you merge them serially, and sometimes break your CI because they should have been bundled together.

If you’ve ever been in the position of Dependabot proposing major version upgrades to the upload-artifact action and the download-artifact action in discrete pull requests, you probably know what I’m talking about. Neither PR on its own will pass CI. Merging either PR breaks your top level CI. You either need to fix this manually by combining the PRs before merge or merge both broken PRs individually and hope for the best. Similarly, if you have a bunch of different minor version updates to your npm dependencies, which all touch the same lockfile, you may also appreciate being able to group your dependencies.

The skill
#

I have too many repositories to want to manage this by hand, especially when I have a number of slightly different dependabot configs. There’s not necessarily a one-size-fits-all solution. So, a good fit for me is to use a Claude skill to update my deps.¹ My “tune dependabot” skill will examine a dependabot config and apply cooldowns as well as groups, where needed. If the config does not yet exist, it’s happy to create a new one from scratch. For me this is a quality of life thing as I have accumulated too many repositories for this kind of banal work to be enjoyable. In addition to the security benefits, it also reduces some of the friction that comes with having to merge a lot of dependabot pull requests on an ongoing basis.

A tuned config
#

Here’s a sample, tuned config file. GitHub Actions gets two groups: major version bumps are batched together so that changes to things like upload-artifact and download-artifact can be merged together, with minor and patch updates bundled into their own pull request. The gomod and npm ecosystems only group minor and patch updates, which allows the major version bumps to be tested in isolation. Every ecosystem gets a one week cooldown period.

version: 2
updates:
 - package-ecosystem: "github-actions"
 directory: "/"
 schedule:
 interval: weekly
 groups:
 major-updates:
 patterns:
 - "*"
 update-types:
 - "major"
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7
 - package-ecosystem: gomod
 directory: "/go"
 schedule:
 interval: weekly
 open-pull-requests-limit: 10
 groups:
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7
 - package-ecosystem: npm
 directory: "/"
 schedule:
 interval: weekly
 open-pull-requests-limit: 10
 groups:
 minor-and-patch:
 patterns:
 - "*"
 update-types:
 - "minor"
 - "patch"
 cooldown:
 default-days: 7

This gets me fewer rebases, boring CI, and a few extra days of waiting while the rest of the world identifies the bad actors.

Written with Superpowers, as usual. ↩︎

Read on website

security on olafalders.com

Enabling Private Vulnerability Reporting

On Cooldowns and Dependabot Tuning

Cooldowns #

Dependabot groups #

The skill #

A tuned config #

Cooldowns
#

Dependabot groups
#

The skill
#

A tuned config
#