02 CTI Baseline Reuse and Ownership.en - jiale-li-orion/SecFusionAgent GitHub Wiki

CTI Baseline, Reuse and Ownership

English | 中文

This document records the CTI (Cyber Threat Intelligence, network threat intelligence) reuse baseline, traditional analyst workflow, rule system and capability ownership that SecFusionAgent fixes before entering Technical Design. It continues the data processing contracts of 01-Data-Sources-and-Processing and does not redefine the source registry, evidence, object/relation and retrieval index; database products, deployment topology and specific framework selection are left to Technical Design.

The goal is to adopt mature CTI standards, platforms and rule capabilities first, then place LLM/Agent at the steps of the traditional flow that still depend on human semantic judgement. The implementation value of SecFusionAgent comes from data organization, semantic processing, investigation and evidence use in the AI Security setting, and does not come from rewriting existing CTI infrastructure.

Existing CTI workflow

Mature CTI platforms already provide structured feed, file import, IOC extraction, object normalization, relevance computation and intelligence sharing as general capabilities. Human work concentrates on new source onboarding, unstructured content understanding, fuzzy entity alignment, relation confirmation, conflict handling and investigation judgement.

OpenCTI automated import supports continuous input such as connector, stream, TAXII, RSS and CSV; file import covers STIX, MISP, YARA, PDF, text, HTML and Markdown, and a parsed document can enter draft/workbench first, where an analyst checks entities and relations before they enter the formal knowledge base. MISP provides free-text, URL, CSV, STIX, email, attachment and feed import, and uses parser/module to extract observables. TheHive stores observables, tasks and investigation context in a case, and an analyst can call a Cortex analyzer for enrichment, then choose which results enter the case.

The traditional workflow therefore reduces to the following responsibilities:

Stage Existing automation capability Main analyst work
source onboarding connector, feed, TAXII, RSS, API find new sources, configure access, mapping, credibility and cadence
collection API/Git/RSS/file import handle anomalous sources, reports, email, URLs and missing fields
explicit extraction regex, freetext parser, CSV/JSON mapper verify context, remove false extraction, add semantic fields
normalization schema mapper, deterministic ID, taxonomy handle alias, product/version, objects with the same name and fuzzy identity
correlation IOC exact/fuzzy/CIDR, graph rule judge whether a relation carries business semantics, handle wrong association
enrichment external analyzer, connector, lookup choose enrichment, interpret results, handle source conflicts
TTP / attack-chain mapping ATT&CK/knowledge base, partial NLP identify implicit behavior, conditions and causality from natural language
curation warninglist, score, filter judge source quality, confidence, and the scope of publication and sharing
investigation playbook, analyzer, case workflow decide the next investigation action, organize evidence into a conclusion

SecFusionAgent automation targets the work on the right that still depends on semantic understanding, and does not replace the deterministic capability on the left that is already stable.

Standards and platform reuse

STIX / TAXII

STIX 2.1 is the general exchange model for threat intelligence objects and relationships, and TAXII 2.1 handles collection and intelligence exchange. Mature implementations such as python-stix2 and taxii2-client exist, and SecFusionAgent is directly compatible with these standards, maintaining an explicit mapping between internal objects and STIX objects.

STIX Patterning expresses the match conditions of an indicator against an observable. Detection semantics expressible by an existing STIX pattern continue to use the standard syntax, and no project-specific indicator DSL is created.

OpenCTI

OpenCTI provides a STIX knowledge graph, connector framework, file import, deduplication, inference, enrichment, workbench and external integration, and remains a reference implementation for CTI interoperability, connectors and analyst workflow. SecFusionAgent has selected its own lightweight Data Plane rather than OpenCTI as the internal source of truth; public connectors/workflow capabilities remain reusable where useful.

OpenCTI connectors already cover sources such as CVE and MISP. The public design of the cvelistV5 connector clones the CVE repo on first run, then synchronizes increments from Git changes, and maps CVE records to STIX Vulnerability, Software, Identity and related Note. Such capabilities enter the reuse candidates directly, and SecFusionAgent does not reimplement an equivalent crawler.

OpenCTI deterministic ID, deduplication and inference rule likewise serve as baseline. Technical Design decides whether OpenCTI CE carries the CTI kernel directly or an owned data layer reproduces its standard semantics while reusing connectors; a probe decides this choice.

MISP

MISP provides IOC/event, feed, freetext parser, correlation, warninglist, taxonomy, galaxy and sharing. General capabilities such as IOC exact match, CIDR, fuzzy hash and common false-positive filtering adopt its mature semantics or an external service directly.

MISP core uses AGPL-3.0. Technical Design checks the license boundary when reusing code; protocol, format, taxonomy, warninglist, feed and an external MISP instance can serve as interoperability targets. SecFusionAgent does not rewrite a general IOC correlation engine.

Detection rule ecosystem

Existing rule formats continue to be reused by detection target: STIX Pattern targets indicator/observable; Sigma targets log events; YARA targets file, text and binary pattern; Suricata/Snort targets network traffic. When detection rules need to be produced or consumed, the system emits an existing format and uses existing parser, validator and ruleset.

These rules are the public interface of the detection ecosystem. SecFusionAgent can generate, correlate or explain rules from intelligence, and does not own the rule language itself.

Rule baseline

Traditional rule matching has several layers, and Technical Design reuses the corresponding implementation per layer.

Rule layer Typical mechanism Ownership
input parsing regex, freetext parser, CSV/JSON mapper OpenCTI/MISP/off-the-shelf parser; the project adds AI-specific mapper
normalization deterministic ID, field standardization, schema mapping STIX/OpenCTI/MISP semantics
deduplication canonical ID, object key, exact match platform rules first, fuzzy identity goes to the semantic layer
IOC correlation exact, CIDR, fuzzy hash mature capabilities such as MISP/OpenCTI
false-positive filtering warninglist, allow/block list reuse public warninglist and project configuration
graph inference fixed relation rule, transitive/derived relation OpenCTI inference baseline; AI-specific relation is defined separately
detection STIX Pattern, Sigma, YARA, Suricata/Snort respective standards and off-the-shelf ruleset
workflow routing filter, watch, playbook condition platform capability or deterministic orchestration in Technical Design

Rules suit problems with determinate syntax, identity and logic. LLM does not take on work that stable rules already cover, such as IP/hash recognition, deterministic ID generation, version comparison and known schema mapping.

Enrichment rule baseline

Traditional intelligence enrichment can be decomposed into operators with explicit input, decision semantics and output contracts. They form the deterministic M3 baseline and the comparison point for later Agent/semantic enrichment.

Operator Input Deterministic semantics Output
ExactIdentifierJoin CVE/GHSA/OSV/CNVD/CNNVD/DOI/SHA namespace normalization + exact match alias / same-object / source record
SchemaProjection structured provider record fixed field/JSONPath mapping CVSS, CWE, reference and time claims
VersionRangeEvaluate product/package + version + source range source-specific comparator affected / not_affected / fixed / unknown
ProductStatusResolve vulnerability + product branch CSAF/VEX status + justification affected / not_affected / fixed / under_investigation
CPE/PURLMatch asset/package identity CPE configuration, PURL/ecosystem/package identity product/package/version relation
GraphClosure issue/PR/commit/release/repo exact edge + ancestry/containment fix/release relation
ExternalExactLookup canonical ID provider exact query KEV, EPSS, advisory metadata
ObservationJoin time-bounded asset observation fingerprint/CPE/PURL/version + applicability evaluator candidate affected asset
EvidenceBind mapped fact/relation locator resolves to a fixed source revision EvidenceRef
ConflictPreserve same predicate/relation from several sources source authority/time/independence comparison parallel assertions + conflict

Version applicability follows the semantics of the evidence source. CVE Record Format 5.x uses versionType, interval bounds, changes and defaultStatus; OSV uses SEMVER / ECOSYSTEM / GIT ranges with introduced / fixed / last_affected / limit; NVD applicability preserves the CPE configuration tree and version bounds; CSAF/VEX contributes explicit affected/not-affected/fixed/under-investigation product status. GIT ranges require repository ancestry rather than string comparison. A missing match or incomparable version remains unknown.

Severity and exploitation signals remain separate. CVSS Base/Threat/Environmental describe different dimensions; CISA KEV means observed exploitation in the wild; public PoC availability is a different fact; EPSS is a time-varying probability of observed exploitation. None substitutes for another or becomes an aggregate risk score without an explicit higher-level policy.

The deterministic baseline emits only registered canonical terms or provider-native source-specific fields. Semantic processing may discover a new evidence-backed relation, but an unregistered term remains exploratory and is excluded from the versioned enrichment P/R denominator until vocabulary review promotes it.

LLM / Agent automation boundary

LLM enters the semantic gaps in the existing analyst workflow. The first batch of candidate capabilities includes the following:

Analyst work LLM/Agent goal Result constraint
unstructured report reading extract product, version, vulnerability conditions, impact, patch/workaround and TTP fields cite the original evidence span
fuzzy entity resolution align repo/product/package/version/alias deterministic ID first; a fuzzy match stores candidates and the basis
relationship discovery discover issue, function, PR, commit, release, dependency and downstream relations the relation links back to the source object/evidence
taxonomy mapping map to ATT&CK/CWE/CAPEC/AI-specific taxonomy match the existing system first, a new category needs an explicit definition
source conflict analysis find conflicts in affected version, severity, fix status and similar fields keep each source observation, output the conflict and its basis
investigation planning determine the evidence currently missing, choose the next source or tool tool permission and execution count are bounded by deterministic policy
evidence synthesis organize attack chain, impact scope, fix status and unknown the conclusion cites a specific evidence revision

Results that are highly uncertain, high-impact, or carry a source conflict that cannot be resolved automatically enter the analyst exception path. Human review narrows from the regular data path to exceptions and high-value judgement; the review result enters the system as evidence/decision, and does not become a temporary modification detached from the data model.

Method baseline

The SecFusionAgent method inherits the traditional CTI baseline first, then improves the analyst-heavy semantic steps. Internal evaluation can describe the capability boundary at the following three levels:

Level Composition Use
Rule / Platform baseline connector/feed + STIX/MISP schema + parser/mapper + deterministic dedup/correlation/inference baseline of existing engineering capability
Analyst workflow baseline + manual entity alignment, relation linking, TTP mapping, conflict review, investigation reference for the existing manual process
SecFusionAgent baseline + LLM semantic processing + Agent investigation + exception routing product method

This layering serves to understand ownership and evaluation design, and does not require leaderboard-style competition with OpenCTI/MISP. Competition evaluation still centers on the source coverage, monitoring latency, enrichment precision/recall, QA quality, automation and engineering completeness the problem statement (赛题) requires; internally the project can additionally record analyst review count, exception rate, evidence correctness and investigation increment, to verify whether automation genuinely reduces manual work.

Handling relations of the four risk categories

The four risk categories share the evidence, object, relation and retrieval kernel fixed in 01, and each has its own main objects and relation graph. The classification describes which kind of object or lifecycle position a risk occurs at; the underlying data capability connects sources, objects, versions and evidence. One intelligence item can enter several graphs at the same time, and ownership follows the fact it expresses.

Risk category Main anchor Main relations Typical sources and handling
AI infrastructure / inference frameworks repo, component, release, runtime issue, PR, commit, affected/fixed version, integration mainly GitHub/GHSA/CVE/PSIRT, tracking implementation and fix along the repo graph
Models and data layer model, dataset, checkpoint, training/inference behavior derived-from, trained-on, poisoned-by, evaluated-by, leaks mainly papers, blogs, model/data hub and vendor reports, relying on semantic extraction and evidence linking
AI applications and agents app, Agent, tool, MCP/skill, memory/state, permission invokes, can-access, writes-state, delegates, trusts repo/advisory and research material together, organized around execution permission, state and tool relations
Supply chain package, artifact, image, dependency, build, distribution channel depends-on, contains, built-from, published-as, distributed-as, deployed-with deterministic data such as CVE/OSV/GHSA, SBOM, lockfile, registry and container scan first

The first three categories proceed along the existing data processing approach. AI Infra relies on the repo graph; the models and data layer relies on the document/model/dataset graph; AI applications and agents rely on the app/tool/state/permission graph. All three continue to reuse the general Source Definition, Managed Content, semantic extraction and Knowledge/structured relation graph.

Supply chain adds one explicit class of propagation judgement: an upstream vulnerability maps to the affected package/version first, then dependency, artifact, image and deployment relations determine which downstream objects actually contain that version. CVE, OSV, GHSA, SBOM, lockfile, package registry and container scanner already answer many determinate questions, including affected version, direct/transitive dependency, artifact contents and fixed version. These capabilities enter the baseline, and graph traversal performs impact propagation.

Supply-chain relations adopt mature semantics and add the object relations the project needs: depends-on means dependency, contains means a release/artifact actually contains a component, built-from means artifact origin, published-as and distributed-as mean delivery form, and deployed-with means deployment combination. Vulnerability applicability to product/package/version uses the M3 canonical applicability-status; fix boundaries use fixed-version / fixed-by. Supply-chain propagation is asserted only when a verifiable version/artifact propagation edge exists, avoiding a second supply-chain-specific vulnerability applicability/fix vocabulary.

LLM/Agent handles the edge cases that deterministic supply chain tooling does not cover: a declared dependency that disagrees with the real build artifact, whether an optional backend enters a specific release, a component introduced by vendoring or copy-paste, an upstream fix that downstream does not upgrade to, a vulnerability that holds only under a specific configuration or an enabled connector, and a cross-repo integration that lacks a stable machine-readable relation. LLM outputs candidate relations and the basis, and final relations continue to follow evidence linking and exception routing.

The four graphs can intersect, and fact ownership stays stable. A parser vulnerability in vLLM itself belongs to AI infrastructure; when that vulnerability propagates to other products through a wheel, container or downstream dependency, the propagation fact belongs to supply chain. When a malicious checkpoint triggers loader RCE, the security property of the model artifact belongs to the models and data layer, the software defect of the loader can also relate to AI Infra, and supply chain still holds the propagation chain of the artifact from the hub to the deployment environment. This lets the same evidence and relation be reused, without flattening the four risk categories into one taxonomy.

SecFusionAgent Ownership

SecFusionAgent owns the AI Security specialization. General CTI foundation capabilities are reused first, and project code and the data model carry the following responsibilities:

Area SecFusionAgent ownership
source selection AI Security source registry, target repo/platform, research source and update strategy
AI-specific object model AI Infra, model/data, Agent and supply chain objects and their relation extensions
semantic extraction field and mechanism extraction from unstructured material such as blogs, papers, PSIRT and issue
semantic entity resolution fuzzy cross-source alignment of repo/product/package/model/version
evidence linking claim, fact, relation and conclusion linking back to a specific observation/revision
AI-specific relation discovery relations such as repo graph, model/artifact, Agent tool/permission and supply chain propagation
conflict / unknown management explicit state for source conflict, evidence gap and unknown
investigation choose source/tool from the missing evidence, write back reusable fact and relation
QA / explanation generate a citable answer from evidence and relation, separating fact, inference and unknown
benchmark AI Security sample, human adjudication basis, regression and adversarial case

The following capabilities belong to mature standards and the ecosystem: STIX/TAXII exchange, general CVE/NVD ingestion, general IOC parser/correlation, deterministic dedup, public taxonomy/ATT&CK, and Sigma/YARA/Suricata rule syntax and validator. For each capability, Technical Design checks for a reusable implementation first, and records the integration approach when a mature implementation exists; in-house development states the specific contract that existing implementations lack.

Reuse decision

Technical Design has closed the former “OpenCTI kernel or owned lightweight data layer” candidate state. SecFusionAgent now uses its own lightweight Data Plane: packages/sources owns provider/source contracts, packages/monitoring owns the acquisition lifecycle, packages/intelligence owns durable Evidence/Knowledge/Incident/Document state, and packages/enrichment owns AI Security enrichment. PostgreSQL/Redis/S3-compatible object storage and outbox/Celery provide the runtime substrate.

STIX/TAXII, OpenCTI, MISP and TheHive/Cortex remain reuse sources for interoperability, connectors/workflow and analyst baselines rather than SecFusionAgent's internal source of truth or runtime kernel. CTI exchange should use mature standards where possible; connector/parser capability should be reused or adapted where practical; internal object/evidence versioning, AI-specific relations, benchmark isolation and Agent runtime contracts remain owned by SecFusionAgent.

The reuse-first policy remains unchanged: locate standards, mature platforms and existing rules before implementing the AI Security semantics and automation contracts the ecosystem does not provide. Local connector/parser integration is maintained in module README files; this section reopens only when interoperability boundaries or internal ownership changes.

Reference implementations and documents