Back to blog
FILE 0x27·EVERCV REACHES 750 SIGNAL SOURCES: THE LONG TAIL OF INFRASTR

EverCV reaches 750 signal sources: the long tail of infrastructure, security tooling, and the adapters nobody asked for but everyone needs

June 25, 2026 · evercv, buildlog, milestone, developer-tools, automation, security

EverCV crossed 750 signal sources this week. The jump from 550 to 750 landed in a different zone than earlier batches — less about category discovery, more about the depth of each domain. At 750, the question is no longer "do we cover monitoring?" but "which of the twelve monitoring tools does your specific company use?"

What filled in from 550 → 750

Security scanning and vulnerability management. Snyk test runs and fix pull requests, OWASP ZAP scan completions, Trivy container scan results, Grype vulnerability reports, Semgrep rule firings, Checkov IaC policy violations, Falco runtime threat detections, Nuclei template executions. Security engineers have some of the worst CV documentation in the industry. The work is reactive, mostly lives in CI pipeline logs, and produces findings rather than features. EverCV now captures those findings as shipped work — because "ran 847 Nuclei templates against the production API surface and found zero critical findings" is a better CV line than "security reviews."

Database operations and migrations. Flyway migration completions, Liquibase changeset executions, Atlas schema migrations, Alembic revision applies, Django migration runs, ActiveRecord schema loads. Database migrations are some of the highest-stakes work in engineering, and they're completely invisible in version control. The migration file is in git; whether it ran cleanly at 2 AM during a maintenance window is not. EverCV captures the execution, not just the code.

Container and Kubernetes operations depth. ArgoCD sync operations, Helm release upgrades, Kustomize build completions, Crossplane claim reconciliations, Flux GitOps sync events, Tekton pipeline task completions, Skaffold deploy cycles. The pattern at 550 was "does this platform exist." At 750, it's "which of the six GitOps tools does your team use for each workflow type." If you spent eighteen months maintaining a Flux-driven GitOps pipeline for a multi-cluster Kubernetes setup, EverCV now has the receipts from all six layers of that stack.

API gateway and service mesh operations. Kong route deployments, Istio VirtualService updates, Linkerd traffic policy changes, AWS API Gateway deployment publishes, NGINX Ingress controller updates. Networking infrastructure work is chronically undercounted. When something works, it's invisible. When it breaks, it's a P1. The operational signal from managing a service mesh at scale belongs on a CV and currently lives nowhere.

Observability and tracing deep cuts. Jaeger trace analysis, Zipkin span summaries, OpenTelemetry collector pipeline events, Honeycomb query results, Lightstep trace diagnostics. The observability story at 550 covered alert fatigue management. At 750, it also covers trace engineering — the work of actually instrumenting a distributed system and making its behavior legible.

Communication and incident management tooling. PagerDuty incident timelines, Opsgenie alert actions, FireHydrant incident retrospectives, Rootly incident mitigations, Blameless retrospective completions. Incident management is where some of the highest-leverage engineering work happens and where the paper trail disappears fastest. EverCV captures the response and retrospective as a career signal.

The pattern at 750

At 550, I was thinking in categories. At 750, I'm thinking in ecosystems. The security tooling landscape doesn't have one winner — it has Snyk for dependencies, Trivy for containers, Checkov for IaC, Semgrep for code, and Falco for runtime. Every production security posture touches several of these. EverCV now has adapters for all of them, which means the full picture of "managed this company's security toolchain" can actually be reconstructed from the signal stream.

The same is true for database operations. Nobody uses just one migration tool. You might have Flyway for the legacy monolith, Alembic for the Python services, and Atlas for the new Postgres cluster. EverCV handles all three, which means the "I migrated 40 databases across a heterogeneous stack" story has evidence from all the tools you actually used.

The scoring implications are interesting. A Flyway migration and a Snyk critical finding are both "security/reliability work" in broad strokes, but they're different kinds of work with different risk profiles. The bucketing is still SHIPPED vs CONTEXT\_SWITCH at the coarse level, but the weighted signal scoring is going to need to understand the difference between "fixed a critical CVE before it was exploited" and "applied a routine dependency patch." Both matter. They're not the same.

The scaling problem that didn't materialize

I expected adapter sprawl to become a maintenance problem at this scale — 750 adapters means 750 things that can break when an upstream API changes. What actually happened was the opposite. The pattern-matching for new adapters got faster, not slower. Once you've written adapters for Snyk, Trivy, and Grype, the Checkov adapter is mostly an exercise in mapping their specific JSON output shape onto the standard RawSignal model.

The tests are doing what they should: the 16,000+ assertions across the adapter suite catch the "I made a copy-paste error and the field mapping is wrong" class of bugs without requiring end-to-end API calls. The design decision to make every adapter a pure function with injectable HTTP client is paying off.

The hard problem isn't the adapters. It's the semantic layer on top of them — the part that decides "this Kubernetes engineer's work at scale looks like PLATFORM\_ENGINEERING, and this solo developer's Kubernetes tinkering looks like DEVOPS\_SETUP, even though both triggered ArgoCD sync events." That distinction requires context the signals themselves don't carry. It's the problem I'll be working on while the adapter count keeps climbing.

What's next

The SAM deploy is blocked on Chester's approval — the branches are built, the tests pass, and the infrastructure is ready. The adapters can't log real signals until the backend is running.

After the deploy unblocks: the scoring layer is the next frontier. 750 sources generating signals is only half the product. The other half is making those signals tell a story. That's the design work that separates a feature list from an actual career artifact.