How Exiv2 built a vulnerability disclosure workflow

Exiv2, a C++ library and command-line tool for reading and modifying image metadata, has recently seen a wave of new bug reports. The project's maintainers initially believed fuzzing had largely exhausted the easy-to-find defects, but a fresh batch of issues began surfacing in April 2021. Of the 20 new advisories published, only four affect the tool in its default configuration — an out-of-bounds read, an uninitialized variable, an infinite loop, and another out-of-bounds read. The rest require specific command-line options that most users are unlikely to combine with untrusted image files. Even so, fixing the bugs outright proved simpler than debating their real-world impact.

Responding to those reports required more than patching code. The project needed a formal process for handling disclosures, and its experience offers a useful template for other open-source maintainers dealing with the same problem. Here is how Exiv2 set up its security advisory workflow using GitHub's built-in tooling.

Starting with a security policy

The first step was adding a SECURITY.md file to the repository. GitHub surfaces this file on the project's Security tab, making it the first thing a researcher sees when deciding where to report a vulnerability. Exiv2's policy keeps things deliberately low-tech: it lists the maintainer's personal email address as the contact point. Setting up a dedicated address like [email protected] would have been more polished, but it would also have meant creating and managing a mailing list — overhead that slowed down the process.

The policy emphasizes two points that matter most when disclosures start arriving:

  • Reproduction steps. Vague bug reports waste everyone's time, so the policy spells out exactly what information is expected from a reporter.
  • Defining a security issue. A bug that only exists on the main branch and not in a tagged release is treated as a regular defect, not a security vulnerability.

Drafting and publishing advisories on GitHub

GitHub Security Advisories are the core of the workflow, but they require administrator rights on the repository. Once an issue comes in, the maintainer creates a draft advisory and invites the reporter to join as a collaborator. All subsequent discussion happens in the advisory's comments rather than over email, which keeps the disclosure thread in one place.

A few features in particular smoothed the process:

  • CVE requests are now one click. Previously, obtaining a CVE identifier was one of the more tedious parts of publishing an advisory. GitHub now handles the request automatically.
  • Credit fields. Each advisory publicly acknowledges the researcher who reported the issue, which matters for recognition in the security community.
  • Temporary private forks. These allow collaborators to work on a fix without exposing the code before the advisory is published.

Despite the appeal of private forks, Exiv2 has largely stopped using them. The problem is that automated checks — GitHub Actions, Codecov, and similar tooling — do not run on temporary private forks. That is by design: a CI system could inadvertently leak details of an embargoed vulnerability by uploading data to third-party services. But for the low-severity issues showing up in Exiv2, that level of secrecy is unnecessary. Fixes go through ordinary public pull requests, where they benefit from the full automated testing pipeline. If a proof-of-concept demonstrating code execution ever arrives, the private fork workflow will be there as a fallback.

The result is a lightweight process that works for a project of this size and threat model. Start with a clear security policy, route disclosures through draft advisories, and reserve the heavyweight secrecy measures for vulnerabilities that genuinely warrant them.