Repository navigation
bug(ocsf): top-level container is undefined in OCSF 1.8.0 event classes #4915
Description
User Story
As an operator sending OpenShell OCSF records to a SIEM or a strict OCSF consumer, I want every native record to pass OCSF 1.8.0 validation, so that strict consumers accept the records and I don't need a pipeline step to drop or move fields.
Problem Statement
Sandbox-associated OCSF records carry a top-level container object. OCSF 1.8.0 does not define container as an event-class attribute; it defines it only under the container profile on objects such as device and process. Every native record with a sandbox identity therefore fails validation:
{"error":"attribute_unknown","message":"Unknown attribute at \"container\"; attribute \"container\" is not defined in class \"ssh_activity\" uid 4007."}(https://schema.ocsf.io/api/1.8.0/v2/validate, same result for Network Activity, Base Event and Device Config State Change.)
The in-repo schema validator skips this attribute through KNOWN_UNDEFINED_EVENT_ATTRIBUTES in crates/openshell-ocsf/src/validation/schema.rs, so the tests stay green while the official validator rejects it. #4288 makes the rest of the native output conformant and leaves container unchanged; this issue tracks that remaining gap.
Impact / Why This Matters
- nano's strict OCSF validator rejects every native sandbox record, always on
containeralone (spike results). - Tenzir
ocsf_castand Cribl's Parquet writer drop the field silently, so sandbox identity is lost there. - The Cortex XSIAM OpenShell content pack (demisto/content PRs #46184 and #46275) reads top-level
container.uidandcontainer.namefor sandbox attribution, so moving the field breaks that pack unless it is updated at the same time.
Acceptance Criteria
- Native sandbox records pass
https://schema.ocsf.io/api/1.8.0/v2/validatewith noattribute_unknownerror forcontainer. - Sandbox identity (ID and name) stays available in a defined OCSF attribute, and the docs say where.
-
KNOWN_UNDEFINED_EVENT_ATTRIBUTESno longer listscontainer. - The XSIAM content pack maintainer is told about the change before it ships.
Suggested UX (if applicable)
Two options found so far:
- Nest it as
device.containerand declare thecontainerprofile. Theimageobject then requiresuid, so the emitter must set the image ID or omitimage. - Carry sandbox identity in
unmappedor attributes only, and drop top-levelcontainer.
Option 1 keeps the data in a typed OCSF location.
Reproduction Steps
- Enable supervisor OCSF JSONL for a sandbox:
openshell settings set <sandbox> --key ocsf_json_enabled --value true. - Generate any activity, for example
openshell sandbox exec --name <sandbox> -- true. - POST any
OCSF-JSONrecord tohttps://schema.ocsf.io/api/1.8.0/v2/validate. - Observe
attribute_unknownforcontainer.
Environment
OpenShell 0.1.5 and main; any driver that emits sandbox-associated records.
Activity
fix(ocsf): emit schema-conformant OCSF 1.8 events
aeilot commentedon Oct 27, 2026
Hi! I’d like to work on this issue. Would moving sandbox identity to
device.containerwith the container profile be the preferred approach? I can also update the validation tests and documentation. Is anyone already working on it?fix(ocsf): emit schema-conformant OCSF 1.8 events
fix(ocsf): emit schema-conformant OCSF 1.8 events (NVIDIA#4288)
krishicks commentedon Oct 28, 2026
Written by Claude Code, reviewed by @krishicks
Thanks @aeilot. Nobody else is working on this, so go ahead.
device.containerwith thecontainerprofile is the direction we'd like. Some things we found while looking into it:containeris allowed. In the 1.8.0 exports,containerappears underdevice,process,network_endpointandnetwork_proxy, and only when the event declares thecontainerprofile. It's never a top-level class attribute.device.containeris the natural home, because every builder already setsdevice.imagerequiresuid. OCSF'simageobject requiresuid, butEventContext::container()(crates/openshell-ocsf/src/builders/mod.rs) sets only the imagename, so moving the object as-is would still fail validation. Either fillimage.uidfrom a real image ID or digest if one is available, or omitimagewhen there isn't one. Please don't put the image reference inuid.containeritself only needsnameoruid, and we set both.deviceis the gateway host. Putting the sandbox underdevice.containerthere would claim the gateway host runs the sandbox. For gateway events that concern a sandbox,resources(aresource_detailswith typesandbox) fits better. API Activity and Detection Finding defineresources; Authentication doesn't, and it doesn't emitcontainertoday anyway. The profile choice inapi_activity.rsandfinding.rskeys offctx.container(), so it will need to follow whatever you decide.EventContext::apply_common_fieldssets the top-levelcontainerfor every builder, so the change is mostly there plusBaseEventData.containerfromKNOWN_UNDEFINED_EVENT_ATTRIBUTES(crates/openshell-ocsf/src/validation/schema.rs), or remove the top-levelcontainerallowance inopenshell-ocsf-validate. Either way, the schemas then check the container object itself. The Podman e2e testocsf_jsonl_conformancevalidates real supervisor JSONL and is a good end-to-end check.docs/observability/ocsf-json-export.mdxdescribes the top-levelcontainerand its exception. It should say where the sandbox ID and name live now.We'll let the XSIAM content pack maintainer know about the change (the last acceptance criterion), since that pack reads the top-level
container.uidandcontainer.name. Please mention in the PR when the new shape is final.feat(ocsf): add JSON Schema validator for OCSF events
feat(ocsf): add JSON Schema validator for OCSF events