flawz: a terminal UI for browsing CVE data from the NVD feed

A local SQLite cache of NVD records, browsed with ratatui

flawz is a Terminal User Interface for browsing the security vulnerabilities, also known as CVEs. As default it uses the vulnerability database from NIST, the NVD, and provides search and listing functionality in the terminal with different theming options.

So the shape of it is a local database plus a full-screen viewer. The NVD is a web API, and browsing it directly would mean a browser and a search form for every lookup. flawz takes the records, keeps them in a SQLite file on your machine, and renders them in a terminal application.

The example the README gives is the xz backdoor, CVE-2024-3094, and the invocation is short.

flawz --feeds 2024 --query xz

The --feeds flag selects which year of NVD data to sync, and the --query flag starts the interface with a search term already in it.

The dependency list explains the design. The nvd_cve crate at 0.3.0 handles the NVD API itself, ratatui at 0.30.1 is the terminal UI toolkit, and the local cache is SQLite. For the interface there is tui-input for text entry, tui-popup for dialogs, and webbrowser at 1.2.1, which is how the tool opens a CVE record in your actual browser when you want the full NVD page rather than the terminal summary.

The main crate is Rust, edition 2024, with a minimum supported Rust version of 1.88.0. The licence is MIT OR Apache-2.0, and the project ships both LICENSE-APACHE and LICENSE-MIT files, so you pick.

The audience is a person doing security work from a shell: a responder checking a version against a feed, or an engineer who lives in the terminal and does not want a browser tab to look up one identifier.

Feed selection is where the time and the bandwidth go

The --feeds option is the one that decides how long a first run takes, and the README documents its four accepted forms.

  -f, --feeds [<FEEDS>...]
          Feeds to sync. Accepts a year (`2026`), a year range (`2002:2026`), `recent` (last 8 days
          of new publications) or `modified` (last 8 days of modifications). Multiple feeds can be
          given

          [env: FEEDS=]
          [default: 2002:2026 recent modified]

The default is the entire span from 2002 to 2026 plus recent plus modified. That is every NVD publication since the database's first year, and it is a large download on the first run. Using a single year, or recent for the last eight days of new publications, is the practical choice for a first sync.

The distinction between recent and modified is worth knowing. recent covers newly published records in the last eight days, and modified covers records changed in the last eight days. A CVE that was published years ago and had its description corrected yesterday appears in modified but not in recent, so a security team tracking rewrites needs both.

There is also a force-update flag for the case where the cache already holds a feed you want to re-pull.

  -u, --force-update
          Re-sync feeds that are already present in the cache

And an offline mode that skips the network entirely.

  -o, --offline

The flag is what makes the tool usable on an air-gapped machine, and it is also the reason the database path is worth knowing, because in offline mode the tool can only show what a previous sync put there.

The NVD API key is the difference between minutes and hours

The --api-key option is documented with the reason attached, which is more useful than a bare flag.

  -k, --api-key <API_KEY>
          NVD API key. With a key the rate limit is 50 requests / 30s (instead of 5 / 30s), making
          sync roughly 10× faster. Get one at <https://nvd.nist.gov/developers/request-an-api-key>

          [env: NVD_API_KEY=]

Without a key the NVD allows five requests per thirty seconds. With one it allows fifty. The README puts the effect at roughly ten times faster sync, and that is not a rounding of the limit: it is the limit.

This is the single most consequential setting for a first run. The full default feed set is every year from 2002, and each page of results is one request, so the arithmetic of the rate limit is what decides whether your first sync takes an evening or an afternoon.

The key can be passed as a flag or through the NVD_API_KEY environment variable, and the same pattern holds across the other options: FEEDS for the feeds, DB for the database path, QUERY for the initial search term. Using the environment variables rather than the flags means the key does not end up in your shell history.

The database path is configurable for the same reason.

  -d, --db <DB>
          Path to the SQLite database used to store the synced CVE data

          [env: DB=]

So the cache is a file you choose, and it is a normal SQLite database. That matters for the workflow: you can copy it to another machine, keep a copy for a point in time, or put it wherever your other tooling expects.

Six distributions, three binaries and a Windows installer

The installation section is the longest part of the README, and that is because the tool is packaged properly for the platforms people actually use.

The cargo route needs Rust installed and the SQLite development files present.

cargo install --locked flawz

sudo apt install libsqlite3-dev

The note on Debian and its derivatives is worth pausing on, because a missing SQLite header produces a confusing build error rather than an obvious one.

Then there is a package for each of the major distributions. Arch Linux installs it with pacman -S flawz from the official repositories. Alpine has it in the testing repository for Alpine Edge, so the repository has to be enabled before apk add flawz will work. macOS has it in Homebrew as brew install flawz. NetBSD has it in pkgsrc as pkgin install flawz.

Nix gets two variants, one for the classic channel-based workflow and one for the newer CLI.

nix run nixpkgs#flawz

And there are prebuilt binaries on the releases page for the different targets.

The build from source is two commands.

git clone https://github.com/orhun/flawz && cd flawz/

CARGO_TARGET_DIR=target cargo build --release

The binary lands at target/release/flawz.

The packaging configuration in the manifest is what produces the prebuilt artefacts. The dist metadata names shell, powershell and msi installers, and the target platforms are aarch64-apple-darwin, x86_64-apple-darwin and x86_64-pc-windows-msvc, which is Apple Silicon, Intel Mac and Windows. There is no Linux target in that list, because the Linux distributions package it themselves from source.

The repository also carries a wix/ directory, which is where the WiX toolchain configuration for the Windows installer lives, and release-plz.toml and cliff.toml for the release and changelog automation.

Seven themes and a search that starts populated

The theming is a small feature with an outsized effect on whether you want to keep a tool open, and the list is in the option help.

  -t, --theme <THEME>
          Set the theme

          Possible values:
          - dracula:                    Dracula
          - nord:                       Nord
          - one-dark:                   One Dark
          - solarized-dark:             Solarized Dark
          - gruvbox-light:              Gruvbox Light
          - catppuccin:                 Catppuccin

          [default: dracula]

Dracula is the default, and the rest cover the usual terminal palettes. Gruvbox appears more than once, in a light variant and in a harder dark one, which tells you the palette family has enough shades that a single setting would not have covered it.

The query option is the other piece of the interface worth describing.

  -q, --query <QUERY>
          Start with a search query

          [env: QUERY=]

Combined with the search-and-listing model, that means you can arrive at the interface already narrowed to what you were looking for, which is what makes the xz example a one-liner rather than a sequence of keystrokes.

The rest of the tooling around the binary is ordinary Rust practice. There is a second binary, flawz-completions, which generates shell completions through clap_complete, and a third, flawz-mangen, which generates a man page through clap_mangen. The main clap configuration enables the derive, env, wrap_help and cargo features, which is why the help output above shows the environment variable and default annotations for each flag.

The release profile is tuned for a distributable binary: opt-level 3, lto on, a single codegen unit, symbols stripped and panic set to unwind. The dev profile instead uses opt-level 0 with panic set to abort, which is the usual arrangement for fast debug builds.

Where flawz is the wrong tool

The first wrong-tool case is a team that needs a queryable vulnerability feed rather than a viewer. flawz stores NVD records in SQLite, and the file is real and portable, but the schema is shaped by what the TUI needs to render, not by a documented interface for other tools to query. If your requirement is a scheduled job that joins CVE data against your asset inventory, this is the wrong shape, and the nvd_cve crate or direct API access is the right one.

The second case is a user who needs anything beyond the NVD. The data source is the NVD by default, and the README does not describe support for other feeds, vendor advisories, CISA known exploited vulnerabilities catalogues or EPSS scores. If your question is which CVEs are actually being exploited, the NVD feed alone will not answer it, and flawz has no mechanism to join in another source.

The third case is a first run without an API key and without reading the feeds default. The default of 2002:2026 recent modified combined with a five requests per thirty seconds limit is a long wait, and nothing in the interface warns you about it before it starts. The fix is to request a key and to select a narrower feed, and both are documented, but neither happens on its own.

The fourth case is a workflow that needs continuous monitoring. flawz is an interactive program with a sync step and a browsing step. It has no scheduler, no watch mode and no alerting, and the offline flag exists to read a cache rather than to poll on a schedule.

On maintenance, the release history is worth reading. v0.4.0 and v0.4.1 were both tagged on 2026-06-13, minutes apart, after v0.3.0 from 2024-11-03. So the project was quiet for a long stretch and then shipped two releases in a row on the same afternoon, and the last push was on 2026-06-13. That is a project with an author who returns to it in bursts rather than one shipping continuously, so a dependency on it is a dependency on that pattern.

The dependency tree is small, which is a point in its favour. The manifest also carries a deny.toml for cargo-deny and a typos.toml, and the project keeps a SECURITY.md and a CODE_OF_CONDUCT.md, so the repository is set up for the usual supply chain hygiene even at this size.

Editorial conclusion

flawz suits a security engineer who wants to look up a CVE from the terminal without opening a browser, particularly on a machine with no graphical session, since the whole interface is ratatui and the data lives in a local SQLite file you control. It does not suit a team that needs a vulnerability feed it can query programmatically, because the SQLite schema is an implementation detail of a TUI rather than a documented API. Before adopting, request an NVD API key and pass it with --api-key, because the default rate limit makes the first sync an order of magnitude slower, and check the --feeds default of 2002:2026 recent modified before you start a sync you did not intend to start.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. orhun/flawz on GitHub
4. README
5. Releases