[Threat Intel 1/11] Gate enrichment completion on extract_iocs, drop detection_actionability

[stephmilovic]

Two corrections to threat-intel work that already merged, ahead of the supply pipeline that consumes it.

extract_iocs runs with on-failure: continue, but the completion gate only probed classify_severity.error and enrich_taxonomy.error. So a transient IOC-route failure still wrote extraction_method: workflow_v2, which is what load_pending_reports filters on, and the report was never looked at again. It stays permanently enriched with no IOCs, and since the promote task only scans reports that have extracted.iocs, it contributes nothing to the indicator index ever. A rolling restart, a request timeout, or a body over the 5MB route bound gets you there.

extract_iocs belongs in the probe set because it is the step whose output the rest of the pipeline actually consumes. Moving the gate from payload-presence to step health was right, it just left out the step that matters most downstream.

Also removed detection_actionability from taxonomy enrichment. It scored how useful a report is for writing a detection rule, which is Detection Watch's call (Dark Watch D20), and nothing downstream consumed it. The completeness gate was its only reader, and it was using field presence as a stand-in for step health, which does not work here because every taxonomy field has a legitimate falsy value: relevance 0.0, diamond_suitable false, empty category and region arrays.

The generator fixtures come along because they carried the same field, plus the reports index rename from the earlier data-stream design.

No workflow version bump: these workflows are not installed anywhere yet.

Needs @elastic/workflows-eng since it touches enrich_threat_report.yaml. It is the only PR in the series that does.

Where this sits

#	PR	Depends on	Status
1	#287197 workflow gate correction + fixtures ← this PR	nothing	✅ merged
2	#287198 contracts, constants, shared libs	nothing	✅ merged
3	#287199 content parsing	#287198	closed
4	#287200 SSRF-guarded HTTP client	#287198	✅ merged
5	#287201 index templates, seeding, inference features	#287198, #287200	✅ merged
6	#287202 indicator alias	#287198, #287201	✅ merged
7	#287203 IOC extraction	#287198, #287200	✅ merged
8	#287204 LLM services, routes, source catalog API	#287198, #287200, #287202, #287203	✅ merged
9	#287205 RSS adapter	#287198, #287200, #287203, #287204	✅ merged
10	#287206 remaining adapters, dispatcher, fetch_source step	#287198, #287200, #287203, #287205	✅ merged
11	#287207 promote/scrub tasks and plugin wiring	#287198–#287206	✅ merged
12	#287479 generator fixture article URLs	nothing	✅ merged

#287479 came first in the merge train and is already on main. The numbered series (#287197–#287207) stacks on top in dependency order. #287199 (content parsing) was closed; IOC extraction ships its own section-header classifier.

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-solution (Team: SecuritySolution)

[stephmilovic]

@elasticmachine merge upstream

[kibanamachine]

Libra found 1 issue.

Generated by Libra

[kibanamachine]

The regression-critical failure gate is changed without an automated workflow test that exercises it. The only test changes in this PR remove fixture assertions, so there is no coverage proving that an extract_iocs step failure leaves extraction_method as pending (or that all-success marks workflow_v2); a future expression or workflow-engine change could silently reintroduce the permanently skipped-report failure this PR is fixing.

Add a workflow execution test covering at least the all-success case and each continued step-error case, asserting the persisted lineage.extraction_method.

[stephmilovic]

Added coverage in enrich_threat_report.test.ts.

One honest caveat on what it is: this package has no workflow-execution harness, so it is not an execution test. It follows the alert_analysis_workflow.test.ts precedent and parses the shipped yaml. So it cannot prove how the engine evaluates the expression at run time.

What it does pin is the structure the fix depends on, which is where the bug actually lived:

• all three continued steps are probed in the complete gate (steps.<step>.error == null)
• all three are probed in the incomplete gate (!= null)
• the two gates stay complementary, so updating one and not the other fails
• all three steps still carry on-failure: continue, without which a failure aborts before either gate is reached and the whole change is unreachable
• detection_actionability is gone

I checked it bites rather than assuming: reverting the gate to the previous two-step form fails 2 of the 13 tests (requires extract_iocs to have succeeded before marking complete and keeps the two gates complementary).

Runtime evaluation of the gate is genuinely untested, and I would rather say so than imply otherwise. It needs a workflow-execution harness, which does not exist in kbn-workflows today and is more than this two-file PR should carry. Tracking it for the follow-up read PR, which already owns install and space-isolation testing.

[jonwalstedt]

Looks good except for the missing test coverage for the extract_iocs step failure that Libra already commented on, add the missing coverage and it is good to go.,

[stephmilovic]

Thanks @jonwalstedt. Coverage added in enrich_threat_report.test.ts, details in the thread above.

Short version: it is a yaml-structure test, not an execution test, because this package has no workflow-execution harness. It pins that all three continued steps are probed by both gates and that they still use on-failure: continue, and I verified it fails if the gate is reverted. Runtime evaluation of the expression is still untested and I called that out explicitly rather than let the coverage look stronger than it is.

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: e9747ae
• Build duration: 66 mins

Failed CI Steps

• FTR Configs #116

Metrics [docs]

✅ unchanged

Test Failures

• [job] [logs] FTR Configs #116 / Reporting Functional Tests with Security enabled Access to Management > Reporting non privilege user does not allow user that does not have reporting privileges
• [job] [logs] FTR Configs #116 / Reporting Functional Tests with Security enabled Access to Management > Reporting non privilege user does not allow user to access schedules that does not have reporting privileges

History

• 💛 Build #491539 was flaky e7e9d81
• 💔 Build #491527 failed eba9a38