HCL BigFix
Deep Understanding Report

For technical decision-makers who want to fully understand BigFix and rebuild a similar system. This report covers: the full BigFix architecture, the Fixlet/Relevance core mechanisms, the patch & threat-content supply chain, deployment and daily usage, a comparison with Zabbix and other tools, and a concrete rebuild design.

1Executive Summary: What BigFix Is and Why It Matters

Core This chapter gives you five judgments that frame the whole report.

1.1 BigFix in One Sentence

HCL BigFix (formerly IBM BigFix / IBM Endpoint Manager) is a content-driven endpoint and patch management platform: one server manages physical, virtual, and cloud endpoints worldwide through a "Content" mechanism — scanning for patch vulnerabilities, executing baseline tasks, and continuously monitoring compliance. Its differentiator: most analysis and execution work is pushed down to the Agent on each endpoint, rather than computed centrally by the server.

1.2 Five Core Judgments

1.3 Report Structure

2BigFix Architecture Overview

Core To understand BigFix, first understand its components and how "content" flows.

2.1 The Four Core Components

2.2 Data Flow (see it in one diagram)

            +-------------+   Fixlet content (Content Delivery cloud)
            |   Console    |<------------+
            +------+------+             |
                   | operator deploys    |
            +------v------+             |
            |    Server   |<------------+
            |  (SQL DB)   |  subscribes to site mastheads, pulls Fixlets
            +------+------+
                   | content + policy push (HTTPS)
            +------v------+
            |    Relay    |<---- hundreds of clients point to one Relay
            +------+------+
                   | distribute content / aggregate reports
            +------v------+
            |    Agent    |  <- local Relevance evaluation
            |  (each box)  |  <- executes Action remediation
            +-------------+  <- reports results/status

Content flow: Server pulls Fixlets from the Internet → distributes to Relays → relays to Agents → Agent evaluates relevance locally → reports which Fixlets are "relevant" → Server aggregates to the Console. Operators see "which machines network-wide are missing which patch," deploy an action with one click, and Agents re-evaluate to confirm after execution.

2.3 Why It Scales to 250,000 Endpoints (the architectural philosophy)

In traditional centralized architectures (e.g., WSUS + polling management servers), the server scans and pushes to each machine, so load grows linearly with endpoints. BigFix inverts this:

• Evaluation happens on the Agent: each machine's Agent runs the Fixlet's Relevance itself — the server never probes machine by machine. This is the single biggest load saving.
• Relay aggregation: hundreds of endpoints share a Relay; between Relay and Server there are only a few requests (dedup + compression).
• Event-driven reporting: Agents report only when relevance changes (new patch relevant / remediation done), not periodic heartbeat floods.
• Offline autonomy: disconnected machines keep evaluating against local policy; they sync incrementally on reconnect — so VPN/remote-office environments stay manageable.

2.4 Extended Components (awareness)

3Core Mechanisms: Fixlet / Relevance / Action / Baseline

Core This is BigFix's "operating system" — understand it and you truly understand BigFix.

3.1 Content Is Everything in BigFix

BigFix's official definition: "The platform is a dynamic, content-driven messaging and management system that distributes the work of managing IT infrastructures out to the managed devices themselves, the agents." Content is a generic term — it may be data to distribute, instructions to run, or queries to execute on targets. All content travels as Fixlet messages.

The four content types (must be clear):

3.2 Relevance Language: The Soul of BigFix (focus)

Relevance Language is BigFix's own query language for describing and retrieving information from endpoints/servers. Two flavors:

• Client Relevance: executes locally on each Agent, querying the local machine. Used for: a Fixlet's applicability (does this machine need this patch?), an Action's success criteria (is the patch installed?), and Analysis property collection. Analogy: it is BigFix's "SQL".
• Session Relevance: executes on the Server, querying the BigFix database. Used for: custom reports, dashboards, REST API integration.

Core syntax concepts (get the gist and you're in):

# Existence checks
exists file "/etc/hosts"                      -> True/False
exists folder "/var/tmp"
exists package "libxml2" of rpm

# Comparison checks (operators differ by object type)
number of processors = 1                      -> True
(version of package "libxml2" of rpm) >= "2.9.1"

# Filtering clause (whose + it, iterate and filter)
(files whose (it ends with ".log") of folder "/var/log")

# Conditional logic
if (exists file "/etc/passwd") then "linux" else "windows"

# Common inspectors (information retrievers)
name of operating system
version of operating system
ram (memory) size
IP addresses of net adapters
names of services whose (state of it = "Running")

3.3 Fixlet Structure (what a patch message looks like)

Fixlet: "Security Update for Windows (KB5000000)"
+-- Relevance (applicability conditions; ALL must be True)
|    +-- exists patch "KB5000000" (registry) = False   <- not yet installed
|    +-- version of operating system >= "10.0"         <- version matches
+-- Action (remediation steps, Action Script language)
|    +-- prefetch "http://download.../patch.msu"       <- download the patch
|    +-- wait / execute "wusa.exe KB5000000.msu"       <- silent install
|    +-- restart (optional)
+-- Success Criteria (again Relevance)
|    +-- exists patch "KB5000000" (registry) = True    <- installed
+-- Description / impact / risk / reference links
+-- Metadata: site, CVE, affected systems, Supersedes relations

Key point: both a Fixlet's "relevance" and its "success criteria" are expressed in Relevance. The Agent's flow: all Relevance True → Fixlet is "relevant" → report → operator runs the Action → re-evaluate Relevance (success criteria) → confirm the fix.

3.4 Action: The Agent-Side Execution Language

Action Script is the cross-platform scripting language inside a Fixlet that performs remediation. Common commands:

prefetch "URL" sha1="..." sha256="..."      # pre-download file (hash-verified)
wait "..."                                    # wait
execute "installer.exe /quiet"                # run a command
run "script.sh"                               # run a script
delete "path"                                 # delete
copy "src" "dst"                              # copy
createfile until=endofsection                 # generate file content
registry key ...                              # modify registry (Windows)
restart / reboot                              # reboot
requires ...                                  # prerequisites

An Action is "taken" by the operator in the Console → target selected (all relevant machines / a computer group) → effective time set → Agents pull and execute → progress and results report back.

3.5 Baseline: Bundling Content into a "Baseline Task"

Baseline = an ordered collection of Fixlets/Tasks, deployed in one shot to complete multiple configurations. This maps exactly to your project's "after VM deployment, execute a specific baseline per purpose":

Baseline "Web Server Security Baseline"
+-- Fixlet: Install KB5000000 (patch)
+-- Fixlet: Install KB5000001
+-- Task: Disable SMBv1
+-- Task: Set firewall rules to allow only 80/443
+-- Task: Disable default shares
+-- Analysis: Collect baseline compliance state

Baselines have compliance evaluation: every Fixlet inside has Relevance, so the Agent can report "this baseline is 60% complete on this machine," and the Console shows network-wide baseline compliance rates.

3.6 The Full Closed Loop (put it together)

4Patch Content Supply Chain: Where Patch Content Comes From and How It Is Managed

Core · the part you care most about BigFix's patch library is not "a downloaded database" — it is a continuously running content supply chain. This chapter dissects: information sources → the official content team → the sites system → customer consumption → quality assurance.

4.1 Information Sources: How They Know "What to Patch"

The official BigFix content team tracks vendor official vulnerability and patch release channels. Core sources:

4.2 How the Official Content Team Works (the content production pipeline)

HCL/IBM's Application Engineering Team produces patch Fixlets. The flow is roughly:

4.3 The Sites System: How Customers Consume Patches

Patch content is organized into Sites; customers consume it via subscriptions. Core mechanics:

• Masthead (.efxm file): a site's "ID card," containing the site URL and subscription keys. Getting and activating a masthead = subscribing to the site; the Server then pulls that site's content on schedule.
• Three site sources: IBM/HCL official sites (Patches for Windows etc.), external vendor sites (Tenable and other security vendors), and custom sites (customer-authored Fixlets).
• Domains: sites group by function (e.g., the "Patch Management" domain contains per-OS patch sites); the Console browses by domain.
• Default subscriptions: installation auto-subscribes to management/maintenance sites; other sites are subscribed per license terms.

Common patch sites in a customer environment (example):
  Patches for Windows                 <- Windows OS patches
  Updates for Windows Applications    <- Windows app patches (Java/Chrome/Adobe...)
  Patches for Linux                   <- Linux distro patches
  Patches for Mac OS X                <- macOS patches
  Custom Sites (customer-authored)    <- internal apps/baselines

4.4 Content Delivery Cloud: How Content Reaches Customers

HCL runs Content Delivery, a cloud distribution service. Customer Servers pull site updates on a subscription schedule (usually every few hours), then distribute via Relays network-wide. For air-gapped environments, the Airgap tool (BES Download Cacher) moves content manually — a key capability for defense/banking isolated networks.

4.5 Beyond Security Patches: Where Baseline Content Comes From

Beyond patches, BigFix provides Security Configuration Baselines, typically based on industry benchmarks:

• CIS Benchmarks (Center for Internet Security) — Windows/Linux/middleware hardening checks.
• Vendor hardening guides (Microsoft security baselines, Red Hat hardening guides).
• Compliance framework mappings (MLPS/等保, PCI-DSS, NIST requirements mapped to checks).

These baselines ship as "Relevance check + Action remediation" Fixlets; customers subscribe or author their own in the same format — exactly the reference prototype for your "different baseline per VM purpose" project.

5Deployment & Usage in Practice

Important The complete path from zero to a working BigFix environment and your first patch/baseline deployment. Items marked needs-verification follow official docs and should be validated in a real environment.

5.1 Choosing a Deployment Topology

5.2 Installing the Server (overview steps)

5.3 Deploying the Agent (three ways)

5.4 Daily Operation: Deploying Patches (Console flow)

5.5 Status Monitoring & Reporting (matches your requirement #2)

BigFix's "see the current state of every machine" is delivered by Analysis + Properties:

• Analysis: predefined or custom property-query sets; Agents collect and report on a query interval (installed-patch list, disk, CPU, service state).
• Computer Properties: literally "the result of a Relevance query" — show as custom Console columns or dashboards.
• Web Reports / BigFix Query: Session Relevance against the database — charts, exports, multi-server aggregation.
• REST API: /api/query?relevance=... or POST JSON — feed status into your own systems. This is exactly your integration point for "every machine reports state to me."

# REST API example: query all computer names (Session Relevance)
curl -u user:pass "https://bf-server:52311/api/query?relevance=name+of+client+computers"

5.6 Common Ops Quick Reference

6Competitive Comparison: Can Zabbix Replace It?

Important Directly answers your "can Zabbix also do this" question, plus a positioning map.

6.1 First, the Answer: Can Zabbix Do Patch Management

Conclusion: Zabbix covers half of your needs (status monitoring & reporting), but the other half (content library + remediation actions) is not its design goal.

6.2 Patch-Management Tool Landscape

6.3 BigFix's Moat (why customers choose it)

• Scale & performance: 250k endpoints per server, second-level visibility — far lower server resource demands than SCCM.
• Patch content quality & speed: official team + SLA + lab testing + Supersedes/Corrupt handling — customers get ready-made content with "zero research."
• Cross-platform unity: Windows / Linux / macOS with one Agent and one Console — no per-platform tooling.
• Offline autonomy: disconnected machines keep evaluating and executing against local policy; incremental sync on reconnect — VPN/remote-friendly.
• Programmability: Relevance language + REST API let customers deeply customize baselines and integrate.
• Open content ecosystem: official + vendor + custom sites mixed — not a closed list.

7Rebuild Design: Building Your Own BigFix

Core · your end goal Building on the first six chapters, here is a concrete rebuild design: architecture, API compatibility, data model, and the implementation path for your two core features.

7.1 Scoping the Rebuild (define the boundary first)

Your goal: a client Agent + a server, compatible with BigFix API design, implementing two core features: ① remote install tasks (patching); ② status monitoring & reporting.

7.2 Target Architecture (mapped to BigFix's four layers)

7.3 Core Design Decisions (the "soul" to copy)

7.4 API Design (modeled on BigFix's real API)

BigFix's real REST API core is Session Relevance queries: `/api/query?relevance=...` queries the database with the Relevance language. You don't need to clone the Relevance language itself, but you can clone its interface style:

# Example: launch a remote install task
POST /api/actions
{
  "contentId": "patch-kb5000000",
  "targets": ["vm-001", "vm-002"],
  "schedule": "immediate",
  "timeoutSec": 1800
}
-> 200 { "actionId": "act-12345", "status": "dispatched" }

# Example: Agent pulls tasks (agent's view)
GET /api/agent/actions?agentId=vm-001&ack=auth-token
-> { "actions": [{ "id": "act-12345", "steps": [{ "type": "exec", "cmd": "wusa.exe KB5000000.msu /quiet" }] }] }

# Example: Agent reports status
POST /api/agent/status
{ "agentId": "vm-001", "properties": { "os": "Windows Server 2019", "patches": ["KB5000000"], "lastBoot": "2026-10-01T08:00:00Z" } }

7.5 Agent Client Design (implementing the two core features)

Feature 1: Remote install tasks

Agent lifecycle:
1. Register: first boot -> POST /api/agent/register -> get agentId + auth token
2. Poll: every N seconds -> GET /api/agent/actions?agentId=... -> pending tasks
3. Execute: run the task steps (download/unpack/run script/silent install)
4. Report: POST /api/agent/action-result -> success/failure/exit code/log
5. Idempotency: tasks carry an idempotencyKey; Agents dedupe / resume

Feature 2: Status monitoring & reporting

Two collection modes:
1. Property reporting: Agent periodically collects preset properties -> reports to Server
   e.g., os version / installed patches / disk space / CPU / service state / last boot
2. Event reporting: immediate report on state change (patch installed / service down)
   e.g., POST /api/agent/events { "type": "patch-installed", "patch": "KB5000000" }

Server side:
- store latest property snapshot (current state) + event timeline (history)
- aggregate: online rate / patch compliance / baseline completion
- display: Web console dashboard / REST API queries

7.6 Technology Selection (for your decision)

7.7 Relationship with Zabbix (complement, not either-or)

If you already run Zabbix, the recommendation: Zabbix keeps doing metrics/alerts; your system does task deploy/patch/baseline — interconnect via webhook/API (e.g., a Zabbix alert triggers your remediation task). This is exactly how many BigFix customers really use it.

7.8 Milestone Roadmap (first release in 4-6 weeks)

8Roadmap · Glossary · Appendix

Reference Decision roadmap, must-know glossary, references, and disclaimer.

8.1 Your Decision Roadmap (pick one of three)

8.2 Glossary

8.3 References

• HCL BigFix Platform official docs (help.hcl-software.com/bigfix)
• HCL BigFix Developer site (developer.bigfix.com) — Relevance language, REST API reference
• IBM BigFix Patch official docs and user guides (content release mechanics)
• BigFix official forum (forum.bigfix.com) — content release announcements, real ops cases
• BigFix Getting Started Guide (architecture and scale PDF)

8.4 Disclaimer & Verification