-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Common questions about VulnForge organized by topic.
- General
- Installation
- Scanning
- Vulnerabilities
- Authentication
- Notifications
- Performance
- Troubleshooting
VulnForge is a self-hosted container security dashboard that helps homelab operators monitor Docker container vulnerabilities, compliance, and security hygiene without relying on external SaaS services.
Yes, VulnForge is open-source and free to use under the MIT License.
- Trivy - Vulnerability scanning
- VulnForge Checker - Native CIS Benchmark compliance (20 checks)
- Dive - Image efficiency analysis and layer optimization
No. All scanning happens locally. VulnForge only connects externally to:
- Download Trivy vulnerability database (from GitHub)
- Fetch CISA KEV catalog (if KEV checking enabled)
- Send notifications (if configured)
| Feature | VulnForge | Commercial SaaS |
|---|---|---|
| Cost | Free | $$$-$$$$ |
| Data Privacy | 100% local | Data sent to vendor |
| Deployment | Self-hosted | Cloud |
| Target Audience | Homelabs, SMB | Enterprise |
| Customization | Full control | Limited |
- Docker with Docker Compose
- 1GB RAM minimum (2GB recommended)
- 10GB disk space (for Trivy cache and scan history)
- Linux/macOS/Windows with WSL2
Yes! VulnForge works on:
- Synology DSM (Container Manager)
- QNAP (Container Station)
- TrueNAS Scale
- Unraid (Community Apps)
See Installation Guide.
Not required, but recommended for:
- HTTPS/TLS encryption
- Custom domain names
- SSO integration (Authentik, Authelia)
Yes, you can run VulnForge with:
-
docker runcommands - Kubernetes (Helm chart coming soon)
- Bare metal (Python + Bun)
See Installation Guide for alternatives.
# Pull latest image
docker compose pull vulnforge
# Restart container
docker compose up -d vulnforgeSee Upgrading Guide for version-specific migrations.
Recommended:
- Production containers: Daily
- Development containers: Weekly
- Compliance scans: Weekly
Configure automatic scheduling in Settings → Scan Settings.
Typical scan times:
- Small image (Alpine, 50MB): 10-30 seconds
- Medium image (Node.js, 500MB): 1-2 minutes
- Large image (Python, 1GB+): 3-5 minutes
Factors affecting speed:
- Image size
- Number of packages
- Trivy DB freshness
- Disk I/O speed
Common causes:
- Trivy DB update failed - Network issue, wait and retry
-
Scan timeout - Increase
SCAN_TIMEOUTin Settings - Docker permission denied - Check socket proxy permissions
- Image not accessible - Image requires authentication
- Disk space full - Free up space
See Troubleshooting.
Yes! VulnForge scans all discovered containers, whether running or stopped.
Yes, via API:
# Scan image directly
curl -X POST http://localhost:8787/api/scan/image \
-H "Content-Type: application/json" \
-d '{"image": "nginx:latest"}'Integrate into CI/CD pipelines to block vulnerable images.
VulnForge has offline resilience:
- Attempts to update Trivy DB
- If update fails and DB is recent (<24h), uses stale DB
- Warns if DB is too old (>72h)
- Can be configured to skip scans if DB too stale
Configure in Settings → Scanner Offline Resilience.
KEV = Known Exploited Vulnerability (CISA catalog)
These CVEs have confirmed active exploitation in the wild and require immediate remediation.
Priority order:
- ✅ Critical KEVs - Immediate (hours)
- ✅ Critical non-KEVs - Within 1 week
- ✅ High - Within 2 weeks
⚠️ Medium - Within 30 days- ⏸️ Low - Quarterly review
Not all vulnerabilities pose real risk to your environment. Use triage to mark false positives and accepted risks.
- Fixable: Patch available, upgrade package to fixed version
- Non-Fixable: No patch available yet, requires mitigation or risk acceptance
- Navigate to Vulnerabilities page
- Find the CVE
- Change triage status to "False Positive"
- Add notes explaining why
For recurring false positives, create False Positive Patterns in Settings → Advanced.
Base images (Alpine, Ubuntu, Debian) receive security updates regularly. To remediate:
# Update base image tag
FROM alpine:3.18 # Old version
# To latest patch version
FROM alpine:3.18.4 # Includes security fixesCheck Docker Hub or image registry for newer tags.
No. VulnForge is a scanning and monitoring tool, not a remediation tool.
You must manually:
- Update Dockerfiles
- Rebuild images
- Redeploy containers
- Re-scan to verify
No, but strongly recommended for production deployments.
By default, VulnForge has no authentication. Anyone with network access can view and modify settings.
VulnForge has two separate authentication systems:
User Authentication (Browser Login):
- Local - Username/password with Argon2id hashing
- OIDC/SSO - Single sign-on (Authentik, Keycloak, Auth0, Okta)
API Authentication (External Tools):
- API Keys - Secure keys for TideWatch, scripts, automation
See Authentication Guide.
Yes! User authentication and API authentication work independently:
- Users login via browser (local or SSO)
- Tools use API keys for programmatic access
- Both can be active simultaneously
Local User Authentication:
- Navigate to Settings → Security → User Account
- Click Change Password
- Enter current password and new password
- Click Save
OIDC/SSO:
- Reset password in your OIDC provider (Authentik, Keycloak, etc.)
- VulnForge will reflect changes on next login
Lost Password / Locked Out:
- Stop VulnForge container
- Delete user auth database:
rm data/vulnforge.db - Restart container
- Setup page will appear for new account creation
VulnForge supports 7 notification services:
- ntfy (self-hosted or ntfy.sh)
- Gotify
- Pushover
- Slack
- Discord
- Telegram
- Email (SMTP)
Navigate to Settings → Notifications and click "Test Notification".
Check your ntfy app/web interface for the test message.
Check:
- ntfy URL is correct
- ntfy topic matches subscription
- ntfy token is valid (if using auth)
- Notification settings are enabled
- Thresholds are configured correctly
Test connectivity:
curl -d "Test message" http://ntfy:80/your-topicYes! Configure in Settings → Notifications:
- Critical Threshold: Minimum critical CVEs to alert (default: 1)
- High Threshold: Minimum high CVEs to alert (default: 10)
- Notify on Scan Complete: Toggle all scans or only critical findings
Typical usage:
- VulnForge database: 50-200 MB
- Trivy cache: 500 MB - 2 GB
- Scan history: 10-50 MB per 100 scans
Storage grows with:
- Number of containers
- Scan frequency
- History retention period
Configure retention in Settings → Data Retention (default: 90 days).
- VulnForge: 256-512 MB
- Trivy: 512 MB - 1 GB during scans
- Total: 1-2 GB recommended
Yes! Configure Parallel Scans in Settings → Scan Settings (default: 3).
Recommendations:
- Low-end hardware (NAS, RPi): 1-2
- Mid-range (homelab server): 3-5
- High-end (dedicated server): 5-10
Not currently. VulnForge uses:
- SQLite database (single-node)
- In-memory scan queue
- Background scheduler (APScheduler)
These components are not designed for distributed deployment.
Check socket proxy permissions:
environment:
CONTAINERS: 1
IMAGES: 1
INFO: 1Verify Docker access:
docker exec vulnforge docker ps
# Should list containers- Check Trivy logs:
docker logs trivy - Restart Trivy:
docker restart trivy - Increase scan timeout in Settings
- Check disk space:
df -h
- Run "Discover Containers"
- Wait for scans to complete
- Check browser console for errors
- Verify VulnForge health:
http://localhost:8787/health
SQLite WAL mode should prevent this, but if it occurs:
# Restart VulnForge
docker restart vulnforge
# If persistent, check for stale locks
docker exec vulnforge ls -la /dataTrivy cache growing:
# Clear Trivy cache
docker volume rm vulnforge-trivy-cache
docker restart trivyScan history growing:
- Reduce retention days in Settings
- Manually clean old scans via Maintenance page
- Troubleshooting Guide - Comprehensive problem-solving
- GitHub Issues - Report bugs
- GitHub Discussions - Ask questions
- Installation Guide - Deployment help
- Authentication Guide - Security setup