Chris Anderson joins the show. You may recognize Chris from the early days of CouchDB and Couchbase. Back when the world was just waking up to NoSQL, Chris was at the center of it all, shaping how developers think about data distribution and offline-first architecture.
These days, Chris is working on Vibes.diy and Fireproof — tools that make one-shot app generation not only possible, but shareable within minutes. We talk about the origins of CouchDB, the fork that led to Membase and Couchbase, and how that long journey led to this new paradigm: Vibe Coding.
Changelog++ members save 5 minutes on this episode because they made the ads disappear. Join today!
Sponsors:
Retool – Assemble your elite AI team, arm them with powerful custom tools, and watch them make your to-do list disappear. Start for free or book a demo at retool.com/agents
Depot – 10x faster builds? Yes please. Build faster. Waste less time. Accelerate Docker image builds, and GitHub Actions workflows. Easily integrate with your existing CI provider and dev workflows to save hours of build time.
Brazil's supreme court has ruled that social media platforms can be held legally responsible for their users' posts. From a report: Companies such as Facebook, TikTok and X will have to act immediately to remove material such as hate speech, incitement to violence or "anti-democratic acts," even without a prior judicial takedown order, as a result of the decision in Latin America's largest nation late on Thursday.
It should come as no surprise that more and more developers are adopting macOS devices as development machines. On top of the OS being quite user-friendly and stable, the hardware is hard to beat. I’ve had MacBooks that have far outlasted any other laptop I’ve purchased (by a long shot), which means I not only do not have to spend the money for a new machine as often as I might have to with any other brand, but I can keep the same work environment I’ve created and perfected over the years.
If you’re a developer, you might have opted to migrate to macOS as well. If you’ve spent years developing on either Linux or Windows, you might have questions. One of the biggest questions to pop into your head could possibly be how to set up the new OS as a development machine.
Fortunately, it’s not nearly as hard as you might think.
Let me make this a bit easier for you and guide you through some of the things you might need and some of the customizations you can take care of.
It Starts With the Terminal
One thing to keep in mind is that macOS is very similar to Linux, especially when it comes to the terminal. Out of the box, you already have a ton of Linux-like tools at your disposal, including command-line text editors like nano, vi and vim. Beyond that, however, one of the first things you’ll want to do is install Homebrew so you gain access to even more command-line tools and apps. You can learn all about Homebrew, including how to install it and Cask, for installing graphical user interface (GUI) tools as well, in Install Homebrew on MacOS for More Dev Tool Options.
I would, however, suggest you install a different terminal app, as what macOS has to offer is fairly basic. As far as which terminal apps to install, I would suggest one of the following:
Some of the above terminals can be installed via downloadable binaries and some can be added via Homebrew.
You might also consider changing the default shells. MacOS defaults to the zsh shell, but if bash is your preferred shell for development purposes, you can easily switch. First, confirm your current shell with:
Most likely, it’ll report zsh.
To install bash, you’ll use brew like so:
After the installation completes, open the shells configuration file with:
If you don’t see /bin/bash listed, add it to the bottom of the file. Save and close the file with the Ctrl+X keyboard shortcut, and then switch your shell with:
Now, if you confirm your shell, it should report bash as the current.
If you don’t want to have to go through the process of customizing bash manually, you can install Oh My Bash, which is an open source framework for managing the bash configuration. Oh My Bash comes bundled with helpful functions, plugins, themes and more.
You can install Oh My Bash with the command:
Next, install Git with brew, like so:
You’ll probably know what to do next with Git.
More Efficient Window Management
On my MacOS devices, I make use of Apple’s Stage Manager, but most users aren’t terribly keen on that feature because it complicates multitasking, especially working with two windows simultaneously.
Fortunately, for developers, Apple finally added a tiling feature to the OS. You can drag a window to one of the display corners to have it fill a quarter of your screen, to the right or left edge to have it fill up half of the display vertically, or to the top or bottom to have it take up half horizontally.
If the built-in snapping/tiling feature isn’t enough, there’s a handy app called Rectangle that gives you more options for snapping/tiling. You can install Rectangle with the command:
Searching and Launching
If you’re like me, you need to be able to search for files and launch apps quickly, and without always taking your hands off the keyboard. For that, you can either wait until the macOS Tahoe upgrade (which supercharges Spotlight), or you can install Alfred (available in the App Store), which makes searching for files and many other tasks incredibly simple.
Development Tools
Of course, every developer has their tools of choice, and trying to cover all of those would be impossible. However, it’s important to know that most of the tools that you’ve grown accustomed to using are available for macOS.
For instance, you can install Node.js by first installing NVM with the command:
After that finishes, issue the command:
Next, download and install Node.js with:
There you go. You now have Node.js ready to rock.
You might also want to install Docker on your Mac, which can be done by downloading the binary installer for either Apple Silicon or Intel devices. Double-click the downloaded .dmg file and walk through the installation wizard.
Whichever apps, libraries, IDEs, frameworks and other tools you use are most likely also available for macOS, so make sure to search them out and install them.
It’s not nearly as hard to set up macOS for development, but do remember that what you need to install or configure will depend on your style and the projects you are working on.
The GitHub Advisory Database (Advisory DB) is a vital resource for developers, providing a comprehensive list of known security vulnerabilities and malware affecting open source packages. This post analyzes trends in the Advisory DB, highlighting the growth in reviewed advisories, ecosystem coverage, and source contributions in 2024. We’ll delve into how GitHub provides actionable data to secure software projects.
Advisories
The GitHub Advisory Database contains a list of known security vulnerabilities and malware, grouped in three categories:
GitHub-reviewed advisories: Manually reviewed advisories in software packages that GitHub supports.
Unreviewed advisories: These are automatically pulled from the National Vulnerability Database (NVD) and are either in the process of being reviewed, do not affect a supported package, or do not discuss a valid vulnerability.
Malware advisories: These are specific to malware threats identified by the npm security team.
Reviewed advisories
GitHub-reviewed advisories are security vulnerabilities that have been mapped to packages in ecosystems we support. We carefully review each advisory for validity and ensure that they have a full description, and contain both ecosystem and package information.
Every year, GitHub increases the number of advisories we publish. We have been able to do this due to the increase in advisories coming from our sources (see Sources section below), expanding our ecosystem coverage (also described below), and review campaigns of advisories published before we started the database.
In the past five years, the database has gone from fewer than 400 reviewed advisories to over 20,000 reviewed advisories in October of 2024.
Unreviewed advisories
Unreviewed advisories are security vulnerabilities that we publish automatically into the GitHub Advisory Database directly from the National Vulnerability Database feed. The name is a bit of a misnomer as many of these advisories have actually been reviewed by a GitHub analyst. The reason why they fall into this category is because they are not found in a package in one of the supported ecosystems or are not discussing a valid vulnerability, and all have been reviewed by analysts other than someone from the GitHub Security Lab. Even though most of these advisories will never turn into a reviewed advisory, we still publish them so that you do not have to look in multiple databases at once.
Malware
Malware advisories relate to vulnerabilities caused by malware, and are security advisories that GitHub publishes automatically into the GitHub Advisory Database directly from information provided by the npm security team. Malware advisories are currently exclusive to the npm ecosystem. GitHub doesn’t edit or accept community contributions on these advisories.
Ecosystem coverage
GitHub-reviewed advisories include security vulnerabilities that have been mapped to packages in ecosystems we support. Generally, we name our supported ecosystems after the software programming language’s associated package registry. We review advisories if they are for a vulnerability in a package that comes from a supported registry.
Vulnerabilities in Maven and Composer packages are nearly half of the advisories in the database. npm, pip, and Go make up much of the rest, while the other ecosystems have a much smaller footprint.
This has not always been the case. When the database was initially launched, NPM advisories dominated the database, but as we have expanded our coverage and added support for new ecosystems, the distribution mix has changed.
Sources: Where do the advisories come from?
We add advisories to the GitHub Advisory Database from the following sources:
NVD: This is a huge source of vulnerabilities covering all types of software. We publish all NVD advisories but only review those relevant to our supported ecosystems, which reduces noise for our users.
GitHub Repository Advisories: The second largest source is made up of advisories published through GitHub’s repository security advisory feature. Similar to NVD, these aren’t restricted to our supported ecosystems. However, we provide better coverage of the repository advisories because they focus exclusively on open source software.
Community Contributions: These are reports from the community that are almost exclusively requesting updates to existing advisories.
Other Specialized Sources: Sources like PyPA Advisories (for Python) and Go Vulncheck (for Go) that focus on specific ecosystems. Because they only cover packages within our supported ecosystems, most of their advisories are relevant to us and get reviewed.
If you add up the number of reviewed advisories from each source, you will find that total is more than the total reviewed advisories. This is because each source can publish an advisory for the same vulnerability. In fact, over half of our advisories have more than one source.
Of the advisories with a single source, nearly all of them come from NVD/CVE. This justifies NVD/CVE as a source, even though it is by far the noisiest.
2024 saw a significant increase (39%) in the number of advisories imported from our sources. This is for the most part caused by an increase in the number of CVE records published.
CVE Numbering Authority
In addition to publishing advisories in the GitHub Advisory Database, we are also a CVE Numbering Authority (CNA) for any repository on GitHub. This means that we issue CVE IDs for vulnerabilities reported to us by maintainers, and we publish the vulnerabilities to the CVE database once the corresponding repository advisory is published.
GitHub published over 2,000 CVE records in 2024, making us the fifth-largest CNA in the CVE Program.
The GitHub CNA is open to all repositories on GitHub, not just ones in a supported ecosystem.
Advisory prioritization
Given the constant deluge of reported vulnerabilities, you’ll want tools that can help you prioritize your remediation efforts. To that end, GitHub provides additional data in the advisory to allow readers to prioritize their vulnerabilities. In particular, there are:
Severity Rating/CVSS: A low to critical rating for how severe the vulnerability is likely to be, along with a corresponding CVSS score and vector.
CWE: CWE identifiers provide a programmatic method for determining the type of vulnerability.
EPSS: The Exploit Prediction Scoring System, or EPSS, is a system devised by the global Forum of Incident Response and Security Teams (FIRST) for quantifying the likelihood a vulnerability will be attacked in the next 30 days.
Using these ratings, half of all vulnerabilities (15% are Critical and 35% are High) warrant immediate or near-term attention. By focusing remediation efforts on these, you can significantly reduce risk exposure while managing workload more efficiently.
The CVSS specification says the base score we provide, “reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time and assumes the reasonable worst-case impact across different deployed environments.” However, the worst-case scenario for your deployment may not be the same as CVSS’s. After all, a crash in a word processor is not as severe as a crash in a server. In order to give more context to your prioritization, GitHub allows you to filter alerts based on the type of vulnerability or weakness using CWE identifiers. So you have the capability to never see another regular expression denial of service (CWE-1333) vulnerability again or always see SQL injection (CWE-89) vulnerabilities.
Still drowning in vulnerabilities? Try using EPSS to focus on vulnerabilities likely to be attacked in the next 30 days. EPSS uses data from a variety of sources to create a probability of whether exploitation attempts will be seen in the next 30 days for a given vulnerability. As you can see from the chart below, if you focus on vulnerabilities with EPSS scores of 10% or higher (approx. 7% of all vulnerabilities in the Advisory DB), you can cover nearly all of the vulnerabilities that are likely to see exploit activity.
EPSS probability
Vulnerabilities in range
Percentage of overall vulnerabilities
Expected vulnerabilities in range attacked within the next 30 days
Percentage of total attacked vulnerabilities
High ( >= 10%)
1440
7.17%
741
85.96%
Moderate ( >= 1%, < 10%)
2687
13.37%
84
9.74%
Low ( >= 0.1%, < 1%)
10264
51.09%
35
4.06%
Very Low ( < 0.1%)
5701
28.37%
2
0.23%
Important caveats to remember when using EPSS:
Low probability events occur.
EPSS does not tell you whether a vulnerability is exploited; it only claims how likely it is.
EPSS scores are updated daily and will change as new information comes in, so a low-probability vulnerability today may become high probability tomorrow.
For more details on how to use CVSS and EPSS for prioritization, see our blog on prioritizing Dependabot alerts.
Actionable data
The GitHub Advisory DB isn’t just a repository of vulnerabilities. It powers tools that help developers secure their projects. Services like Dependabot use the Advisory DB to:
Identify vulnerabilities: It checks if your projects use any software packages with known vulnerabilities.
Suggest fixes: It recommends updated versions of packages that fix those vulnerabilities when available.
Reduce noise: You’ll only get notified about vulnerabilities that affect the version of the package you are using.
Take this with you
The GitHub Advisory Database is a powerful resource for tracking open source software vulnerabilities, with over 22,000 reviewed advisories to date. By focusing on popular package registries, GitHub allows you to definitively connect vulnerabilities to the packages you are using. Additional data such as CVSS and EPSS scores help you properly prioritize your mitigation efforts.
GitHub’s role as a CVE Numbering Authority extends beyond the Advisory Database, ensuring that thousands of vulnerabilities each year reach the broader CVE community. Want to ensure your vulnerability fix reaches your users? Create a GitHub security advisory in your repository to take advantage of both the GitHub Advisory Database and GitHub’s CNA services.
Can AI-driven autonomy reduce harm, or does it risk dehumanizing decision-making? In this “AI Hot Takes & Debates” series episode, Daniel and Chris dive deep into the ethical crossroads of AI, autonomy, and military applications. They trade perspectives on ethics, precision, responsibility, and whether machines should ever be trusted with life-or-death decisions. It’s a spirited back-and-forth that tackles the big questions behind real-world AI.
Outshift by Cisco: AGNTCY is an open source collective building the Internet of Agents. It's a collaboration layer where AI agents can communicate, discover each other, and work across frameworks. For developers, this means standardized agent discovery tools, seamless protocols for inter-agent communication, and modular components to compose and scale multi-agent workflows.
Log in
An overview of Google’s 2025 Environmental Report.
