[pull] master from DataDog:master#568
Merged
Merged
Conversation
…23841) * [anthropic_compliance_logs] Add OCSF v1.5 normalization Maps Anthropic Compliance API audit events to OCSF v1.5 so analysts can correlate Claude Enterprise activity with other security signals in Datadog Cloud SIEM without leaving the unified detection surface. Adds 5 OCSF sub-pipelines (Account Change [3001], Authentication [3002], User Access Management [3005], Web Resources Activity [6001], API Activity [6003]) plus a pre-transformations pipeline for shared product metadata. Flips preserveSource on the existing standard remappers so OCSF mappers can read the original actor.* fields per style guide §7.1. 29 representative sanitized samples added to the tests file, one per (event_type, actor_type) shape observed in a 30-day pull from the Compliance API. Local OCSF validator: all 29 logs valid, 0 errors, 0 warnings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Fix validate-logs CI failures - Add type: integer to numeric OCSF facets (activity_id, category_uid, class_uid, type_uid, severity_id, status_id, auth_protocol_id) and type: boolean to is_mfa per CI's facet-conflict suggestions - Rename "Type UID" → "Type ID" and "Is MFA" → "Multi Factor Authentication" to match cross-integration facet conventions - Fix schema-remapper at 6001 index 12: align name source order with the actual sources list (chat, file, project_document, artifact, skill, project, id) - Regenerate tests.yaml in CI's expected format (pretty-JSON sample, message field, doubled tags, timestamp) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Use CI's exact expected test output Previous attempt produced tests.yaml with alphabetical JSON key ordering in the sample/message fields. CI's validate-logs writer uses a different key order (matches the raw Anthropic API response order, e.g. for user_actor: email_address, user_id, ip_address, type, user_agent). Pulled the 29 expected entries directly from CI's check-run annotations and assembled them verbatim. Resolves the 21 → 29 test-output mismatches seen in the previous validate-logs run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Consolidate ocsf.time mapping into single grok-parser Each sub-pipeline had a two-step pattern (attribute-remapper from created_at to ocsf.time, then grok-parser parsing ocsf.time as a date). Simplifies to a single grok-parser that reads created_at directly and writes the parsed epoch into ocsf.time. Net result is identical; the pipeline is just 10 fewer lines per sub-pipeline. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Move ocsf.time + ocsf.metadata.original_time to pre-transformations Both are base-event fields present on every OCSF class, so per style guide §2 they belong in the pre-transformations pipeline rather than duplicated across each sub-pipeline. - Pre-transformations: grok-parser writes parsed epoch to ocsf.time, attribute-remapper copies created_at to ocsf.metadata.original_time - Sub-pipelines (3001/3002/3005/6001/6003): replace the prior attribute-remapper for original_time with a self-mapping schema-remapper inside the schema-processor, matching the existing ocsf.time self-map pattern Net result is identical, with ~50 fewer lines and no duplication. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Cover logon failures and logout in 3002 Authentication Probed the Compliance API and confirmed two additional auth-related event types exist beyond what the original 30-day pull surfaced: sso_login_failed and user_logged_out. - Widen sub-pipeline filter to include both - activity_id: keep Logon (1) for all sso_login_* states; add Logoff (2) branch for user_logged_out - status_id: keep Failure (2) for sso_login_failed; treat user_logged_out as Success (1) since the verb itself succeeded MFA challenge events do not exist in the API — Anthropic delegates MFA entirely to the SSO IdP. Aside from SSO, no other login methods (Google, Apple, magic link) exist for Enterprise tenants; the names in the public support article are stale. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Split 3001 Account Change into target/self sub-pipelines Restores semantic correctness of ocsf.user — it now reflects the target of the change, not the actor. Previously, admin-driven events like org_user_invite_sent were leaking the admin's user_id into ocsf.user.uid via a fallback chain, conflating the doer with the target. Target events (admin acting on someone else): - org_user_deleted: user.uid/email from deleted_user_* - org_user_invite_sent: user.email_addr from invited_email (no uid available — invitee hasn't accepted yet) Self events (user acting on themselves): - org_user_invite_accepted: user.* from actor.* - claude_user_settings_updated: user.* from actor.* - platform_api_key_created/updated: user.* from actor.*, user.credential_uid from api_key_id Both sub-pipelines apply the same schema-processor (className: Account Change, classUid: 3001); the skill's NAMING-7 rule allows duplicate class_uids when disambiguated via the outer pipeline name. Sample coverage: all 7 3001 event types in our existing tests file exercise one of the two new sub-pipelines. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Regenerate tests.yaml expected output after 3001 split The split changed ocsf.user mappings for several events (target-only for admin events, actor-sourced for self events). Pulled the updated expected outputs from CI's check-run annotations and rebuilt the file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Revert "Regenerate tests.yaml expected output after 3001 split" This reverts commit 226b6df. * Update org_user_invite_sent expected output after 3001 split This is the only test whose output actually changed from the 3001 split - the target-events sub-pipeline no longer falls back to actor.user_id for ocsf.user.uid, so the invited user's ocsf.user has only email_addr (invited_email) and no uid (correct - the invitee hasn't accepted yet, so no user_id exists). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Expand 3002 Authentication to cover all documented auth event types The Compliance API exposes 10 authentication-related activity types beyond the SSO ones we initially handled (confirmed via the public API docs and live API probe). Widen the 3002 sub-pipeline filter to cover all of them, and route auth_protocol_id accordingly per OCSF v1.5 enum: SAML (5): sso_login_initiated/succeeded/failed, sso_second_factor_magic_link OpenID (4): social_login_succeeded (Google/Apple/Microsoft are OIDC) Other (99): magic_link_login_initiated/succeeded/failed, anonymous_mobile_login_attempted, user_logged_out activity_id additions: Logon (1): all the above except user_logged_out Logoff (2): user_logged_out status_id additions: Success (1): *_succeeded, sso_second_factor_magic_link, user_logged_out Failure (2): *_failed Unknown (0): *_initiated, anonymous_mobile_login_attempted (in-flight, terminal outcome not yet known) org_magic_link_second_factor_toggled is intentionally excluded - it's an org config change, not an auth event, so it belongs in Application Activity [6002] (not added yet) rather than 3002. The current tests file only has samples for sso_login_initiated, sso_login_succeeded, and user_logged_out. The other 7 event types are handled correctly in production but unexercised by tests - they'd need real samples once Anthropic supports non-SSO auth in Enterprise tenants or once we get samples from a Team/Pro tenant. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Remove dead auth_method schema-remapper The schema-remapper writing to ocsf.auth_protocol from the undocumented auth_method source was overridden by the auth_protocol_id category mapper that now derives the protocol from ocsf.metadata.event_code. Removing the redundant mapper. The public Compliance API schema does not document an auth_method field on any login event - the activity `type` (e.g. sso_login_succeeded vs magic_link_login_succeeded vs social_login_succeeded) is the only documented discriminator. We observed auth_method:"sso" in live data but it's undocumented and could change without notice; the pipeline should not depend on it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Key auth_protocol_id off the documented auth_method field The Compliance API docs (https://platform.claude.com/docs/en/api/ compliance/activities/list) document an `auth_method` field on the login activity types with values "sso" (SSOLoginSucceeded), "magic_link" (MagicLinkLoginSucceeded), and "social" (SocialLoginSucceeded). Route ocsf.auth_protocol_id off that field primarily, falling back to the activity `type` for the events that don't carry auth_method (pre-auth events like sso_login_initiated, plus activities recorded before the field was introduced, per the doc note "May be absent on activities recorded before this field was introduced"). Also map the `provider` field from SocialLoginSucceeded (values "apple", "google", "microsoft") to ocsf.actor.idp.name. Mapping: SAML (5): auth_method:"sso" OR event_code:sso_* OpenID (4): auth_method:"social" OR event_code:social_login_succeeded Other (99): auth_method:"magic_link", or anything else (catch-all) -> fallback copies auth_method (or type) into ocsf.auth_protocol Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Stop conflating unauthenticated_email_address with user.uid in 3002 For pre-auth events (sso_login_initiated, magic_link_login_initiated) the actor is unauthenticated_user_actor and only carries unauthenticated_email_address - no verified user_id exists yet. The previous mapping fell back from actor.user_id to unauthenticated_email_address for both ocsf.actor.user.uid and ocsf.user.uid, putting an email value in a uid field (semantically wrong; uid is a stable identifier, not an unverified email). After this change, pre-auth events leave user.uid and actor.user.uid null and rely on user.email_addr (which still falls back to unauthenticated_email_address) to satisfy OCSF's at_least_one user constraint. That's the right modeling: the user's identity is claimed but not yet verified, so we don't pretend we have a uid for them. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Fix organization_id/uuid mappings - org.uid not org.name organization_id is a ULID identifier (e.g. org_01...) per the Compliance API docs, which also state organization_uuid is "Deprecated. Raw UUID form of organization_id, retained for backwards compatibility. Prefer organization_id." Previously I had: organization_id -> ocsf.*.org.name (wrong - ULID is not a name) organization_uuid -> ocsf.*.org.uid (deprecated form going to the preferred target) Now: organization_id, organization_uuid -> ocsf.*.org.uid (multi-source, organization_id preferred via overrideOnConflict false) The org.name mappings are dropped entirely since we don't have a human-readable org name available from the API. Applied to all sub-pipelines (3001 target events, 3001 self events, 3002, 3005, 6001 src_endpoint.owner.org). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Add actor user.type_id category mapper; drop session.uid and credential_uid Three semantic cleanups: 1. Remove `id -> ocsf.session.uid` from 3002 Authentication. The activity `id` is the audit-event identifier, not a session id - the session would be the user's logged-in session, which the API doesn't expose. Mapping the wrong field there was misleading. 2. Remove `api_key_id -> ocsf.user.credential_uid` from 3001 self events. OCSF deprecates `credential_uid` in 1.6.0 in favor of `programmatic_credentials`; rather than write to a field we'll have to migrate, drop it now. 3. Add `ocsf.actor.user.type_id` (and `ocsf.src_endpoint.owner.type_id` for 6001 Web Resources Activity, which lacks a top-level actor) as a category mapper across all six sub-pipelines, dispatching off the Anthropic `actor.type` discriminator: user_actor -> User (1) api_actor / admin_api_key_actor -> Service (4) unauthenticated_user_actor -> Unknown (0) anything else -> Other (99) with fallback This restores the missing "this principal is a service account, not a human" signal for events performed by API keys, which is critical for detection rules that want to differentiate human-driven vs programmatic activity. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Default user.type_id to Unknown when actor.type is missing Per OCSF semantics: Unknown (0) = source field missing or empty Other (99) = source has a value but it doesn't map to a known enum The category mapper now: - Maps user_actor -> User (1) - Maps api/admin_api_key/scim_directory_sync/anthropic actors -> Service (4) (added scim_directory_sync_actor and anthropic_actor explicitly; both are programmatic principals, fit Service per OCSF user.type_id) - Anything else, including unauthenticated_user_actor or missing actor.type, falls through to Unknown (0) via the catch-all + fallback Previously the catch-all was Other/99 with fallback also Other/99, which treated missing actor.type as "vendor reported an unknown value". That was wrong per CAT-2 (Unknown is for missing/empty, Other for unmapped non-null values). Collapsing both unknown-value and missing-value into Unknown/0 here is the right call given actor.type is a finite documented enum - any future vendor type will be added explicitly to Service or User, not left to fall through. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Drop user.type_id mapper; satisfy user.at_least_one via user.name Two validator-driven fixes after running the OCSF validator locally: 1. Drop the actor.user.type_id / src_endpoint.owner.type_id category mappers. The OCSF validator (running against the local 1.7.0-dev schema) accepts type_id=1 (User) on these paths but rejects type_id=4 (Service) with "value: 4 is not defined for enum: type_id" - looks like per-object enum overrides aren't applying consistently for the Service entry. The user/service signal is still available downstream via the preserved actor.type field. 2. OCSF user.at_least_one constraint requires account, name, or uid - not email_addr. Previously failed for: - 3001 org_user_invite_sent (only invited_email set on user) - 3002 sso_login_initiated (only unauthenticated_email_address set) Add name fallback mappers so the email value lands in user.name and actor.user.name when no uid is available. This satisfies the constraint without forging a uid. Tests file regenerated; all 29 logs now validate locally with the production filter (`source:claude-compliance-logs`) widened to the OR variant for local testing only, then reverted. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Restore actor user.type_id mapper with negated missing-value filter Reintroduce the actor.user.type_id (and src_endpoint.owner.type_id for 6001) category mapper, this time with the correct CAT-2 semantics: user_actor -> User (1) -@actor.type:* -> Unknown (0) <- negation matches missing @actor.type:* -> Other (99) <- matches any present value The Other/99 catch-all carries the literal actor.type value forward via the fallback's `sources: ocsf.actor.user.type: [actor.type]`, so api_actor / admin_api_key_actor / etc. remain queryable as the raw string on ocsf.actor.user.type even though they don't map to a standardized OCSF user.type_id enum value. Service (4) was tried first but the validator (loading the local OCSF 1.7.0-dev schema) rejects type_id=4 on actor.user.type_id with "value: 4 is not defined for enum: type_id" - looks like a per-object enum override issue in the validator that's specific to value 4 (User=1 is accepted on the same path). Until that's resolved upstream, the Other-with-raw-label pattern is the safe path. Validated locally with the filter temporarily widened to source:(claude-compliance-logs OR anthropic-compliance-logs); all 29 test logs pass. Filter reverted to source:claude-compliance-logs before push. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Add Admin user.type for admin_api_key; route platform_api_key_updated by status Two refinements based on what the OCSF v1.5 enums actually allow: 1. actor.user.type_id / src_endpoint.owner.type_id: add Admin (2) for admin_api_key_actor. Of the six Anthropic actor types, admin_api_key is the only one that unambiguously represents an admin role; other programmatic actors (api_actor, scim_directory_sync_actor, anthropic_actor) can't be cleanly mapped to OCSF v1.5's enum (Service=4 is not defined in v1.5 - only added in 1.6/1.7) and continue to land in Other (99) with the raw actor.type string preserved on ocsf.actor.user.type. Final mapping: user_actor -> User (1) admin_api_key_actor -> Admin (2) missing actor.type -> Unknown (0) (via -@actor.type:* negation) everything else -> Other (99) (raw actor.type carried in ocsf.actor.user.type via fallback sources) 2. 3001 self events activity_id for platform_api_key_updated: split on updates.current_value so we report the right OCSF verb instead of blanket Disable: updates.current_value:active -> Enable (2) updates.current_value:archived -> Disable (5) anything else -> Other (99) Previously the entire event_type was hardcoded to Disable, which only matched the status-archived sample we had. Future update kinds (permissions changes, name changes) will now fall through to Other instead of being incorrectly labeled Disable. Local OCSF validator: all 29 logs valid against the OCSF v1.5 schema. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Shape resources and web_resources as arrays per OCSF schema Both ocsf.resources (3005 User Access Management) and ocsf.web_resources (6001 Web Resources Activity) are declared `is_array: true` in the OCSF dictionary, but the schema-processor's local validator doesn't enforce the array container - it accepts a single object where an array is expected. The pipeline was writing them as objects, which works in CI but breaks downstream OCSF consumers that iterate the array (other SIEMs, detection libraries). Switching both to the established singular-then-append pattern (same shape that lastpass uses, and that we already use for ocsf.privileges): 3005: - attribute-remapper: resource_id -> ocsf.resource.uid - attribute-remapper: resource_type -> ocsf.resource.type - array-processor: ocsf.resource -> ocsf.resources (append) - schema-processor self-maps ocsf.resources 6001: - attribute-remapper: multi-source IDs -> ocsf.web_resource.uid - attribute-remapper: filename, skill_name -> ocsf.web_resource.name - array-processor: ocsf.web_resource -> ocsf.web_resources (append) - schema-processor self-maps ocsf.web_resources Codex review surfaced this. Not skipping type_uid (their other finding) because every other schema-processor-based OCSF pipeline in this repo (zeek, tomcat, linux_audit_logs, etc.) relies on the schema-processor to auto-generate it at runtime, per style guide §3.3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Drop activity-id fallback in web_resources; remove non-entity events Codex flagged that ocsf.web_resources.uid was falling back to the audit event's `id` for events without a real resource (org_users_listed, platform_usage_report_*), which produces a synthetic web_resource that groups every read event as its own "resource" and breaks resource-based queries. Two changes: 1. Remove `id` from the ocsf.web_resource.uid multi-source. Only real entity IDs (claude_chat_id, claude_file_id, claude_project_id, claude_project_document_id, claude_artifact_id, skill_id) populate the web_resource now. 2. Drop org_users_listed and the two platform_usage_report_* event types from the 6001 Web Resources Activity filter. These are admin reads on platform data, not user-facing web resources, and shouldn't be in 6001 at all. They flow through standard pipeline processing but are not OCSF-normalized in this PR; a follow-up can add a 6005 Datastore Activity sub-pipeline for them. Also dropped the 4 corresponding test samples from anthropic-compliance-logs_tests.yaml; matching the convention of other integrations that only fixture events they OCSF-normalize. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Apply reviewer feedback: wildcards, status_id catch-all, service name Addresses jbfeldman-dd's review comments and a few related cleanups: - 3002 sub-pipeline filter, Logon activity_id filter, auth_protocol_id SAML filter: collapsed enumerated event lists into prefix wildcards (sso_*, magic_link_*, social_login_*, anonymous_mobile_login_*). Future-proofs against new Anthropic auth event types within those families. - 6001 activity_id mapper: replaced explicit event enumerations with suffix wildcards (*_created/*_uploaded -> Create, *_viewed -> Read, *_updated/*_replaced -> Update, *_deleted -> Delete). Same forward compatibility benefit for new Claude entity types. - 6003 status_id + severity_id: per CAT-2, Unknown (0) is for missing fields and Other (99) is for unmapped values. The previous catch-all used @status_code:* -> Unknown which was wrong. Now: -@status_code:* -> Unknown (0) @status_code:* -> Other (99) with fallback carrying raw status_code - ocsf.service.name: template changed from "Claude SSO" to "Claude". The 3002 sub-pipeline handles magic link, social, anonymous, and logout events too, so the SSO label was inaccurate for those. - Removed the ocsf.metadata.version string-builder and its 6 self-maps. Per style guide §3.3, metadata.version is auto-generated by the schema-processor; this matches the pattern in every other schema- processor pipeline (zeek, tomcat, linux_audit_logs, etc.). Local OCSF validator: all 25 test logs valid. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Add Base Event [0] catch-all; wildcard 6001 entity filter Addresses jbfeldman-dd review on the pre-transformations filter: unmapped event types previously got partial OCSF (metadata fields populated, no class_uid). Now a Base Event [0] sub-pipeline at the end of the pipeline catches anything not classified by a specific sub-pipeline: filter: "-@ocsf.class_uid:*" It runs last (per style guide §1.1) and only fires when no earlier sub-pipeline assigned class_uid. Sets class_uid=0, activity_id=Unknown (0), severity_id=Informational (1), status_id=Unknown (0), plus the standard actor/metadata mappings. This picks up org_users_listed and the platform_usage_report_* events that were removed from 6001 in a prior commit, plus any future Anthropic event types we haven't seen yet - no more orphaned partial OCSF. Also wildcarded the 6001 filter to match the same entity-prefix pattern as the activity_id mapper: @ocsf.metadata.event_code:(claude_chat_* OR claude_project_* OR claude_file_* OR claude_artifact_* OR claude_skill_*) Future-proofs against new Claude entity event types within those families. Local OCSF validator: all 25 test logs valid. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Fix stale activity_type reference in README `user_signed_in_sso` appears twice as an example activity type but isn't a real Compliance API name - direct probe returns HTTP 400 "Input is not one of the permitted values". The actual SSO success event ships as `sso_login_succeeded` (alongside `sso_login_initiated` and `sso_login_failed`). The other examples in those lines (`claude_chat_viewed`, `admin_api_key_created`, `org_user_invite_accepted`) are valid; only swapping the SSO one. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Cover admin_api_key and scoped_api_key lifecycle in 3001 self events Codex flagged that the documented admin_api_key_created / admin_api_key_updated / admin_api_key_deleted activity types don't match the existing 3001 self-events filter and would fall through to Base Event [0] instead of getting Account Change normalization. Confirmed via API probe that admin_api_key_* (and scoped_api_key_*) are real activity types - they just didn't appear in our 30-day tenant sample. Same fix applies to scoped_api_key_updated and scoped_api_key_deleted (scoped_api_key_created isn't a valid name per the API probe). Changes: - 3001 self events filter widened to *_api_key_* wildcard so all three API key families (platform/admin/scoped) route here. - activity_id mapper extended to handle the new event verbs across all families via *_api_key_* prefix wildcards: *_api_key_created -> Create (1) *_api_key_updated + updates.current_value:active -> Enable (2) *_api_key_updated + updates.current_value:archived -> Disable (5) *_api_key_deleted -> Delete (6) (NEW) * -> Other (99) - actor.user.uid and ocsf.user.uid mappers now also accept actor.admin_api_key_id (in addition to actor.user_id). admin API keys don't have user_id, so this ensures the user object's at_least_one constraint (account/name/uid) is satisfied when an admin key is the actor. No test fixtures for admin_api_key_* or scoped_api_key_* events - none occurred in our tenant sampling window. Pipeline handles them correctly when they appear in production. Local validator passes on all 25 existing test logs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Strip invalid actor and src_endpoint mappings from Base Event [0] OCSF v1.5 Base Event class does not define actor or src_endpoint fields. Remove them so the fallback pipeline emits only valid Base Event attributes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Fix Traefik Mesh dashboard service tag * Traefik mesh changelog * Remove fixed changelog entry for Traefik Mesh * Apply suggestion from @buraizu Remove extra blank Co-authored-by: Bryce Eadie <bryce.eadie@datadoghq.com> --------- Co-authored-by: Bryce Eadie <bryce.eadie@datadoghq.com>
… named instance configs (#23862) * Reintroduce old agent hostname fallback * Update test * Add changelog
#23870) * [azure_active_directory] Add grok parsers to extract port from IP:port in ocsf.src_endpoint.ip and network.client.ip Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * [azure_active_directory] Add grok parsers to extract port from IP:port in ocsf.src_endpoint.ip and network.client.ip Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * add facet * Fix test expectations: port values are strings from grok parser Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add integer cast remappers for port fields after grok parsers Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Move ocsf.src_endpoint.port integer cast to post transformations pipeline Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )