OpenEASD
See what attackers see. Use it before they do.
Use it as a red teamer to map external surface fast on targets you're authorised to test. Use it as a defender to see what's leaking out of your own infrastructure: subdomains, exposed ports, dangling CNAMEs, missing TLS, known CVEs, without paying $500-5000/mo for a commercial EASM platform.
OpenEASD wraps the open-source recon tools security teams already use: subfinder, amass, alterx, dnsx, subzy, cloud_enum, naabu, nmap, httpx, gau, katana, nuclei, gitleaks, behind a single web UI with scheduling, alerts, and findings tracking. Thirty tools across DNS/DNSSEC, historical DNS records (passive; A/AAAA/MX a domain has resolved to over time), email (SPF/DMARC/DKIM/MTA-STS/open-relay), TLS, SSH, ports, CVEs, subdomain takeover, ASN/IP-range discovery, historical URLs, cloud assets, exposed secrets in JavaScript, leaked secrets in public GitHub (passive; searches GitHub's code-search API for the org's committed credentials and runs gitleaks over the hits — bring-your-own GitHub token), public-source infrastructure exposure (passive; internal hostnames, cloud buckets, and API endpoints leaked in the org's public GitHub repos), infostealer-log exposure (via Hudson Rock's keyless Cavalier API), data-breach exposure (passive; free XposedOrNot tier out of the box, authoritative with a bring-your-own Have I Been Pwned key), Shodan-sourced exposure (passive; free InternetDB tier out of the box, richer with a bring-your-own Shodan key), lookalike / TLD-squat domain detection (passive; phishing infrastructure and brand abuse targeting your domain), technology fingerprinting, web hygiene, and CVE prioritisation (EPSS + CISA KEV). Run a passive scan (public-source only, no authorization needed) or an active scan (probes the target, authorization required). Self-hosted, MIT-licensed, one docker run (single image). Results stay on your machine — unless you enable the optional Cloudflare Workers AI analysis (off by default, explicit consent required), which sends finding data to your own Cloudflare account.
Optionally, OpenEASD can rank each scan's findings by exploitability and explain why (a "fix these first" list with per-finding rationale), schedule targeted follow-up scan steps based on what was found, and write plain-language report and alert summaries — using Cloudflare Workers AI with your own account (credentials saved in Django admin (AI settings), or via CLOUDFLARE_ACCOUNT_ID + CLOUDFLARE_API_TOKEN env vars). Off by default; enabling it requires explicit consent in the UI, every call is audit-logged (never the prompt or response contents), and active follow-up scanning still requires the same domain authorization as manual scans.
Built by Rathnakara GN and Ashok Kamat of Cybersecify, the same tool we run in engagements and on our own infrastructure.
Who this is for
- In-house security engineers and IT-doing-security teams at small-to-mid orgs scanning their own external surface
- Small security consultancies monitoring a handful of clients
- Bug bounty hunters who want a unified view of recon output across programs they're authorised to test
- Solo self-hosters and security learners auditing their own infra
Who this isn't for
- Enterprise SOCs: no RBAC, SAML, or multi-tenant support (single-user by design)
- Anyone needing to scan domains they don't own or aren't authorised to test: OpenEASD is intentionally not a "scan-anyone" hosted service. Running it implies you own or have written authorisation for your targets
Compliance evidence
OpenEASD is not a compliance product and does not make anyone certified. What it does produce is the external scanning evidence auditors ask for, dated and exportable, instead of a screenshot taken the week before the audit.
| What an auditor asks for | Where it comes from |
|---|
| Scanning happens on a defined cadence | Per domain monitoring (6h / 12h / 24h / 48h / weekly) plus one time and recurring schedules, with every run recorded |
| An inventory of internet facing assets | Persistent asset inventory (Django admin): subdomains, IPs, ports and URLs deduplicated across scans, each with first seen, last seen, and active or gone status |
| Findings ranked by real world risk | Severity enriched with EPSS exploit probability and CISA KEV flags, plus an exposure score and grade with movement against the previous scan |
| Evidence that findings get triaged and closed | Issue status (open, acknowledged, in progress, resolved, false positive, accepted risk) with owner, resolution note, first seen, last seen and resolved date |
| Something you can hand over | Per scan CSV export, including the Issue Register |
| Authority to scan the target | Each domain carries a recorded authorization (owner, written consent or bug bounty) with who gave it and when, enforced server side before any active scan |
Control references that usually apply: ISO/IEC 27001:2022 Annex A 8.8 (technical vulnerability management) and A 5.9 (inventory of information and other associated assets); SOC 2 Trust Services Criteria CC7.1 (detection and monitoring) and CC6.6 (boundary protection). Auditors word their requests differently, so treat this as a starting point, not a mapping to cite.
What it does not do: it is not a penetration test, so it does not satisfy requirements that call for one, such as Amazon SP-API Data Protection Policy reviews or most enterprise security questionnaires. It does not look at internal networks, cloud configuration posture, or the policy and process side of either framework.
Supply chain transparency
OpenEASD is a security tool, so it's reasonable to ask whether the tool
itself is trustworthy. Here's what we do (and don't do) to make that
auditable.
What's in the Docker image
Every external tool we ship is downloaded inside the Docker build from
its maintainer's official source. No repackaging, no mirroring:
Verbatim install commands are in the Dockerfile; every
version is pinned. To verify a binary, pull the same version directly
from the upstream URL; it should byte-match what ships in the image.
How the image is built
Every push to main and every v* tag triggers
.github/workflows/ci.yml, which builds
the linux/amd64 single image and publishes to
ghcr.io/cybersecify/openeasd. The build is reproducible from the
public source; the published image carries:
- SBOM (Software Bill of Materials, SPDX format): every package in
the image, retrievable via
docker buildx imagetools inspect
- SLSA provenance attestation: cryptographic proof that the image
was built by this repo's GitHub Actions, not swapped or rebuilt
elsewhere
# The published image carries its own SBOM + provenance:
docker buildx imagetools inspect ghcr.io/cybersecify/openeasd:latest --format '{{ json .SBOM }}'
docker buildx imagetools inspect ghcr.io/cybersecify/openeasd:latest --format '{{ json .Provenance }}'
What we don't do
- No telemetry. OpenEASD doesn't phone home, doesn't check for
updates, doesn't send your scan results anywhere.
- No auto-update. The version you pulled is the version that runs.
- No external callbacks during scans: the only network traffic is
the scan itself, originating from the tools shipped in the image.
Block all egress at your firewall (except what's needed to reach scan
targets) and OpenEASD continues to work.
Continuous security checks
| Check | Tool | Runs on |
|---|
| Python SAST | bandit | Every push + PR |
| Python CVE scan | pip-audit | Every push + PR |
| Semantic security analysis | CodeQL (Python + JS/TS) | Every push + PR + weekly |
GitHub Actions are pinned to commit SHAs (not floating tags) so a
compromised action update can't silently rotate into the build.
Dependabot keeps them current on a weekly cadence.
Open security alerts are public on the
Security tab; we don't hide gaps.
Want to verify? Build from source.
If you don't trust the published Docker image, build it yourself;
every step is in the Dockerfile:
git clone https://github.com/cybersecify/OpenEASD
cd OpenEASD
docker build --target singleimage -t openeasd .
Known gap (named honestly)
- Docker images are not yet cosign-signed. SBOM + SLSA provenance
in the manifest covers the "what's in it + who built it" question;
cosign would add a separate, externally-verifiable signature. On the
roadmap.
For vulnerability reporting, see SECURITY.md.
System requirements
The scan tools (nuclei and amass especially) are memory-hungry. On a host with
too little RAM the kernel will OOM-kill them mid-scan, so scans finish partial or
empty.
| RAM | vCPU | Disk |
|---|
| Minimum | 2 GB | 1 | 5 GB |
| Recommended | 4 GB | 2 | 10 GB |
| 1 GB host | set OPENEASD_LOW_MEMORY=true | 1 | 5 GB |
OpenEASD adapts to the host automatically via OPENEASD_PROFILE (default
auto, detected from RAM):
| Profile | When | Behaviour |
|---|
low | < 2 GB (or OPENEASD_LOW_MEMORY=true) | tools run sequentially, nuclei throttled, amass skips brute — completes on ~1 GB without OOM |
balanced | 2–8 GB | phase-parallel, nuclei -c 25 |
high | ≥ 8 GB | phase-parallel + higher local concurrency and deeper enumeration |
Set -e OPENEASD_PROFILE=low|balanced|high to override auto-detection. On a 1 GB
box, auto-detect picks low (or set it explicitly); a few GB of swap also helps.
On politeness: a bigger box scales local parallelism, not how hard the
target is hit — the per-target request rate stays capped across all profiles, so
high doesn't flood targets or trip their WAFs (which the report flags anyway).
Quick start
The primary deploy is a single Docker image (embedded PostgreSQL + gunicorn + DBOS worker in one container). The /data volume is mandatory (Postgres data + logs live there):
docker run -d --name openeasd -p 8000:8000 -v openeasd-data:/data \
-e SECRET_KEY=<long random> -e DB_PASSWORD=<strong> -e DEBUG=False \
-e ALLOWED_HOSTS=<host,localhost> ghcr.io/cybersecify/openeasd:latest
# or: docker compose -f docker-compose.singleimage.yml up -d --build
For a privilege-separated / scalable setup, use the 3-tier path (PostgreSQL + web + worker via docker compose up -d --build); see Deployment.
Open http://localhost:8000 → log in with admin / admin (you'll be forced to set a new password) → add a domain → run a scan. Full env-var reference, update path, and Kubernetes manifests are under Deployment.
Features
- Automated pipeline: 30-tool scan workflow from domain to findings
- Network attack surface scanning: CVEs, TLS/cert issues, SSH config, network protocol vulnerabilities
- CVE prioritisation: EPSS exploit-probability scores + CISA KEV (known-exploited-in-the-wild) flags enrich CVE findings in place, so you triage by real-world risk rather than severity alone
- Dynamic workflows: predefined scan modes (Passive Light/Deep, Active Light, Full) plus a custom tool selection per scan
- Tool auto-registration: Add new tools with zero core modification
- Live scan progress: Real-time pipeline status with per-tool step tracking
- Scan stop/cancel: Graceful cancellation between tool steps
- Unified findings: All tools write to a single Finding model with lifecycle tracking
- Asset inventory: A persistent, deduplicated view of your attack surface across scans — every subdomain/IP/port/URL with first-seen / last-seen / active-or-gone status; pivot from any asset to its findings and scan history (persistent inventory, browsable in Django admin)
- Continuous monitoring: Per-domain rescans on a configurable schedule (6h / 12h / 24h / 48h / weekly)
- Subscan: Re-run specific tools on existing scan assets without full rediscovery
- Reports: CSV export
- Alerts: Slack and Teams webhooks with configurable severity threshold; alert history in Django admin
- Scheduling: One-time, recurring, and daily automated scans
- Domain authorization enforcement: Each domain requires a recorded authorization (owner / written consent / bug bounty) before an active scan can start; passive-only scans are exempt. Enforced server-side in the scan-start view
- Session auth: Django session login; the default
admin/admin must be changed on first login
Scan Pipeline
── Domain Posture ───────────────────────────────────────────────────────────
Phase 1 Domain Security - DNS, DNSSEC chain-of-trust, email auth
(SPF/DMARC/DKIM/TLS-RPT/BIMI), RDAP checks (passive;
public resolvers + rdap.org — no auth needed)
Phase 1 Domain Probes - Active target probes (needs authorization): AXFR
zone transfer, SMTP open-relay, MTA-STS policy fetch
Phase 1 DNS History - Historical A/AAAA/MX records via a passive-DNS
dataset (passive; BYO DNS_HISTORY_API_URL)
── Brand Threat ─────────────────────────────────────────────────────────────
Phase 1 TLD Squatting - Lookalike / tldsquatting domain detection (passive;
registered lookalikes via public DNS — phishing/brand abuse)
Phase 13 ASN Clustering - Groups registered lookalikes by shared hosting ASN
(Team Cymru, passive) — coordinated phishing infra
── Credential Exposure ──────────────────────────────────────────────────────
Phase 2 Hudson Rock - Infostealer-log exposure via Hudson Rock's keyless
Cavalier API (aggregate counts only, no plaintext)
Phase 2 GitHub Secrets - Leaked secrets in public GitHub via gitleaks
(passive; BYO GITHUB_TOKEN, redacted before storage)
Phase 2 Breach Check - Data-breach exposure via XposedOrNot (free/keyless)
or Have I Been Pwned (BYO key); counts only, no PII
── Asset Discovery ──────────────────────────────────────────────────────────
Phase 3 Subfinder - Passive subdomain enumeration
Phase 3 Amass - Active subdomain enumeration
Phase 3 Alterx - Subdomain permutation from discovered subdomains
Phase 3 ASN Discovery - Owned ASN/CIDR ranges via amass intel (reports only)
Phase 3 GitHub Org Recon - Infra references (hostnames/buckets/API endpoints) in
the org's public GitHub repos (passive; BYO token opt.)
Phase 4 DNSx - DNS resolution, public IP filtering
── Asset Exposure ───────────────────────────────────────────────────────────
Phase 5 Takeover Check - Subdomain takeover detection via subzy (dangling DNS)
Phase 5 Cloud Assets - Public S3/Azure/GCP bucket enumeration (cloud_enum)
── Port Discovery ───────────────────────────────────────────────────────────
Phase 6 Naabu - TCP port scanning (top 100; CDN edge IPs excluded)
Phase 6 Shodan - Passive exposure intel: ports/services/CVEs per IP (free InternetDB; BYO key for full API)
Phase 7 Service Detection - Classify ports as web/non-web via nmap -sV (auto)
── Network Exposure ─────────────────────────────────────────────────────────
Phase 8 Nmap - CVE scanning via NSE vulners (non-web ports)
Phase 8 TLS Checker - Certificate, cipher, and protocol analysis
Phase 8 SSH Checker - SSH configuration audit
Phase 8 Nuclei Network - Network protocol vuln templates (non-web ports)
── Web Exposure ─────────────────────────────────────────────────────────────
Phase 9 httpx - Web probing, URL discovery, technology fingerprinting
Phase 10 Historical URLs - Archived URL discovery via gau
Phase 11 Katana - Deep URL crawl on top of httpx
Phase 12 Nuclei - Web vulnerability scanning (community templates)
Phase 12 Web Checker - Security headers, cookies, CORS; security.txt (RFC 9116)
Phase 12 JS Secrets - Hardcoded secrets in fetched JavaScript via gitleaks
── Prioritization ───────────────────────────────────────────────────────────
Phase 13 CVE Intel - Enrich CVE findings with EPSS + CISA KEV
── AI analysis (optional; off by default, bring-your-own Cloudflare) ──────────
Post-scan Triage - Rank findings by exploitability (CISA KEV + EPSS
outrank raw CVSS) with a per-finding rationale, plus
plain-language report and alert summaries
Post-scan Orchestration - A bounded agent may schedule targeted follow-up
subscans based on what was found (still gated by the
same domain authorization as manual scans)
Every scan probe also carries an honest OpenEASD/1.0 user agent (so a target
can allowlist it), and the report flags WAF/edge blocking so an empty result
means "clean", never "silently blocked".
The AI stage runs only when Cloudflare Workers AI credentials are provided
(saved in Django admin (AI settings), or CLOUDFLARE_ACCOUNT_ID / CLOUDFLARE_API_TOKEN
env vars) and an operator enables it with explicit consent. With it off — the
default — the pipeline ends at Phase 13 and nothing leaves your machine. Every AI
call is recorded in an audit log (time, scan, purpose, model, token counts,
finding IDs); prompt and response contents are never stored.
Architecture
apps/mvp/ - Server-rendered UI: Django views + templates, vendored Bulma + HTMX, session auth
apps/core/ - Infrastructure (never changes), grouped in three layers
console/ - dashboard, insights, reports (CSV), notifications (Slack/Teams),
ai (Cloudflare Workers AI, BYOK), credentials, observability
engine/ - scans, workflows (+ tool registry), durable (DBOS), scheduler,
service_detection (core, always runs), verification
data/ - domains, assets, web_assets, findings, issues, asset_inventory
apps/<tool>/ - 29 tool apps (add/remove freely): domain_security, domain_probe,
dns_history, tldsquatting, hudson_rock, github_secrets, breach_check,
subfinder, amass, asn_discovery, github_recon, alterx, dnsx,
takeover_check, cloud_assets, naabu, shodan, nmap, tls_checker,
ssh_checker, nuclei_network, httpx, historical_urls, katana, nuclei,
web_checker, js_secrets, cve_intel, asn_cluster
See manage.py render_pipeline_diagram and docs/03-system.md for the full pipeline.
Deployment
Single Docker image (primary)
One container runs embedded PostgreSQL + gunicorn + the DBOS worker. The /data volume is mandatory:
docker run -d --name openeasd -p 8000:8000 -v openeasd-data:/data \
-e SECRET_KEY=<long random> -e DB_PASSWORD=<strong> -e DEBUG=False \
-e ALLOWED_HOSTS=<host,localhost> ghcr.io/cybersecify/openeasd:latest
# or: docker compose -f docker-compose.singleimage.yml up -d --build
Trade-off: scanner tools and NET_RAW share the web process (no privilege separation), and web/worker cannot scale independently. Use the 3-tier path below when that matters.
Docker Compose, 3-tier (privilege-separated / scalable alternative)
OpenEASD runs as three services — PostgreSQL + web + worker. Edit the
secrets in docker-compose.yml (SECRET_KEY, DB_PASSWORD, ALLOWED_HOSTS),
then:
docker compose up -d --build
db — PostgreSQL 17 (app data + the DBOS durable-execution schema)web — the slim openeasd-web image (server-rendered UI + synchronous CSV reports; no scanner tools)worker — the openeasd-worker image (DBOS worker + the full scanner matrix, NET_RAW)
For internet-facing or scaled deployments, run all three tiers. Keeping
web, worker, and db as separate containers is deliberate:
- Privilege separation — the internet-facing
web image carries no
scanner tools and no NET_RAW, so a compromised web surface doesn't
inherit the offensive toolkit or raw-socket access (those live only on the
worker, which isn't exposed).
- Fault isolation — nuclei/amass are memory-hungry; if one is OOM-killed
it takes down only a worker, not the UI.
- Independent scaling — Postgres has no single-writer lock, so you can run
multiple
worker replicas pulling the same DBOS queue for scan throughput
while the web tier scales separately for HTTP load.
Collapsing web + worker into one container is possible for a small,
trusted, single-user evaluation, but it puts the scanner tools and NET_RAW
on the exposed process — not recommended for internet-facing deployments.
Keep db as its own container either way so app replacement never risks data.
Open http://localhost:8000, then log in with admin / admin. You will be forced to set a new password before accessing the app.
Production note: ALLOWED_HOSTS="*" is fine for evaluation on a private network. For internet-facing deployments, narrow it to your actual hostname or IP (e.g. ALLOWED_HOSTS="scanner.example.com,127.0.0.1") and set CSRF_TRUSTED_ORIGINS if accessing over a domain.
Update to latest
# Single image: pull, then recreate the container (the /data volume persists)
docker pull ghcr.io/cybersecify/openeasd:latest
docker rm -f openeasd # then re-run the `docker run` command above
# 3-tier compose: the web/worker images are built locally, not pulled
docker compose up -d --build # the db volume persists all data
Environment variables
| Variable | Default | Description |
|---|
SECRET_KEY | insecure default | Django secret key; set this in production |
FIELD_ENCRYPTION_KEY | (derived from SECRET_KEY) | Optional Fernet key (urlsafe-base64, 32 bytes) encrypting BYOK API keys/webhooks at rest. Set it to decouple secret encryption from SECRET_KEY rotation; changing the effective key makes stored secrets unreadable (re-enter them) |
ALLOWED_HOSTS | localhost,127.0.0.1 | Comma-separated hostnames (add your server IP/domain) |
CSRF_TRUSTED_ORIGINS | (none) | Required if accessing via a domain, e.g. https://openeasd.example.com |
DEBUG | False | Set True only for local development |
DB_HOST / DB_PORT / DB_NAME / DB_USER / DB_PASSWORD | db / 5432 / openeasd / openeasd / — | PostgreSQL connection (or set DATABASE_URL) |
DBOS_SCAN_CONCURRENCY | 2 | Max scans executing at once (Postgres has no single-writer lock) |
CLOUDFLARE_ACCOUNT_ID / CLOUDFLARE_API_TOKEN | (none) | Optional AI analysis (or set in Django admin, AI settings) |
SLACK_WEBHOOK_URL | (none) | Slack incoming webhook for scan alerts (can also be set in Django admin, Notification config) |
MS_TEAMS_WEBHOOK_URL | (none) | Teams incoming webhook for scan alerts (can also be set in Django admin, Notification config) |
ALERT_SEVERITY_THRESHOLD | high | Minimum severity to trigger alerts; overridden by the Notification config in Django admin |
SCAN_DAILY_HOUR | 2 | Hour for daily scheduled scans (24h, in ) |
Kubernetes
Manifests are in k8s/. Requires a cluster with an nginx Ingress controller.
1. Set your secret
Edit k8s/secret.yaml and replace REPLACE_WITH_OPENSSL_RAND_HEX_32 with a real key:
openssl rand -hex 32
2. Set your domain
Edit k8s/configmap.yaml (ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS) and k8s/ingress.yaml (host) to match your domain.
3. Deploy
kubectl apply -k k8s/
4. Update to latest image
kubectl rollout restart deployment/openeasd-web deployment/openeasd-worker -n default
Architecture
Three tiers, each its own workload — a default deploy is 3 pods (logs → stdout, no PVC):
| Workload | Command | Resources |
|---|
openeasd-web Deployment | init (migrations/admin) → gunicorn (2 workers) | 256Mi–512Mi, no NET_RAW, Service → :8000 |
openeasd-worker Deployment | manage.py dbos_worker | 512Mi–4Gi, NET_RAW for nmap/naabu, no Service |
openeasd-postgres StatefulSet | PostgreSQL 17 | 10Gi PVC |
Only the openeasd-web Deployment runs migrations (its initContainer); the openeasd-worker Deployment waits for them via the role-aware entrypoint (OPENEASD_ROLE=worker → migrate --check), so there's no DDL race.
Scaling: each Deployment is replicas: 1 by default. Postgres removes the old single-writer limit, so openeasd-worker scales independently — kubectl scale deploy/openeasd-worker --replicas=N adds workers all draining the same DBOS queue, without touching the web tier.
Health check
GET /health/ returns {status, version, git_sha, build_date}, used by K8s readiness and liveness probes (no auth required).
Development Mode
# Starts Django (:8001, serves the UI) + the DBOS worker together
# (needs PostgreSQL running). See the Makefile for the individual commands.
make dev
# UI at http://localhost:8001
Full local-dev guide (prerequisites, first-time setup, CI parity,
troubleshooting): docs/OPERATIONS.md.
CI/CD
GitHub Actions runs on every push to main and v* tags:
- pytest: fast test suite (~1,730 tests, excludes the 42 slow DNS/RDAP tests in
test_domain_security.py)
- bandit: Python SAST scan
- pip-audit: dependency CVE scan
- Docker build: amd64 smoke-build on pull requests only
- Publish to GHCR: the single image
ghcr.io/cybersecify/openeasd (amd64) published on every main push and version tags
HTTP surface
There is no REST API — the UI is a server-rendered plain-Django app (apps/mvp,
session auth) served at /. The Django-Ninja REST API + JWT Bearer auth were removed
(2026-10-14). The only machine-facing HTTP endpoints are:
- Report export:
GET /reports/<scan-uuid>/csv/ (session auth)
- Health:
GET /health/ (unauth, for container/K8s probes)
- Metrics:
GET /metrics/ (Prometheus, opt-in, off by default)
Adding a New Tool
Create a tool app with tool_meta in its AppConfig; no core files to modify:
# apps/my_tool/apps.py
from django.apps import AppConfig
class MyToolConfig(AppConfig):
name = "apps.my_tool"
label = "my_tool"
verbose_name = "My Tool"
tool_meta = {
"label": "My Tool",
"runner": "apps.my_tool.scanner.run_my_tool",
"phase": 6,
"phase_group": "Port Discovery",
"requires": ["naabu"],
"produces_findings": True,
}
Then add "apps.my_tool" to INSTALLED_APPS in openeasd/settings/base.py. The tool auto-registers in the workflow system.
Tool App Structure
apps/my_tool/
apps.py - AppConfig with tool_meta
models.py - Empty (uses core Finding/asset models)
scanner.py - Orchestrator: collect -> analyze -> save
collector.py - Runs binary or probes, returns raw data
analyzer.py - Parses data, builds Finding/asset objects
Running Tests
# Fast tests (excludes slow DNS tests, ~1,730 tests)
uv run pytest tests/ --ignore=tests/unit/test_domain_security.py
# All tests (~1,780 total, incl. the 42 slow DNS/RDAP tests)
uv run pytest tests/
Tech Stack
Backend:
- Django 5.2 LTS: Web framework
- DBOS: Durable-execution engine — task queue + scheduler, Postgres-backed (crash-resumable scans)
- croniter: Cron parsing for the DBOS user-schedule sweep
- WhiteNoise: Serves static files in production (Docker) with gzip compression
- PostgreSQL (+ psycopg 3): Database — app data and the DBOS checkpoint schema
- paramiko: SSH protocol inspection
- cryptography: X.509 certificate analysis
- Django sessions: login/auth for the server-rendered UI (no JWT, no REST API)
Frontend:
- Bulma + HTMX (vendored): server-rendered Django templates, no build step, no Node
License
MIT License - see LICENSE
Author
Rathnakara GN and Ashok Kamat / Cybersecify
