Security
Four orthogonal questions about a compiled binary fall under the word security. The engine treats them as four separate surfaces. Each has its own taxonomy, its own rule format, its own confidence model, its own brief.
| Question | Surface | Taxonomy | Output |
|---|---|---|---|
| What is wrong with the code? | Findings | MITRE CWE | Per-call-site finding with cwe_id, rule_id, severity, confidence |
| What does this binary do? | Indicators | capa categories + MITRE ATT&CK | Per-hit fact with category, evidence, T-numbers |
| Is this binary malicious? | Malware | Four-tier verdict (Benign / Suspicious / LikelyMalicious / Malicious) | One verdict per binary, composed over the three other surfaces |
| Does it contain a known-vulnerable version of a known component? | CVEs & SBOM | MITRE CVE | Per-component SBOM row with name, version, evidence layer, CVE list |
The four are independent on purpose. A binary with twenty CWE findings is not necessarily malicious — legitimate software written by people who never read the secure-coding guidelines fires the same strcpy rule as malware that uses strcpy because nobody writing malware reads them either. A binary with no CWE findings is not necessarily safe — a polished implant has clean code. Indicators are facts about behavior, deliberately unscored; the malware verdict is where those facts compose into a judgment. CVE/SBOM matches are a fifth axis — they say nothing about the binary's own code, only that the OpenSSL it bundles has known unpatched vulnerabilities.
When to use which
The decision an analyst is making determines which surface they read first.
Auditing your own code for shipping defects. Start with Findings. The CWE catalog covers the memory-safety, crypto, injection, identity, and posture classes that show up in security review. Treat the findings as a list of facts about your code; apply your own judgment about which deployment-context factors make any given finding exploitable. The triage signal reachable_from_main is your highest-leverage filter; the per-CWE detail pages document each rule's confidence and false-positive posture.
Auditing a third-party binary you have not seen before. Start with Indicators to understand what the binary actually does — the capa-style categories give you a quick read on persistence, network behavior, credential handling, and obfuscation. Then check Malware for the four-tier verdict, which composes those indicators with semantic shape detectors (process hollowing, keychain dumping, TCC bypass, dyld injection). Findings come last for this workflow — they describe code quality, which is informative but rarely decisive.
Auditing firmware or a container that bundles open-source components. Start with CVEs & SBOM. The three-layer stack — path patterns, per-binary version banners with semver compare, firmware-version lookup — identifies known-vulnerable versions of upstream packages (BusyBox, OpenSSL, dnsmasq, the Linux kernel, OpenSSH, Dropbear, Apache, Samba, CUPS) and the vendor-firmware-level CVEs that map directly to a container version string. Findings, indicators, and malware all run too; the SBOM surface is what makes a firmware audit tractable in the first place.
Building a CI gate. All four. Findings baseline against a known-good build so only new CWE introductions ring; indicators baseline so a new ATT&CK technique appearing is its own signal; malware verdict has hard gates (any benign fixture going Suspicious or above fails CI); SBOM matches block builds when a vendored component crosses a max_vulnerable threshold.
What is deliberately not here
No CVSS scores. Severity on findings is a per-instance hint, not a quantitative risk metric. CVSS depends on deployment context that the engine does not have.
No remediation guidance. The engine reports what it sees; it does not tell you how to patch. CVE detail is upstream fields only (name, severity, description); no patching, no fix-it instructions, no "upgrade to version X" advice. That separation is intentional and policy-grade.
No live ATT&CK or NVD fetches. Both the ATT&CK technique catalog (430 macOS-relevant techniques) and the CVE rule tables are pinned at build time. Reproducibility wins over freshness.
No dynamic analysis. Everything in all four surfaces is static. The engine does not execute the binary, sandbox it, hook it, or instrument it. A fuzzer reaches paths a static analyzer never will; the two are complementary.
No automatic family attribution. Malware-family fingerprints under indicators (Indicators — Family fingerprints) report shared strings with samples attributed to family X. They never claim the binary is family X. Attribution is a judgment, not a fact.
Where this fits in the engine
All four surfaces are downstream of the same analysis pipeline. The Engine brief walks the pipeline end to end (READ → LIFT → REASON → IDENTIFY → JUDGE → EMIT). The four security surfaces are the JUDGE layer, partitioned by the question each answers. Below them, the same recovered call graph, the same SSA-form IL, the same constant-propagation results, the same string and import inventories, the same code-signature parse. The taxonomies above the pipeline differ; the input does not.