Migrate security signatures to detector framework

[yanivagman]

This PR migrates 34 security detection signatures from the legacy signature plugin system to the new detector framework, plus adds test infrastructure improvements.

Note for reviewers: This PR is best reviewed commit-by-commit, as each commit migrates one signature independently.

Changes

Migrated Signatures:

• Anti-debugging & code injection: anti_debugging_ptraceme, ptrace_code_injection, proc_mem_code_injection, process_vm_write_code_injection, dynamic_code_loading, fileless_execution
• System hooking: hooked_syscall, hooked_seq_ops, proc_fops_hooking, syscall_table_hooking
• Persistence mechanisms: core_pattern_modification, default_loader_modification, ld_preload, rcd_modification, scheduled_task_modification, sudoers_modification
• Container escapes: cgroup_notify_on_release_modification, cgroup_release_agent_modification, disk_mount, docker_abuse
• Kubernetes security: k8s_service_account_token, kubernetes_api_connection, kubernetes_certificate_theft_attempt
• System reconnaissance: aslr_inspection, proc_kcore_read, proc_mem_access, sched_debug_recon
• Suspicious activities: dropped_executable, hidden_file_created, illegitimate_shell, stdio_over_socket, system_request_key_config_modification
• Kernel security: kernel_module_loading

Test Infrastructure:

• Added common detector test helpers
• Fixed e2e-kernel-test to work with new detector framework

Impact

• All signatures maintain identical detection logic
• Tests updated to use new detector testing patterns
• Signatures remain registered and functional

---

This is a refactoring migration with no behavioral changes to detection capabilities.

[Copilot]

Pull request overview

This PR migrates 34 security detection signatures from the legacy Go plugin signature system to the new detector framework, representing a significant architectural refactoring. The migration maintains identical detection logic while adopting a more modern, testable architecture with improved type safety and separation of concerns.

Key Changes

• Migrated 34 signatures covering anti-debugging, code injection, persistence mechanisms, container escapes, Kubernetes security, system reconnaissance, and kernel security
• Added detector test infrastructure with mock helpers for logger and data store registry
• Updated e2e kernel test script to handle detector-produced events which use different event name patterns
• Emptied the legacy signature export list as signatures transition to the detector framework

Reviewed changes

Copilot reviewed 132 out of 133 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
tests/e2e-kernel-test.sh	Added detector ID to event name mapping and logic to check for detector-produced events
detectors/test_helpers.go	Created shared test infrastructure with mock logger and data store registry implementations
detectors/*_test.go (multiple files)	Added comprehensive detector tests replacing legacy signature tests
detectors/*.go (multiple files)	Implemented new detector versions of migrated signatures
signatures/golang/export.go	Emptied ExportedSignatures list as signatures migrate to detector framework
signatures/golang/*.go (multiple files)	Removed legacy signature implementations
signatures/golang/*_test.go (multiple files)	Removed legacy signature test files

[Copilot]

This hardcoded mapping between detector IDs and event names creates tight coupling between the test script and detector implementations. Consider generating this mapping dynamically from detector definitions or maintaining it in a shared configuration file that both the detectors and tests can reference. This would reduce maintenance burden when adding new detectors or modifying event names.

[yanivagman]

Valid point. Currently the test only covers 9 of the 34 migrated detectors, and the 1:1 mapping between detector IDs and event names is indeed always needed. As test coverage expands, maintaining a hardcoded map could become tedious. However, generating this dynamically from detector definitions would require either parsing Go code or invoking the compiled binary - both add complexity. A middle-ground might be a JSON config file that's easier to maintain and could be generated by a helper script. Open to suggestions on the best approach which we can implement in a future PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 33.55%. Comparing base (235daa0) to head (16767da).
⚠️ Report is 36 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5146      +/-   ##
==========================================
+ Coverage   33.51%   33.55%   +0.04%     
==========================================
  Files         250      226      -24     
  Lines       28908    28442     -466     
==========================================
- Hits         9688     9544     -144     
+ Misses      18609    18322     -287     
+ Partials      611      576      -35     

Flag	Coverage Δ
unit	33.55% <ø> (+0.04%)	⬆️
see 25 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.