Zentral Osquery Extension

A collection of extra tables for osquery.

The extension is a single Go binary that registers a set of osquery virtual tables. Some tables are implemented in this repo, some come from upstream projects (macadmins/osquery-extension imported as a Go module, fleetdm/fleet vendored under tables/fleetdm/).

Tables

Name	Description	Platforms	Source
adobe_plugins	Adobe CEP / UXP / native plug-ins discovered by scanning well-known directories	macOS, Windows	fleet
app_sso_platform	Apple Platform SSO registration state for the logged-in user	macOS	fleet
bitlocker_key_protectors	BitLocker key protector types per drive	Windows	fleet
cis_audit	Security configuration data (auditpol, secedit) for CIS benchmark checks	Windows	fleet
falcon_kernel_check	Whether the running kernel is supported by the CrowdStrike Falcon sensor	Linux	fleet
falconctl	Status of the CrowdStrike Falcon agent (falconctl -g … parser)	macOS	local
falconctl_option	CrowdStrike Falcon agent options exposed via falconctl -g	Linux	fleet
google_chrome_profiles	Google Chrome profiles found on disk	macOS	macadmins
local_network_permissions	macOS local network permission grants per app	macOS	macadmins
macadmins_unified_log	log show query results from the macOS unified log	macOS	macadmins
macos_profiles	High-level information on installed configuration profiles	macOS	macadmins
mcp_listening_servers	Local processes that serve an MCP (Model Context Protocol) endpoint on a listening port	macOS, Linux, Windows	fleet
mdm	MDM enrollment status and DEP information	macOS	macadmins — see upstream notes about rate limits
sofa_security_release_info	macOS security release info for a given OS version (from SOFA)	macOS	macadmins
sofa_unpatched_cves	CVEs not yet patched on the running macOS version (from SOFA)	macOS	macadmins
wifi_network	Current Wi-Fi network name and security level	macOS	macadmins
windows_updates	Pending Windows updates returned by the Windows Update Agent COM API	Windows	fleet

Building

The build is pure Go (no cgo) and uses standard GOOS/GOARCH cross-compilation. Per-platform registration lives in main_<goos>.go files; build constraints ensure each target only pulls in the table packages that compile for it.

GOOS=darwin  GOARCH=arm64 go build .
GOOS=linux   GOARCH=amd64 go build .
GOOS=windows GOARCH=amd64 go build .

The output binary should be renamed to match osquery's extension convention (*.ext on Unix, *.ext.exe on Windows) before loading. The release pipeline produces correctly-named archives automatically.

Releases

Pushing a tag matching v* triggers .github/workflows/release.yml. The pipeline runs three jobs in parallel where possible:

• build-darwin runs on macos-latest with .goreleaser-darwin.yml. Native clang lets us embed Info.plist directly into the Mach-O binary as a __TEXT,__info_plist section. The two arch slices are combined into a single universal binary, which is then codesigned with a Developer ID Application identity and submitted to Apple's notary service.
• build-others runs on ubuntu-latest with .goreleaser-others.yml. Pure-Go cross-compilation for linux and windows on both amd64 and arm64.
• release collects the artifacts from both build jobs, generates a combined checksums.txt, and creates the GitHub release with auto-generated notes.

The workflow also supports workflow_dispatch for manual runs: leave the tag input empty for a snapshot dry-run that uploads artifacts without creating a release, or pass an existing tag to publish.

Apple signing secrets

The darwin job loads its signing material from 1Password at run time via the 1password/load-secrets-action. The repo must have a single GitHub Actions secret OP_SERVICE_ACCOUNT_TOKEN holding a 1Password service-account token with read access to the items below. The op:// paths are hard-coded in the workflow — adjust them there if your vault/item naming differs.

Vault CI, item Developer ID Application (signs the Mach-O binary):

field	content
certificate	base64-encoded contents of the exported .p12 certificate
password	passphrase for the .p12
identity	full identity name, e.g. Developer ID Application: Foo (TEAMID)

Vault CI, item Developer ID Installer (signs the .pkg installer):

field	content
certificate	base64-encoded contents of the exported .p12 certificate
password	passphrase for the .p12
identity	full identity name, e.g. Developer ID Installer: Foo (TEAMID)

Vault CI, item App Store Connect API Key (notarization):

field	content
key_id	10-character key identifier from App Store Connect
issuer_id	issuer UUID from App Store Connect
key	full contents of the .p8 private key file

The cert is imported into a temporary keychain that's discarded at the end of the job. notarytool runs in --wait mode — a release will fail if notarization is rejected.

Artifacts produced for each release:

• osquery-extension_<version>_darwin.pkg (signed + notarized + stapled installer)
• osquery-extension_<version>_darwin_all.tar.gz (universal binary: x86_64 + arm64)
• osquery-extension_<version>_linux_amd64.tar.gz
• osquery-extension_<version>_linux_arm64.tar.gz
• osquery-extension_<version>_windows_amd64.zip
• osquery-extension_<version>_windows_arm64.zip
• checksums.txt

Each tarball/zip ships the binary, project LICENSE.txt, README.md, and (in licenses/) the vendored fleet LICENSE and ATTRIBUTION.md.

macOS installer layout

The .pkg writes the following paths:

Path	Source
/usr/local/zentral/osquery/extensions/osquery-extension.ext	the signed universal binary
/usr/local/zentral/osquery/extensions.load	pkg/extensions.load — tells osqueryd which extensions to autoload

A no-op postinstall script lives at pkg/scripts/postinstall; future logic (e.g. signalling osqueryd to reload) can be added there.

The .pkg is a distribution package (not a bare component package). Per the macOS pkgbuild(1) man page, a component package "is typically incorporated into a product archive, along with a 'distribution' and localized resources, using productbuild(1)" — distribution packages also leave room to add installer UI (welcome / license screens, OS-version requirements, host architecture restrictions) by swapping the synthesized Distribution.xml for a hand-written one later. The release workflow runs pkgbuild to produce an unsigned component package, derives a Distribution.xml from it via productbuild --synthesize, then runs productbuild --distribution --sign to produce the final signed installer; the component is intentionally left unsigned because (also from pkgbuild(1)) "if you are going to create a signed product with the resulting package, using productbuild(1), there is no reason to sign the individual package."

Third-party code

• Code under tables/fleetdm/ is vendored from fleetdm/fleet under the MIT Expat license. See tables/fleetdm/LICENSE and tables/fleetdm/ATTRIBUTION.md for the pinned commit and the list of vendored packages.
• The macadmins tables are pulled in as a Go module dependency (github.com/macadmins/osquery-extension) rather than vendored — their license travels with the module.

License

This project is licensed under the MIT License — see LICENSE.txt.