Security findings and operational telemetry have lived in separate silos for most of the industry's history, and that split is only now starting to close. In November 2024, the Open Cybersecurity Schema Framework (OCSF) — the vendor-neutral JSON schema originated by AWS, Splunk, CrowdStrike, Cloudflare, Palo Alto Networks, IBM, and Rapid7 — joined the Linux Foundation, and in December 2025 ITU member states backed it for consideration as a formal international standard, with ratification targeted for June 2026. That momentum matters because the practical problem it addresses is mundane and expensive: a scanner finds a critical CVE at 2 a.m., and nobody sees it until the next SCA report ships on Monday, while the same team's on-call rotation is already staring at a Datadog dashboard for CPU and latency alerts. Piping scan output into the tools engineers already watch closes that gap, but naively is expensive — Datadog's log ingestion runs roughly $0.10 per ingested GB plus about $1.70 per million indexed events, with Cloud SIEM analysis tacking on another $0.20 per analyzed GB, so shipping a raw, unfiltered SBOM dump on every build burns budget fast. This post covers how to normalize, filter, and deliver security telemetry into observability platforms without burying the signal your team actually needs to act on.
Why can't you just forward raw scanner output to Datadog or New Relic?
Raw scanner output is built for a human reading a report, not a machine ingesting a stream, and forwarding it as-is produces both noise and unnecessary cost. A full SCA or SBOM scan on a moderately sized monorepo can enumerate hundreds of dependency findings per run, most of them low-severity or already known; piped straight into a logs pipeline, that becomes hundreds of billed, indexed log lines every single build. Observability platforms also expect structured, queryable fields — severity, asset ID, CVE identifier, environment — not a paragraph of scanner prose, so unstructured findings end up unsearchable inside the tool they were sent to. The fix is to filter server-side before transmission (severity thresholds, environment tags, "new since last scan" deltas) and normalize into a consistent schema before it ever reaches the ingestion API, so the observability platform is doing correlation and alerting, not re-parsing free text.
What does OCSF actually solve, and is it ready to rely on?
OCSF solves the normalization problem: a Splunk detection, a CrowdStrike alert, and a dependency scanner finding each arrive in a different native shape, and OCSF gives them a shared taxonomy of categories, classes, and required fields so a single detection rule or dashboard can consume all three. It's real and gaining ground quickly — the Linux Foundation adoption in late 2024 and the December 2025 ITU support for standardization by mid-2026 both point to a schema that's moving past "one vendor's pet format" toward something durable. According to Deepwatch's write-up on OCSF, its maintainers have also begun coordinating with the OpenTelemetry project specifically to bridge security and operational telemetry — which is the exact gap this post is about. It's still young for mission-critical routing logic, so most teams today map into OCSF for storage and cross-tool correlation while keeping OpenTelemetry as the transport layer, rather than treating OCSF alone as an ingestion protocol.
How does OpenTelemetry fit alongside a security-specific schema?
OpenTelemetry (OTel) is the transport and instrumentation layer, while OCSF is the data shape — the two are complementary, not competing. Both Datadog and New Relic accept OTel natively for metrics, logs, and traces, which means a security finding can travel the same OTel Collector pipeline as your application's request traces, tagged with the same service and environment attributes, instead of requiring a bespoke security-only agent. New Relic's primary security-data ingestion path is OpenTelemetry outright. Practically, this means you can emit a scan-completion event as an OTel log record with an OCSF-shaped body: standard OTel resource attributes (service.name, deployment.environment) for routing, and OCSF fields (severity_id, class_uid, finding_info) for the security-specific payload — giving one pipe that both your platform team and your security team can query.
What should actually trigger an alert versus just a logged event?
Not every finding deserves a page, and treating them uniformly is how security alerts get muted the same way disk space at 62% alerts do. A reasonable tiering: log every finding for audit and trend analysis, but only alert on findings that cross a severity threshold and are confirmed reachable or exploitable in a running environment — a critical CVE in a dependency that's never invoked at runtime is audit-log material, not a page. Layer in context the observability platform already has: a vulnerability newly found in a service that's also throwing elevated error rates or was just deployed is a materially different signal than the same CVE sitting quietly in a service that hasn't changed in six months. Routing decisions like "critical + internet-facing + production" to PagerDuty, "critical + internal" to a Slack channel, and everything else to a queryable log index keeps the signal-to-noise ratio survivable.
How does a signed webhook fit into this pipeline in practice?
A signed webhook is the connective tissue between a scanner's native event stream and whatever ingestion API your observability platform exposes. Safeguard's own event catalog is a concrete example of the pattern: it emits events like findings.vulnerability.created, findings.vulnerability.reachability_changed, and scan.completed, each delivered as an HMAC-SHA256-signed payload with an X-Safeguard-Signature header and a replay guard that rejects anything older than five minutes. Consumers verify the signature, then transform and forward — dropping or downgrading anything below a severity or reachability threshold — into Datadog's Logs/Metrics/Events API or an OTel Collector bound for New Relic. Because delivery is at-least-once rather than exactly-once, the receiving side needs to deduplicate on the event's stable ID before writing it into a metrics counter or triggering a downstream alert, or a single retried delivery can double-count a finding.
How Safeguard Helps
Safeguard ships the pieces this pipeline needs rather than leaving teams to assemble them from scratch. The event catalog covers findings, scans, remediation, and policy violations, each with server-side filter expressions (severity in ["critical","high"] and env == "production", for instance) so you only pay to transmit and ingest what's actually alert-worthy, and reachability classification is attached to vulnerability events so downstream routing can distinguish theoretical CVEs from ones your code actually calls. On the delivery side, Safeguard has native Datadog (Logs, Metrics, and Events API) and New Relic (OpenTelemetry) integrations alongside Splunk HEC, Elastic, Chronicle, and Sentinel, plus direct streaming into Kinesis, Event Hubs, and Pub/Sub for teams building their own pipeline. The result is that a critical, reachable finding in production can land in the same Datadog or New Relic dashboard your on-call engineer is already watching — filtered to the findings that matter, not a firehose of every dependency in your SBOM.