Processor Naming Convention

All Go processors follow a strict naming convention applied consistently across cmd/ directories, Containerfile targets, ECR tags, ECS task definitions, EventBridge schedules, CloudWatch log groups, task-manager.toml, terraform/go-schedules.tf, justfile recipes, GHA workflow steps, and the ECR push hook.

Format

Binary / cmd/ directory: {source}-{type}-processor
Cloud infrastructure (ECS/ECR/EventBridge/CloudWatch): go-{source}-{type}-processor
Justfile local recipe: go-{source}-{type}-backfill
Enrichment justfile recipe: go-enrich-{source}-{type} (no backfill/processor suffix)

Components

Component	Description	Values
source	Short name for the data source	`rustsec`, `cisa-kev`, `nist-nvd`, `ghsa`, `enrich-nuclei`, etc.
type	Data acquisition method	`git` = baked git repo in container, `json` = JSON API or download, `rss` = RSS/Atom feed, `fetch` = web scraping/HTTP fetch, `cvrf` = CVRF XML advisory, `csaf` = CSAF 2.0 JSON advisory, `csv` = CSV files
role	Execution context	`processor` = cloud/binary name, `backfill` = local justfile recipe
prefix	`go-` on justfile recipes and all AWS resource names (NOT on cmd/ directories since they’re already inside `go-processors/`)

Where Each Form Is Used

System	Format	Example
`scripts/go-processors/cmd/` directory	`{source}-{type}-processor`	`cmd/rustsec-git-processor/`
Containerfile target	`AS {source}-{type}-processor`	`FROM scratch AS rustsec-git-processor`
Containerfile data stage	`AS {source}-{type}-data`	`FROM alpine AS rustsec-git-data`
Go binary output path	`/{source}-{type}-processor`	`-o /rustsec-git-processor`
ECR image tag	`go-{source}-{type}-processor-latest`	`go-rustsec-git-processor-latest`
ECS task definition family	`go-{source}-{type}-processor`	`go-rustsec-git-processor`
ECS container name	`{source}-{type}-processor`	`rustsec-git-processor`
EventBridge schedule name	`go-{source}-{type}-processor`	`go-rustsec-git-processor`
CloudWatch log group	`/ecs/vdb-scheduler/go-{source}-{type}-processor`
CloudWatch stream prefix	`{source}-{type}-processor`	`rustsec-git-processor`
GHA workflow step name	`Build and push {source}-{type}-processor`
task-manager.toml key	`[tasks.{source}-{type}-processor]`	`[tasks.rustsec-git-processor]`
task-manager.toml aws_schedule	`go-{source}-{type}-processor`	matches ECS family
`terraform/go-schedules.tf` module name	`{source}_{type}_processor` (snake_case)	`module "rustsec_git_processor"`
`terraform/go-schedules.tf` task_name	`{source}-{type}-processor`	`task_name = "rustsec-git-processor"`
`terraform/go-schedules.tf` ECR image tag	`go-{source}-{type}-processor-${var.tag}`	`go-rustsec-git-processor-latest`
`terraform/ecs.tf` cluster name	`vdb-scheduler`	All scheduled tasks run here
`terraform/logs.tf` DLQ name	`vdb-scheduler-dlq`	Dead-letter queue for failed EventBridge invocations
`.claude/hooks/post-push-ecr.sh` TARGETS entry	`{source}-{type}-processor`	`rustsec-git-processor`
justfile recipe (regular)	`go-{source}-{type}-backfill`	`go-rustsec-git-backfill`
justfile recipe (enrichment)	`go-enrich-{source}-{type}`	`go-enrich-nuclei-fetch`

IMPORTANT: terraform/go-schedules.tf task_name values must match scheduleToTaskName(aws_schedule) — i.e. the aws_schedule value from task-manager.toml with the go- prefix stripped. The scripts/task-dashboard TUI uses task_name as the key to look up schedule expressions and CPU/memory. If task_name is stale (old name), all tasks show as frequency group “Unknown” in the dashboard.

Data Type Classification

Type	When to use	Examples
`git`	Advisory data is cloned from a git repository and baked into the container image at build time	pypi, ghsa, gemnasium, rustsec, ocaml, bitnami, canonical, almalinux, cnvd, drupal, cleanstart, ossfuzz, oss-malware
`json`	Data is fetched from a JSON API endpoint or downloaded as JSON/tar.gz/zip archives at runtime	cisa-kev, nist-nvd, euvd, vulncheck-kev, vulncheck-nvd, crowdsec, certfr, mitre-cve, osv, enrich-googleosi, circl, chainguard, wolfi
`rss`	Data is parsed from RSS or Atom XML feeds	alas, binarly, zdi
`fetch`	Data is scraped from unstructured web pages or fetched via HTTP from non-API sources	enrich-nuclei, enrich-references, 0day-today
`cvrf`	Data is fetched and parsed from CVRF (Common Vulnerability Reporting Framework) XML endpoints — a structured XML advisory protocol distinct from RSS	cisco
`csaf`	Data is fetched and parsed from CSAF 2.0 (Common Security Advisory Framework) JSON endpoints — a structured JSON advisory protocol defined by OASIS	siemens
`csv`	Data is parsed from CSV files	epss
`gsheet`	Data is fetched as a CSV export from a public Google Sheets spreadsheet at runtime	gpz-0day-itw
`snort`	Data is parsed from Snort IDS/IPS rule files — version-specific parsers (v2.x, v3.x)	emergingthreats

Local-Only Tools

Some processors are local-only (no ECS task definition, no EventBridge schedule, no Containerfile target):

0day-today-fetch-backfill — local exploit archive processing
epss-csv-backfill — local EPSS score CSV import
cvelistv5-json-backfill — local cvelistV5 repo processing

These use the backfill suffix in their cmd/ directory name (since they have no cloud processor counterpart).

Enrichment Tasks

Enrichment tasks (enrich-*) are a special category that enrich existing CVE data rather than importing new advisories. Their naming:

cmd/ directory: enrich-{source}-{type} (no processor/backfill suffix — “enrich” is the role)
ECS family: go-enrich-{source}-{type} (same, just with go- prefix)
justfile recipe: go-enrich-{source}-{type} (same as ECS — no backfill suffix since they don’t “backfill”)