DEV Community: Ramin Najjarbashi

CVE-Radar: Multi-Source Open Source CVE Dashboard for DevSecOps Teams

Ramin Najjarbashi — Thu, 18 Jun 2026 05:18:37 +0000

Stop Chasing Vulnerabilities: Meet CVE-Radar, Your Self-Hosted Multi-Source CVE Monitoring Dashboard
In the world of DevSecOps, staying on top of vulnerabilities is exhausting. Thousands of new CVEs drop every week, but most tools either overwhelm you with noise or miss what actually matters to your stack.
That’s why I built CVE-Radar — a powerful, beautiful, and fully open-source vulnerability radar that aggregates multiple trusted sources and shows you exactly what you need to care about.

What is CVE-Radar?

CVE-Radar is an open-source, self-hosted vulnerability intelligence platform that aggregates multiple authoritative sources (NVD, OSV, GitHub, CISA KEV, and major Linux distros) to give you a clear, real-time view of which CVEs actually affect your infrastructure.

Think of it as a smart radar for your entire tech stack — with a modern dashboard, powerful filtering, trend charts, per-tool insights, and multi-channel alerting.

Built with React, TypeScript, Express, and PostgreSQL, it's production-ready, fully Dockerized, and supports both individual developers and enterprise self-hosted environments.

The Architecture & Recent Updates

CVE-Radar is built with a clean, modern full-stack architecture:

Frontend: React + Vite + TypeScript + Tailwind
Backend: Express.js + Drizzle ORM
Database: PostgreSQL + Redis caching
Deployment: Docker Compose (one-command setup) and Kubernetes friendly
Monitoring: Prometheus metrics

Recent Highlights

Major UI/UX improvements to the notification system
Stronger multi-source data aggregation and synchronization
Enhanced dashboard charts and filtering
Better internationalization and RTL support
Overall performance and stability improvements

The codebase is well-structured, documented, and contributor-friendly.

Quick Start: Give It a Spin

Getting CVE-Radar up and running is fast and straightforward. The project includes a complete Docker-based setup with helpful Makefiles.

Installation Steps

# Clone the repository
git clone https://github.com/RaminNietzsche/CVE-Radar.git
cd CVE-Radar

# Install dependencies and start development environment
make setup
make dev

After Running

Web UI → http://localhost:5173
Backend API → http://localhost:3001

Default admin credentials and further instructions will appear in the terminal.

Recommended Enhancements

Add these to your .env file for optimal performance:

NVD_API_KEY=your_nvd_key_here
GITHUB_TOKEN=your_github_token_here

Production Mode

make build
make up

For advanced deployment options (Kubernetes, Air-gap, custom domains, etc.), check the full documentation in the repository.

Open Source & Proud: How You Can Help

CVE-Radar is fully open source under the MIT license, and I built it to be community-driven from day one.

Whether you're a developer, security engineer, DevOps practitioner, or just someone who cares about better vulnerability management tools — there are many ways to contribute:

Ways to Get Involved

Star the Repository — It helps with visibility and shows support ⭐
Try it out and share your feedback (open an Issue or start a Discussion)
Report bugs or suggest new features
Contribute code — The project has several “good first issue” labels for beginners
Add new features like:
- More notification channels
- Additional vulnerability sources
- Improved matching algorithms
- Better Kubernetes integration
Improve documentation or write blog posts/tutorials
Spread the word in your community, Discord servers, or workplace

Current Status

Latest Version: v1.4.0
Actively maintained with regular updates
Contributor-friendly codebase with clear architecture and good documentation

Every contribution — no matter how small — helps make CVE-Radar more powerful for the entire DevSecOps community.

Ready to join?

👉 Check out the project here: github.com/RaminNietzsche/CVE-Radar

Feel free to drop your thoughts, questions, or ideas in the comments below. What features would you like to see next? Let's build something great together! 🚀

Let’s Chat!

I’d love to hear from you!

Whether you’ve tried CVE-Radar, have feedback, found a bug, or just want to share how you handle vulnerability management in your organization — drop a comment below.

Questions I’d especially like your thoughts on:

What’s your biggest pain point with CVE monitoring today?
Which features would make this tool more valuable for your workflow?
Have you used similar tools (like Dependency-Track, Trivy, or Grype)? How does CVE-Radar compare?
Any new data sources or notification channels you’d like to see added?

Your feedback directly shapes the future of the project.

Thank you for reading! ❤️

If you found this useful, please consider:

⭐ Starring the repo
Sharing it with your team or network
Trying it out and letting me know how it goes

👉 GitHub Repository

Looking forward to your comments and contributions! 🚀

The Great Orphan Object Hunt: How I Fixed Our Cloud Storage Woes

Ramin Najjarbashi — Mon, 27 Mar 2023 21:27:41 +0000

As an SRE working with a cloud provider and object storage, I've learned firsthand how tricky it can be to keep a Ceph cluster running smoothly. And while most of the time, everything hums along just fine, every once in a while, we encounter a problem that leaves us scratching our heads.

Recently, we started getting calls from users who were confused about their usage metrics. They were seeing that the sum of all objects in their buckets was many fewer than what we were showing in our panel, and naturally, they were concerned. After some digging, we discovered that there were orphan objects stuck in the cluster - objects that couldn't be shown by any client, like s3cmd, boto3, or mc.

Now, with billions of objects in our cluster, finding and removing these orphan objects was no easy task. I tried using normal tools, but they just weren't up to the job. So, I had to get creative.

I started by creating a bash script that would help me identify and remove these orphan objects. Here's the code:

#!/bin/bash

#set -e

if [ -z "$1" ]
  then
    echo "No bucket name provided"
    exit 1
fi
BUCKET=$1

BUCKET_ID=$(radosgw-admin bucket stats -b $BUCKET | jq -r '.id')
if [ -z "$BUCKET_ID" ]
  then
    echo "Failed to get bucket ID for $BUCKET"
    exit 1
fi

INDEX_POOL=$(radosgw-admin zone get | jq '.placement_pools[].val.index_pool' -r)
DATA_POOL=$(radosgw-admin zone get | jq '.placement_pools[].val.storage_classes[].data_pool' -r)
ORPHANS=$(radosgw-admin bucket check -b $BUCKET | jq -r ".[]" )
if [ -z "$ORPHANS" ]
  then
    echo "No orphan objects found in $BUCKET"
    exit 0
fi

UPLOAD_ID=""
for object in $ORPHANS
do
  NEW_ID=$(echo $object | awk -F '.' '{print $(NF-1)}')
  UPLOAD_ID="$UPLOAD_ID $NEW_ID"
done

# You must Remove this objects from data pool
ORPHAN_OBJECTS_DATA=$(radosgw-admin bucket radoslist -b $BUCKET | egrep --text  "($(echo $UPLOAD_ID | tr ' ' '|' ))")
if [ -n "$ORPHAN_OBJECTS_DATA" ]
  then
    while read -r object
    do
      echo rados -p $DATA_POOL rm $object || true
    done <<<  "${ORPHAN_OBJECTS_DATA// /\\ }"
  fi

# You must Remove this omapkeys from index pool
SHARDS=$(radosgw-admin bucket stats -b $BUCKET | jq -r ".num_shards")
for (( COUNTER=0; COUNTER<$SHARDS; COUNTER+=1 ))
do
  ORPHAN_OMAP=$(rados -p $INDEX_POOL listomapkeys .dir.${BUCKET_ID}.${COUNTER} | egrep --text "($(echo $UPLOAD_ID | tr ' ' '|'))")
  if [ -n "$ORPHAN_OMAP" ]
    then
      while read -r omap
      do
        echo rados -p $INDEX_POOL rmomapkey .dir.${BUCKET_ID}.${COUNTER} $omap
      done <<< "${ORPHAN_OMAP// /\\ }"
    fi
done

# Fix bucket
echo radosgw-admin bucket check -b $BUCKET --fix

This script uses radosgw-admin to check for orphan objects in a specified bucket, then removes them from both the data pool and the index pool. It's not a perfect solution, but it worked for us - and it might just work for you too!

But why do orphan objects even happen in the first place?

Well, it's a complicated issue, and one that's beyond the scope of this post. But suffice it to say that they can be caused by a number of factors, including bugs in the system, network issues, or even user error.

So, what can you do if you find yourself in a similar situation?

My advice would be to start by using a script like the one I've provided here to identify and remove any orphan objects in your cluster. But beyond that, there are a few best practices you can follow to help prevent orphan objects from occurring in the first place:

Keep your software up-to-date: Orphan objects can sometimes be caused by bugs in older versions of your storage software. Make sure you're always running the latest stable release.
Monitor your cluster closely: Regularly monitoring your cluster's performance can help you catch orphan objects early, before they become a big problem.
Educate your users: Make sure your users understand how to use your storage system correctly to minimize the risk of orphan objects caused by user error.

In conclusion, the Great Orphan Object Hunt was a challenging but ultimately rewarding experience. By using a bit of creativity and some handy tools, we were able to fix our cloud storage woes and keep our users happy. And with a bit of luck, we'll be able to avoid orphan objects altogether in the future!

UPDATE:

https://tracker.ceph.com/issues/16767