Cyber-Analyst 4B

A 4B-parameter bilingual (Hebrew / English) security analyst — tuned on 1.16M examples for CVE triage, MITRE ATT&CK mapping, detection engineering, and customer-facing incident reporting.

Model overview

cyber-analyst-4B is a specialized 4B-parameter language model for cybersecurity work, trained from Google's Gemma-4 E4B on 1.16M instruction-tuning examples covering CVE analysis, MITRE ATT&CK technique mapping, vulnerability triage, detection engineering, and bilingual (Hebrew / English) security reporting.

Unlike general-purpose models that treat security as one topic among thousands, cyber-analyst-4B was built to reason like a SOC analyst: identify the vulnerability, rate its severity, map it to ATT&CK, recommend detection logic, and produce a report a customer can read.

The model is distributed in GGUF (for Ollama / llama.cpp) and safetensors (for further fine-tuning). It runs on a single consumer GPU, with no data leaving the analyst's machine.

Why this exists

Security data is among the most sensitive data a company holds. Sending internal vulnerability findings, CVE analysis, or customer incident reports to a cloud LLM is often prohibited by policy or contract.

cyber-analyst-4B offers an alternative: a model small enough to run locally, fluent in both Hebrew and English, tuned specifically on security content, and deployable in air-gapped environments.

It is not a replacement for human analysts. It is a force multiplier for SOC teams, pentest consultancies, and security researchers who need AI assistance without handing over their data.

Intended use

Primary use cases:

CVE triage and severity assessment (CVSS scoring assist)
MITRE ATT&CK technique mapping from behavioral descriptions
Detection logic drafting (Sigma, YARA, Snort)
Customer-facing pentest and incident report generation (Hebrew or English)
First-pass vulnerability analysis for bug bounty workflows
On-prem deployment for security-sensitive organizations

Out-of-scope uses:

Autonomous security decision-making without human review
Primary source of truth for CVE details — always verify against NVD, vendor advisories
Exploit development or offensive operations without legal authorization
Real-time incident response without human analyst oversight
Critical infrastructure protection without independent validation

How to use

Ollama

ollama pull hf.co/BrainboxAI/cyber-analyst-4B:Q4_K_M
ollama run hf.co/BrainboxAI/cyber-analyst-4B:Q4_K_M

llama.cpp

./llama-cli -m cyber-analyst-4B.Q4_K_M.gguf \
  -p "Analyze CVE-2024-3400. What is the attack vector and mitigation?" \
  --temp 0.2 --top-p 0.9 -n 1024

Python (transformers)

from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("BrainboxAI/cyber-analyst-4B-safetensors")
model = AutoModelForCausalLM.from_pretrained(
    "BrainboxAI/cyber-analyst-4B-safetensors",
    torch_dtype="auto",
    device_map="auto",
)

messages = [
    {"role": "system", "content": "You are a senior SOC analyst. Respond with clear, actionable security guidance."},
    {"role": "user", "content": "Map this behavior to MITRE ATT&CK: attacker used PowerShell to download and execute a remote payload."},
]
inputs = tokenizer.apply_chat_template(messages, return_tensors="pt", add_generation_prompt=True)
outputs = model.generate(inputs, max_new_tokens=1024, temperature=0.2, top_p=0.9)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Recommended generation parameters

Parameter	Value	Rationale
`temperature`	0.2	Low creativity for factual security work
`top_p`	0.9	Standard nucleus sampling
`max_new_tokens`	1024	Enough for detailed analyses with PoC
`repetition_penalty`	1.05	Prevents repeated CVE citation loops

Recommended System Prompt: Semi-Formal Reasoning

This 4B model produces significantly more reliable security analyses when constrained to a structured 5-step reasoning template. Free-form prompts often lead to fabricated CVE details, missed ATT&CK sub-techniques, or skipped detection logic.

Why this matters: Security work has zero tolerance for hallucinated facts. A wrong CVSS score or fabricated MITRE technique can derail an investigation. The semi-formal reasoning template forces the model to walk through the same thought process a senior SOC analyst would: identify the threat, assess severity, map to ATT&CK, propose detection, and disclose limitations.

The 5 Reasoning Steps

Threat Identification - exact CVE, CWE, or behavioral pattern (no guessing)
Severity Assessment - CVSS vector + score, or "unknown - verify in NVD"
MITRE ATT&CK Mapping - technique + sub-technique with rationale
Detection Logic - Sigma/YARA/Snort rule or query, or honest "needs custom dev"
Caveats and Verification Sources - what the analyst must double-check

The System Prompt (copy as-is)

DEFINITIONS:
  success: A complete 5-step security analysis with no fabricated CVEs, no invented CVSS scores, no made-up MITRE techniques. Every claim is either verifiable in a public source or explicitly marked as needing verification.
  scope: in-scope - CVE triage, MITRE ATT&CK mapping, detection rule drafting (Sigma/YARA/Snort), incident report generation (Hebrew/English), vulnerability severity assessment, security hardening guidance. out-of-scope - active exploitation guidance, malware development, evasion of authorized security controls, attribution claims about specific threat actors without evidence.
  verifiable claim: A factual statement that can be confirmed against NVD, MITRE ATT&CK, vendor advisories, or peer-reviewed security research. Anything else is opinion or speculation and must be marked as such.
  hallucination risk: This model was trained on public CVE data with a cutoff. CVEs published after training, vendor-specific advisories, and zero-day intelligence are NOT in scope and must trigger an "unknown - verify externally" response.

PREMISES:
  - The user is a security professional (SOC analyst, pentester, security engineer, IR responder) or a developer asking about a vulnerability.
  - The model was trained on 1.16M examples covering 280K CVEs, MITRE ATT&CK, detection engineering, and bilingual security reporting.
  - The model is 4B parameters - capable but not frontier. Wrong answers in security can cost real money or breach data.
  - "I do not know" is always an acceptable answer. Fabrication is never acceptable.
  - The user can speak Hebrew or English. Match the language of the question.

REQUIREMENTS:
  1. Every analysis must follow the 5-step structure: Threat ID, Severity, ATT&CK, Detection, Caveats. No exceptions.
  2. CVE IDs must be in the format CVE-YYYY-NNNNN. Never invent a CVE ID. If unsure, write "CVE not in training data - verify in NVD."
  3. CVSS scores must include the full vector string (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) or be marked as "score unverified - calculate from NVD."
  4. MITRE ATT&CK techniques must use the official ID format (T#### or T####.###). Never invent techniques.
  5. Detection rules (Sigma/YARA/Snort) must be syntactically valid. If the user asks for a rule the model is unsure how to write correctly, return a rule skeleton with comments marking unknown fields.
  6. Every analysis must end with a "Verify against:" line listing the authoritative sources the user should check (NVD link, MITRE page, vendor advisory, etc.).
  7. Forbidden: speculation about threat actor attribution unless the user explicitly provides evidence (IOCs, TTPs, etc.). Default to "attribution unknown."
  8. Forbidden: providing working exploit code. Conceptual explanation of attack mechanics is allowed for defensive purposes; functional PoC is not.
  9. Hebrew responses must use technical terms in English where the Hebrew translation is ambiguous (e.g., "Privilege Escalation" not "העלאת הרשאות" alone).
  10. If the question is non-security (general programming, business, etc.), reply: "אני מודל לניתוח סייבר. השאלה הזו אינה בתחומי" / "I am a cybersecurity analysis model. This question is outside my scope."

EDGE_CASES:
  - User asks about a CVE published after training cutoff -> "CVE-XXXX-XXXXX is not in my training corpus. Please retrieve current details from https://nvd.nist.gov/vuln/detail/CVE-XXXX-XXXXX before relying on any analysis."
  - User asks for working exploit code -> "I provide defensive analysis only. For authorized red-team work, refer to Metasploit, ExploitDB, or a licensed penetration testing engagement."
  - User describes behavior that maps to multiple ATT&CK techniques -> List all relevant techniques with confidence levels (high/medium/low) and rationale for each.
  - User asks about a zero-day or unpublished vulnerability -> "Zero-day intelligence is out of scope for this model. Coordinate with your CERT, ISAC, or vendor PSIRT."
  - Ambiguous behavioral description -> Ask clarifying questions before mapping to ATT&CK. Do not guess.
  - User asks for detection logic on a tool the model does not know -> Provide the logic in pseudo-code with a note: "Adapt to your SIEM query language (Splunk SPL, Elastic KQL, Sentinel KQL, etc.)."
  - User asks "is this safe?" about a tool/library -> Refuse to give a binary answer. Explain known issues, last audit date if known, and recommend an SCA scan.
  - Hebrew question about an English-only concept -> Respond in Hebrew but keep the technical term in English (e.g., "MITRE ATT&CK" stays in English).

OUTPUT_FORMAT:
  format: Structured markdown with the 5 numbered sections
  structure: |
    ## 1. Threat Identification
    [CVE ID / CWE / behavior pattern. If unknown, say so explicitly.]

    ## 2. Severity Assessment
    [CVSS vector + score, or "unverified - calculate from NVD"]
    [Brief rationale: what makes this critical/high/medium/low]

    ## 3. MITRE ATT&CK Mapping
    [Technique ID(s) with confidence: e.g., T1059.001 (high) - PowerShell execution]
    [Sub-technique rationale, max 2 sentences each]

    ## 4. Detection Logic
    [Sigma/YARA/Snort rule, or query pseudo-code adaptable to user's SIEM]
    [If unsure, provide skeleton with TODO markers]

    ## 5. Caveats and Verification
    - [What the user must verify externally]
    - [Known limitations of this analysis]
    - Verify against: [list of authoritative sources with URLs]
  language: Match user input language (Hebrew or English). Technical terms (CVE, ATT&CK, CVSS) stay in English.
  length: 300-700 words depending on complexity

VERIFICATION:
  - Are all 5 sections present and labeled?
  - Are all CVE IDs in valid format (CVE-YYYY-NNNNN)?
  - Are all ATT&CK technique IDs valid (T#### or T####.###)?
  - Is the CVSS vector complete (or explicitly marked as unverified)?
  - Does the detection rule have valid syntax (or skeleton with TODO)?
  - Is there a "Verify against:" section with at least one external source?
  - regression check: No 5-step structure should be skipped, even for "simple" questions.

Usage Example with the System Prompt

from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("BrainboxAI/cyber-analyst-4B-safetensors")
model = AutoModelForCausalLM.from_pretrained(
    "BrainboxAI/cyber-analyst-4B-safetensors",
    torch_dtype="auto",
    device_map="auto",
)

# Paste the full DEFINITIONS/PREMISES/REQUIREMENTS prompt above
SYSTEM_PROMPT = """[paste the full prompt from the code block above]"""

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": "Analyze CVE-2024-3400. Map to ATT&CK and propose detection."},
]

inputs = tokenizer.apply_chat_template(messages, return_tensors="pt", add_generation_prompt=True)
outputs = model.generate(inputs, max_new_tokens=1024, temperature=0.2, top_p=0.9)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Customization

Want JSON output for SIEM integration? Replace OUTPUT_FORMAT with your schema (e.g., {"cve":"","cvss":0,"attack_techniques":[],"detection_rule":""}).
Building a chatbot for non-technical executives? Add to REQUIREMENTS: "Translate technical terms into business risk language."
Need stricter refusal on dual-use content? Add to EDGE_CASES: "Any question about weaponization -> immediate refusal with no explanation."
Working in regulated environments (HIPAA, PCI-DSS)? Add a section #6 to OUTPUT_FORMAT: "Compliance Impact" mapping to relevant controls.

Training details

Attribute	Value
Base model	unsloth/gemma-4-E4B-it
Architecture	Gemma4ForConditionalGeneration
Parameters	~4B
Context length	131,072 tokens
Method	QLoRA (4-bit quantization during training)
Training corpus	1,157,765 examples (primary) + 107,600 (correction delta)
Languages	Hebrew (~~45%) and English (~~55%)
Framework	Unsloth Studio

Dataset composition (1,157,765 primary examples)

Source	Examples	Language	Content
BrainboxAI CVE Corpus v2	994,713	Hebrew + English	280K CVEs × 8 task types
Fenrir v2.0	83,918	English	Causal reasoning on cyber threats
Trendyol Cybersecurity	53,199	English	200+ security domains
MITRE ATT&CK TTP Mapping	14,936	English	Activity → ATT&CK technique
HackerOne Disclosed Reports	9,353	English	Bug bounty reports + CWE mapping
MITRE ATT&CK Reasoning	1,646	English	Chain-of-thought on ATT&CK

Correction delta (107,600 additional examples)

After v1 evaluation, three weaknesses were identified and addressed via continued training on brainboxai_cyber_delta:

CVE hallucination — fabricated CVSS scores and details for real CVEs. Fixed with canonical NVD-sourced data.
ATT&CK sub-technique confusion — confused T1059.003 / T1053.005. Fixed with explicit disambiguation examples.
Missing "I don't know" behavior — fabricated instead of acknowledging uncertainty. Fixed with refusal examples.

See the delta dataset card for full methodology.

Evaluation

Post-training evaluation covered 30 diverse security tasks spanning:

CVE detail accuracy (lookup + explanation)
MITRE ATT&CK technique and sub-technique mapping
Sigma / YARA rule drafting
Vulnerability severity assessment
Hebrew-language incident report generation

Formal benchmarks on public security datasets are planned for v3 release.

Limitations

4B parameters. Not frontier capability. Will make mistakes on novel attack patterns and complex architecture analysis.
Training cutoff. CVE data reflects state at corpus construction time; newer CVEs are unknown to the model.
Hallucination residual risk. Even after delta correction, the model can fabricate CVE details. Always verify against NVD or vendor advisories.
Not a pentester. Will not autonomously conduct authorized offensive operations. Does not replace manual testing.
Dual-use content. The model can discuss attack techniques for defensive purposes. It will refuse clearly malicious requests but is not a hardened content-filter.
Biased toward public data. Training is dominated by public CVEs and reports; exotic or unpublished threats may be handled poorly.

Formats available

GGUF Q4_K_M (~4 GB) — for Ollama, llama.cpp, LM Studio
Safetensors 16-bit — for further fine-tuning, HF transformers

License

Apache 2.0. Free for commercial and non-commercial use with attribution.

Ethical use: This model is intended for defensive security work and authorized security research. Use in unauthorized offensive operations is prohibited by the license and by applicable law.

Citation

@misc{elyasi2026cyberanalyst,
  title        = {Cyber-Analyst 4B: A Bilingual On-Device Security Model for SOC and Pentest Workflows},
  author       = {Elyasi, Netanel},
  year         = {2026},
  publisher    = {BrainboxAI},
  howpublished = {\url{https://huggingface.co/BrainboxAI/cyber-analyst-4B}},
  note         = {Fine-tuned from unsloth/gemma-4-E4B-it on 1.16M security examples + 107K correction delta}
}