autoresearch: global threshold search#24
Conversation
Deploying secopsai with
|
| Latest commit: |
43b0925
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://873d6bfa.secopsai.pages.dev |
| Branch Preview URL: | https://autoresearch-global-20260407.secopsai.pages.dev |
Deploying website with
|
| Latest commit: |
43b0925
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4edc9c92.website-bks.pages.dev |
| Branch Preview URL: | https://autoresearch-global-20260407.website-bks.pages.dev |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f0b52d3af
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| T1059 / T1105 — Detect installer-time shells that fetch a payload and detach it. | ||
| """ | ||
| detached_patterns = re.compile( | ||
| r"(?i)(nohup\s+.+\s+&\b|/bin/\w+\s+-c\s+.*\s+&\b|start\s+/min\s+powershell|powershell.*-enc\b|" |
There was a problem hiding this comment.
Fix detached-shell regex to match trailing background '&'
The detached_patterns expression makes the nohup ... & and /bin/* -c ... & branches effectively non-matching because they end with &\b; in shell command lines the & is normally followed by whitespace or end-of-string, so this boundary condition fails and those branches never fire. That causes detect_detached_payload_execution to miss the exact detached execution patterns it was introduced to catch (for example nohup curl https://... && /tmp/payload &) unless another alternation happens to match.
Useful? React with 👍 / 👎.
| source = raw_source if raw_source in {"openclaw", "macos", "linux", "windows", "correlated"} else platform | ||
| if source not in {"openclaw", "macos", "linux", "windows", "correlated"}: | ||
| source = "openclaw" |
There was a problem hiding this comment.
Preserve original finding source during normalization
This normalization now collapses any non-enum source to openclaw via platform, which drops provenance for valid producers like the threat-intel pipeline (source="secopsai-intel" in secopsai/intel.py). After sync, those findings are mislabeled as OpenClaw/application findings, which breaks source-based filtering and triage semantics in downstream dashboards.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 43b09250c3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| continue | ||
| if process not in child_fetchers: | ||
| continue | ||
| if (url_hint.search(combined) and fetch_hint.search(combined)) or install_hint.search(combined): |
There was a problem hiding this comment.
Require network-fetch evidence before tagging install chains
The new detect_node_installer_remote_fetch rule marks an event as malicious whenever install_hint matches, even if no downloader/URL evidence is present. In common npm/bun workflows, child shells often execute local node_modules scripts (sh -c node_modules/...) under npm/node, so this branch will generate high-volume false positives and dilute rule usefulness. The rule summary says this should detect remote fetch during install, so this condition should stay gated on explicit fetch/URL signals.
Useful? React with 👍 / 👎.
| if not risk_tags: | ||
| risk_tags = list(metadata.keys()) if metadata else [] |
There was a problem hiding this comment.
Preserve risk tags instead of synthesizing metadata field names
When incoming findings do not include risk_tags, normalization now substitutes metadata key names (for example source_name, detector, fingerprint) as tags. This changes the semantic meaning of risk_tags from threat indicators to internal bookkeeping fields, which will mislead dashboards/filters and any downstream logic expecting behavioral tags. For sources that omit risk_tags (including many detector-produced findings), this produces systematically incorrect tag data.
Useful? React with 👍 / 👎.
Automated local autoresearch run.
Baseline F1: 0.864995 (FP=447, FPR=0.3921)
Best score: 0.874385 | F1: 0.875039 (FP=373, FPR=0.3272)
Report: /Users/chrixchange/.openclaw/workspace/secopsai/results/autoresearch-20260407-220010.json
Reproduce: