BrainboxAI/cyber-analyst-4B

bx-cyber-nogah

Repository id: BrainboxAI/cyber-analyst-4B

A bilingual Hebrew and English security analyst that runs entirely on your own machine. Your security data never leaves it.

About the name. bx-cyber-nogah is this model's name under the BrainboxAI naming convention: bx for the lab, cyber for the domain, and nogah (Hebrew for the planet Venus, the morning star) for the middle size tier. The repository id stays BrainboxAI/cyber-analyst-4B and will not change. Every existing link and script keeps working.

About version stability. Retraining on the same task is pushed to the same repository and updates the weights in place. Someone who downloads today and again in two months may get different weights under the same name. If you need absolute stability, pin yourself to a specific commit rather than to the main branch.

---

What it is

A language model trained on security material that answers in both Hebrew and English. It was built to reason in the order a SOC analyst reasons: identify the vulnerability, rate its severity, map it to MITRE ATT&CK, propose detection logic, and write a report a customer can read.

It is built on Google's unsloth/gemma-4-E4B-it.

What "runs on your machine" means here. The quantised file is about 5.3 GB and runs on a single consumer GPU. You can run it on a fully air-gapped network. No finding, no report and no customer name leaves the machine.

Why it exists

Security data is among the most sensitive material a company holds. Sending an internal finding, a vulnerability analysis or a customer incident report to a cloud model is usually a breach of policy or of contract.

This model is the alternative: small enough to run locally, fluent in Hebrew and English, and deployable inside a closed network.

It does not replace an analyst. It is a force multiplier for a SOC team, a pentest consultancy, or a researcher who wants help without handing over the material.

What it is for

• CVE triage and first-pass severity assessment.
• Mapping observed behaviour to a MITRE ATT&CK technique.
• Drafting detection logic: Sigma, YARA, Snort.
• Writing a pentest or incident report for a customer, in Hebrew or English.
• First-pass vulnerability analysis in bug bounty workflows.
• Deployment inside an organisation that cannot send material out.

What it is not, and what you must not do with it

• It is not a source of truth on CVEs. It fabricates vulnerability details: a CVE id that does not exist, a CVSS score nobody calculated, an ATT&CK technique with no such identifier. A correction round was run against this (described below) and it reduced the problem. It did not remove it. Always verify against NVD and the vendor advisory.
• No autonomous security decisions. Nothing it writes should trigger an action without a person reading and approving it.
• It is not an offensive tool. Weapons development and unauthorised offensive operations are prohibited by the licence and by law.
• It does not respond to incidents. A live incident needs a human analyst. A model that answers fast does not become a model that is right.
• It does not protect critical infrastructure without separate, independent validation.
• It has a knowledge cutoff. Vulnerabilities published after the data was collected simply do not exist for it, and it does not know they are missing.
• It is not a content filter. It discusses attack techniques for defensive purposes. It refuses clearly malicious requests, but it is not a hardened safety mechanism.
• It has no score on a public benchmark. See the Evaluation section.

How to run it

Ollama

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

A warning about the Modelfile in this repository. That file is left over from the build step, and the chat template inside it is not Gemma-4's. Do not build a model from it with ollama create. Use the ollama pull above, which constructs the correct template from the GGUF file itself.

llama.cpp

The file inside the repository is named gemma-4-E4B-it.Q4_K_M.gguf. The name is left over from the build step. It is the fine-tuned model, not the base model.

./llama-cli -m gemma-4-E4B-it.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

Reporting in Hebrew is one of the things this model was trained for, so here is the Hebrew case:

# Prompt: "Write a short incident summary in Hebrew for a customer: an attacker
#          used PowerShell to download and run a remote payload."
./llama-cli -m gemma-4-E4B-it.Q4_K_M.gguf \
  -p "כתוב סיכום אירוע קצר בעברית ללקוח: תוקף השתמש ב-PowerShell כדי להוריד ולהריץ payload מרוחק." \
  --temp 0.2 --top-p 0.9 -n 1024

The prose comes back in Hebrew. Technical terms (CVE, ATT&CK, CVSS, PowerShell) stay in English, which is how Israeli security teams actually write.

Python, through the safetensors repository

The repository BrainboxAI/cyber-analyst-4B-safetensors is currently private, so the code below will not run without access. The open route to running this model is Ollama or llama.cpp, above. For access to the full weights, use the contact address at the foot of this card.

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	Why
temperature	0.2	Low creativity. Security work wants facts
top_p	0.9	Standard nucleus sampling
max_new_tokens	1024	Enough for a detailed analysis with a detection rule
repetition_penalty	1.05	Stops the model looping on a CVE citation

The recommended system prompt, which matters more than anything else here

A model this size produces much more reliable analyses when it is forced through five steps instead of answering freely. Given an open question it tends to fabricate CVE details, miss a sub-technique, or skip the detection logic entirely.

Security work has no tolerance for an invented fact. A wrong CVSS score or a MITRE technique that does not exist sends an entire investigation to the wrong place.

The five steps: threat identification, severity assessment, ATT&CK mapping, detection logic, and caveats with sources to verify against.

And this is an impression, not a measurement. No numerical comparison was run between the model with this prompt and without it.

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 prompt from the code block 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))

Customisation

• Need JSON for a SIEM? Replace OUTPUT_FORMAT with your schema.
• Building a tool for non-technical executives? Add a requirement to translate terms into business risk language.
• Need stricter refusal on dual-use content? Add an immediate-refusal rule to EDGE_CASES.
• Working under HIPAA or PCI-DSS? Add a "Compliance Impact" section to OUTPUT_FORMAT.

Training details

Attribute	Value
Base model	unsloth/gemma-4-E4B-it
Architecture	Gemma4ForConditionalGeneration
Context length	131,072 tokens
Method	QLoRA. The base model is loaded in 4 bits during training
Framework	Unsloth
Primary corpus	1,157,765 examples
Correction set	107,600 further examples
Total	1,265,365 examples
Language mix	Roughly 45% Hebrew, roughly 55% English
Hyperparameters, hardware, wall time and cost	Not recorded

A note on sources. No independent training record survived for this model. Everything in the table above comes from the model's own previous card. There is no log file, no run report, and no second source to check it against. Rows that were not on that card are left empty rather than filled with a guess.

A note on "1.16M" against "1.27M". Both figures have appeared on cards in this family, and both are correct. 1.16 million is the primary corpus alone. 1.27 million is the primary corpus plus the correction set. The exact numbers are in the table above.

What the primary corpus is made of

Source	Examples	Language	Content
BrainboxAI CVE Corpus v2	994,713	Hebrew and English	280K CVEs across 8 task types
Fenrir v2.0 (AlicanKiraz0/Fenrir)	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 to ATT&CK technique
HackerOne Disclosed Reports (hackaprompt/hackerone-reports)	9,353	English	Bug bounty reports with CWE mapping
MITRE ATT&CK Reasoning (cobo512/mitre-attck-reasoning)	1,646	English	Chain-of-thought on ATT&CK
Total	1,157,765

Three of the sources above, AlicanKiraz0/Fenrir, cobo512/mitre-attck-reasoning and hackaprompt/hackerone-reports, are no longer reachable on Hugging Face as of writing. The names stay here as provenance, not as links. The links to them on the previous card were broken and have been removed.

BrainboxAI's own datasets (brainboxai_cyber_train and brainboxai_cyber_delta) are not public. They appear in this repository's metadata to record provenance, not as a link you can open.

The correction set, and what was broken in version one

After evaluating the first version, three weaknesses were found, and a further 107,600 examples were trained on to fix them:

1. Fabricated CVE details. The model produced CVSS scores and details for real CVEs. Fixed with canonical NVD-sourced data.
2. Confusion between ATT&CK sub-techniques. It mixed up T1059.003 and T1053.005. Fixed with explicit disambiguation examples.
3. It could not say "I do not know." Rather than admit uncertainty it fabricated. Fixed with refusal examples.

The correction reduced the first problem. It did not remove it. See the Limitations section.

Evaluation

No scored public benchmark was run on this model. There is no score, and no number you can compare against another model.

What was done instead: an internal evaluation across 30 security tasks. CVE detail accuracy (lookup and explanation), ATT&CK technique and sub-technique mapping, Sigma and YARA drafting, severity assessment, and Hebrew incident-report writing.

How to read that, honestly. There is no results file, no per-task score, and no way to reproduce it from outside. It is enough to say the model was checked. It is not a benchmark.

What that means for you: there is no measured evidence that this model is better than its base model at anything. There is work that was done and an impression formed. Those are two different things.

Limitations

• It is a small model. At this size it will get novel attack patterns and complex architecture analysis wrong.
• Knowledge cutoff. The CVE data reflects the state of the world at build time. Newer vulnerabilities are unknown to it.
• It still fabricates, even after the correction round. Always verify against NVD and the vendor.
• It is not a pentester. It runs nothing and replaces no manual testing.
• Dual-use content. It discusses attack techniques for defensive purposes. It is not a hardened content filter.
• Public-data bias. Training is dominated by public CVEs and reports, so exotic or unpublished threats are handled poorly.
• No benchmark. See the Evaluation section.
• It is a fine-tune of unsloth/gemma-4-E4B-it. Every limit of that model is still here.

Files and repositories

Repository	What is inside	Who wants it
BrainboxAI/cyber-analyst-4B	gemma-4-E4B-it.Q4_K_M.gguf (5.3 GB) and this card	Ollama, llama.cpp, LM Studio
BrainboxAI/cyber-analyst-4B-safetensors	Merged 16-bit weights (16.0 GB). Private repository	transformers and continued training, on request
BrainboxAI/cyber-analyst-4B-verifier-pilot	A follow-on experiment: a model that verifies findings	Anyone who wants to see where this goes next

The repository also holds gemma-4-E4B-it.BF16-mmproj.gguf (0.99 GB). That is Gemma-4's vision component, needed only if you want to feed it images, such as a screenshot of a finding. Text analysis does not need it.

License

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

This is a fine-tune of unsloth/gemma-4-E4B-it, so the terms of that model apply to this one as well. The base model is published under Apache 2.0 and also points to the Gemma 4 licence terms.

Ethical use: this model is for defensive security work and authorised research. Use in unauthorised offensive operations is prohibited by the licence and by law.

Citation

@misc{elyasi2026cyberanalyst,
  title  = {Cyber-Analyst 4B (bx-cyber-nogah): 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,157,765 security examples plus a 107,600-example correction set}
}

Author

Built by Netanel Elyasi, founder of BrainboxAI, an Israeli applied-AI studio building small, private, domain-specialised models.

For in-house deployment, tuning on internal material, or a question about fit: netanele@brainboxai.io.

Part of the BrainboxAI family of on-device models. See also law-il-E2B (law) and code-il-E4B (code).