Detection Dependencies and Content Packaging
Model shared telemetry, mappings, components, filters, converters, schemas, deployment targets, and delivery routes as a versioned dependency graph that can be tested and packaged with detection content.
Dependencies include evidence and execution
A rule imports a shared selection, expects a field alias, uses a local filter, requires correlation state, depends on an identity enrichment, is converted for one backend, and routes results to a case queue. Deploying only the rule text cannot reproduce the service.
Represent dependencies by stable identity, version constraint, type, owner, and reason. Include telemetry contracts, schemas, parsers, normalized fields, enrichments, shared logic, filters, converters, target capabilities, schedules, credentials, routing, tests, and response integrations.
Distinguish required from optional dependencies. An optional enrichment may lower confidence when absent. A required actor field may invalidate the analytic. This difference should drive health and deployment gates.
Version constraints preserve tested combinations
A floating reference to latest can update a shared component without retesting consumers. Pinning everything forever prevents security fixes and creates fragmented copies. Use explicit compatibility ranges and lock the resolved deployment artifact.
Record source revision, dependency identities and resolved versions, converter and backend version, build inputs, tests, and artifact digest. The repository can express compatible intent; the lock or manifest records what actually shipped.
When a dependency changes, calculate reverse impact. A parser update may affect hundreds of rules. A filter change may alter only one environment. The graph turns hidden shared risk into reviewable blast radius.
Package intent, implementation, and assurance together
A deployable bundle should contain or reference the rule and correlation content, metadata, local overlays, schemas, mappings, target configuration, dependencies, expected runtime policy, tests, representative fixtures, and integrity information.
Keep sensitive credentials outside the package while recording the identity and access contract they must satisfy. Test data should be synthetic or protected appropriately and should not leak production secrets.
The package is not necessarily one archive. It is a reproducible manifest that lets another system resolve the same artifact and prove which inputs produced it. This supports rollback, audit, and historical alert interpretation.
Test graph failures, not only happy-path resolution
Validate missing, incompatible, stale, cyclic, and unexpectedly upgraded dependencies. Confirm that build and deployment fail visibly when required components cannot be resolved. Optional dependencies should produce an explicit degraded state.
Test source-rule and shared-component changes against every affected consumer. One component’s fixture may pass while a downstream rule interprets its output differently. Preserve expected behavior at both component and end-to-end levels.
Use canary deployment and rollback with the resolved bundle. Rollback needs the previous artifact and compatible dependencies, not merely the previous rule commit.
Observe runtime drift from the packaged graph
A platform administrator can edit a rule, disable a schedule, change a lookup, or detach a filter after deployment. Compare repository intent, built artifact, deployed configuration, and runtime execution.
Record deployment identity, target, artifact digest, effective overlays, enablement, schedule, last execution, and delivery health. Drift can be authorized emergency change or unauthorized modification; detection should report the fact and governance context before assigning intent.
Retirement follows the graph too. Remove orphaned filters, unused components, credentials, schedules, and routes only after confirming no other content depends on them. A clean dependency record prevents abandoned infrastructure from remaining an invisible part of the security service.
Historical manifests remain valuable after removal because old alerts, incident timelines, and audit questions still need the dependency versions that shaped their results. Preserve them as immutable release evidence.
Frequently asked questions
Why package dependencies with detection content?
Because the same rule can behave differently or fail when a field map, shared selection, filter, converter, backend feature, schedule, or routing policy changes. Packaging records the tested combination.
