platform_security

How it works

Two read-only actions report whether boot-time and code-signing protections are configured on: secure_boot (is Secure Boot enforced) and code_integrity (is the OS restricting what code may run). Each writes rows of the form <action>|<os>|<key>|<raw>|<state>. Neither takes parameters, so no request text reaches a path, a registry name or a command line. Linux reads a few efivarfs and securityfs files; Windows reads registry values; macOS reports secure_boot as unsupported and runs spctl --status and csrutil status for code_integrity. Every read is a value with a state, absent (the OS definitively says it is not there) or unreadable (the read failed), and a failed read never reads as absent. enabled, disabled and partial describe the protection, not the raw number. The Windows rows report configured policy, not proof of what is running.

flowchart LR
  OP["Operator or workflow"] --> SRV["Server, authz Security Read"]
  SRV -->|"gRPC over mTLS"| EX["platform_security execute: secure_boot or code_integrity"]
  EX --> WIN["Windows leg: RegQueryValueExW on the SecureBoot State, CI Policy, DeviceGuard and Lsa keys"]
  EX --> MAC["macOS leg: secure_boot writes an unsupported row, code_integrity runs spctl and csrutil with a 5 second deadline"]
  EX --> LIN["Linux leg: open and read of efivarfs SecureBoot and SetupMode, securityfs lsm and lockdown"]
  WIN & MAC & LIN --> ROWS["rows with raw value and state, status OK, CONSTRAINED or PERMISSION_DENIED, UNAVAILABLE for macOS secure_boot"]
  ROWS --> RS[("ResponseStore")] --> API["REST /api/responses"]

This plugin’s priority is asserted, not evidenced: it was built from a reading of a capability gap, and no capability-map requirement, parity gap, compliance control, roadmap item or named customer asks for it.

What is read

• Linux (open and read, errno classified, no process started). secure_boot reads the efivarfs SecureBoot-* and SetupMode-* variables (a 4-byte attribute word plus one data byte). code_integrity reads /sys/kernel/security/lsm (the active LSM list) and /sys/kernel/security/lockdown (the bracketed active mode).
• macOS. secure_boot writes one unsupported row (there is no public API; SIP is reported under code_integrity). code_integrity runs /usr/sbin/spctl --status (Gatekeeper) and /usr/bin/csrutil status (SIP) as fixed commands through a time- and output-limited subprocess runner: absolute path, no shell, no search path, a 5 second deadline and an output cap. Neither state has a library API.
• Windows (RegQueryValueExW, 64-bit view, under HKLM\SYSTEM\CurrentControlSet\Control). SecureBoot\State (UEFISecureBootEnabled); CI\Policy (every value, names enumerated first, then one read each); DeviceGuard (EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, HypervisorEnforcedCodeIntegrity); DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity (Enabled); and Lsa (LsaCfgFlags). LsaCfgFlags is the Credential Guard setting and lives under Control\Lsa, not Control\DeviceGuard: 1 is enabled with a UEFI lock (enabled_locked), 2 is enabled without one.

How absence is decided

A BIOS or CSM (legacy-BIOS compatibility) boot has no efivars, many kernels have no lockdown LSM (Linux Security Module) and a default Windows install has no DeviceGuard values. Each of these is an absent row that adds no reason token and leaves the status OK. The rule differs by OS, because a not-found can also mean the surface itself was never exposed.

• Linux. A leaf ENOENT is absent only when the parent pseudo-filesystem is confirmed present. For code_integrity, /sys/kernel/security must be mounted as securityfs (checked by the statfs magic number); if it is not, the ENOENT becomes ENODEV and the row reads unreadable with <key>:errno_19. For secure_boot, /sys/firmware/efi/efivars must be efivarfs whenever /sys/firmware/efi exists; if /sys/firmware/efi does not exist at all the host is treated as non-UEFI and the variables read absent. A refusal (EACCES, EPERM) is unreadable with <key>:eacces, and a file of 4096 bytes or more is unreadable with <key>:errno_27.
• macOS. spctl and csrutil are sealed-system-volume binaries with no legitimate “not there” case, so a tool that cannot be started (including a missing binary) reads unreadable, never absent. Text that parses is trusted whatever the exit status.
• Windows. The decision is made per key. SecureBoot\State, CI\Policy and both DeviceGuard keys can genuinely be missing on a real host and read absent. Lsa is foundational NT infrastructure with no evidenced not-found case, so a missing Lsa key reads unreadable with lsa:key_missing; a LsaCfgFlags value missing from an opened Lsa key is still legitimately absent.

What you can decide with it

• What the Windows states mean. deviceguard.EnableVirtualizationBasedSecurity, deviceguard.HypervisorEnforcedCodeIntegrity and deviceguard.hvci_scenario_enabled read 0 disabled, 1 enabled. deviceguard.RequirePlatformSecurityFeatures reads 0 disabled and 1 or 3 (Secure Boot, plus DMA protection) enabled. lsa.LsaCfgFlags reads 0 disabled, 1 enabled_locked, 2 enabled. Any other value is unmodelled and the raw value is kept. Every other value found under CI\Policy is listed by name as unmodelled.
• What the macOS states mean. gatekeeper is enabled for assessments enabled and disabled for assessments disabled. sip is enabled or disabled for the exact status line, and partial for enabled (Custom Configuration).. Any other text is unmodelled.
• Absent is an answer, not a pass. On Linux, absent on secure_boot means no efivars were visible to the agent; inside a container it does not tell you the host’s firmware mode (caveat 1). On Windows, absent for a deviceguard.* row means the feature is not configured, not that it is running.
• Not covered. Whether a Windows feature is actually running, macOS boot-security policy on Apple silicon, and TPM or measured-boot state.
• Per OS. Keys and states differ by OS, so a fleet check branches on the <os> column. OK means every key was read or definitively absent; it is not a compliance verdict.

Diagrams

Linux read of one variable or file

flowchart TD
  A["open the efivar or securityfs file"] --> B{"open result"}
  B -->|"opened"| C["read, at most 4095 bytes"]
  C -->|"expected shape"| V["decode and map to a state"]
  C -->|"efivar not 4 + 1 bytes"| U1["unreadable, key:efivars:shape"]
  C -->|"4096 bytes or more"| U2["unreadable, key:errno_27 (file too large)"]
  B -->|"ENOENT"| D{"parent surface present?"}
  D -->|"surface missing"| U3["unreadable, key:errno_19"]
  D -->|"present, or no /sys/firmware/efi"| AB["absent, no token"]
  B -->|"EACCES or EPERM"| U4["unreadable, key:eacces, status PERMISSION_DENIED"]
  B -->|"other errno"| U5["unreadable, key:errno_n"]

“Surface missing” means securityfs is not mounted at /sys/kernel/security, or /sys/firmware/efi exists but /sys/firmware/efi/efivars is not efivarfs. A host with no /sys/firmware/efi takes the absent branch, and a container that hides that directory is indistinguishable from a BIOS boot, which is why caveat 1 exists.

macOS tool outcome

flowchart TD
  R["run spctl or csrutil with a 5 second deadline"] --> Q{"outcome"}
  Q -->|"could not start"| U1["unreadable, key:spawn_failed, eacces or errno_n"]
  Q -->|"deadline hit"| U2["unreadable, key:timeout"]
  Q -->|"output cut at the cap"| U3["unreadable, key:output_truncated"]
  Q -->|"ran"| P{"first line matches a known status?"}
  P -->|"yes, any exit code"| S["enabled, disabled or partial"]
  P -->|"no, exit 0"| M["unmodelled, raw text kept"]
  P -->|"no, non-zero exit"| U4["unreadable, key:exit_n or key:exit_signal"]

OS capability

Declared limits per leg (descriptor fallback text, verbatim):

• secure_boot / macOS — no public API; SIP reported under code_integrity

Privileges and prerequisites

Binaries and subprocesses: macOS code_integrity runs exactly two, /usr/sbin/spctl --status and /usr/bin/csrutil status (each by absolute path, no shell); every other leg is an in-process read and spawns nothing. Network: none.

Data contract

Inputs

Neither action takes parameters.

Outputs

Pipe-delimited rows written via write_output(), in read order. The first field is the fixed action literal (secure_boot or code_integrity), then <os>, <key>, <raw> and <state>. <raw> is - when nothing was read (absent, unreadable, unsupported); a raw value that was read passes through the shared untrusted-output escaper, which turns a backslash into / and escapes a pipe.

• Row order. Linux secure_boot writes secure_boot then setup_mode; Linux code_integrity writes lsm then lockdown; macOS writes gatekeeper then sip.
• Windows row count. Rows can outnumber the named values, because every CI\Policy value is listed, sorted by name, with the one modelled value mapped and the rest unmodelled.
• Return codes. The action returns 0 for every data-level outcome; an unknown action name returns 1 with the single row unknown action: <name>, and an internal exception returns 1 with the single two-field row constrained|internal_error.

crossplatform.platform_security.code_integrity — row_kind|os|key|raw|state

crossplatform.platform_security.secure_boot — row_kind|os|key|raw|state

Result status

Where the data goes

• Instruction result. Rows travel over the agent’s mTLS gRPC channel as the command response and land in the ResponseStore, queryable at /api/responses/{id}. Both actions are gathered definitions (crossplatform.platform_security.secure_boot, crossplatform.platform_security.code_integrity, 300s TTL).
• Not consumed by daily-sync, Echo, DEX, or metrics.
• Sensitivity. Rows carry boot-integrity and code-signing settings only: no username, path, process name or installed-software name. The values are a security-posture baseline of the host (for example Secure Boot off, Gatekeeper off, lockdown none), which tells an attacker where enforcement is weak, so the rows warrant the same handling as other Security data.
• Siblings: vuln_scan (its configuration checks run spctl --status and csrutil status through popen as pass/fail findings; this plugin reports the raw text and a state over the bounded runner) and bitlocker (disk encryption posture).

Sample output

Windows — captured: windows Windows 10.0.26200 x86_64 · bare-metal · 2026-09-21 · LocalSystem (elevated) · leg-hash 9cf003de2f97

== action=secure_boot
secure_boot|windows|UEFISecureBootEnabled|1|enabled
[result_status] OK / FULL

== action=code_integrity
code_integrity|windows|ci_policy.EmodePolicyRequired|0|unmodelled
code_integrity|windows|ci_policy.SAC_PreviousState|4294967295|unmodelled
code_integrity|windows|ci_policy.SkuPolicyRequired|0|unmodelled
code_integrity|windows|ci_policy.VerifiedAndReputablePolicyState|0|disabled
code_integrity|windows|deviceguard.EnableVirtualizationBasedSecurity|-|absent
code_integrity|windows|deviceguard.HypervisorEnforcedCodeIntegrity|-|absent
code_integrity|windows|deviceguard.RequirePlatformSecurityFeatures|-|absent
code_integrity|windows|deviceguard.hvci_scenario_enabled|-|absent
code_integrity|windows|lsa.LsaCfgFlags|-|absent
[result_status] OK / FULL

macOS — captured: macos macOS 26.6.2 arm64 · bare-metal · 2026-09-21 · euid 501 · leg-hash 9cf003de2f97

== action=secure_boot
secure_boot|macos|secure_boot|-|unsupported
[result_status] UNAVAILABLE / FULL / no public API; SIP reported under code_integrity

== action=code_integrity
code_integrity|macos|gatekeeper|assessments enabled|enabled
code_integrity|macos|sip|System Integrity Protection status: enabled.|enabled
[result_status] OK / FULL

Linux — captured: linux Debian GNU/Linux 13 (trixie) aarch64 · container · 2026-09-23 · euid 0 · leg-hash 9cf003de2f97

== action=secure_boot
secure_boot|linux|secure_boot|-|absent
secure_boot|linux|setup_mode|-|absent
[result_status] OK / FULL

== action=code_integrity
code_integrity|linux|lsm|-|unreadable
code_integrity|linux|lockdown|-|unreadable
[result_status] CONSTRAINED / PARTIAL / lsm:errno_19,lockdown:errno_19

Caveats and known gaps

1. A container without /sys/firmware/efi reads Secure Boot as absent, even on a Secure Boot host. The mount check separates “mounted, but this value is absent” from “the surface is not mounted” for the securityfs reads, but not for efivarfs: a default container’s /sys tree omits /sys/firmware/efi whatever the host’s firmware, and neither deploy/docker/Dockerfile.agent nor the repository’s compose files bind-mount it. Closing this needs a deploy-side change (bind-mounting /sys/firmware/efi read-only into the agent container), and the Linux sample, a container capture, shows exactly this on its two secure_boot rows.
2. Configured policy, not runtime proof. The Windows rows read registry values, which say what is configured. Whether Device Guard, HVCI or Credential Guard is actually running is a separate runtime fact (Win32_DeviceGuard) that this plugin does not query, and it does not call WLDP.
3. macOS secure_boot is unsupported, and code_integrity parses tool text. There is no public API for the boot-security policy and bputil is a recovery-environment tool that is not run, so secure_boot always reports UNAVAILABLE on a Mac. Gatekeeper and SIP have no library API either, so both are read from a tool’s text: the parsers match an exact line and report anything else as unmodelled. Security.framework SecStaticCode* is not used, because every call in that family validates one named code object’s own signature, not a machine-wide enforcement setting.
4. Fixed reads, no discovery. The plugin reads only the keys named above; it does not walk securityfs or the registry (apart from listing the value names under CI\Policy), and it does not report TPM or measured-boot state.
5. Windows CI\Policy is listed whole but modelled for one value. Every value under the key appears as a row, but only VerifiedAndReputablePolicyState has a state mapping; the others (for example SkuPolicyRequired) read unmodelled with the raw number, which says the value exists, not what it means.

Source and tests

• Plugin: agents/plugins/platform_security/src/platform_security_legs.hpp · agents/plugins/platform_security/src/platform_security_linux.cpp · agents/plugins/platform_security/src/platform_security_macos.cpp · agents/plugins/platform_security/src/platform_security_parsers.hpp · agents/plugins/platform_security/src/platform_security_plugin.cpp · agents/plugins/platform_security/src/platform_security_win.cpp · agents/plugins/platform_security/src/platform_security_win_parsers.hpp
• Definitions: content/definitions/platform_security.yaml
• Capability rows: server/core/src/capability_decls/plugin_action_catalogue_platform_security.hpp
• Tests: tests/unit/test_platform_security_local_dispatcher.cpp · tests/unit/test_platform_security_parsers.cpp · tests/unit/test_platform_security_win_parsers.cpp
• Privilege row: docs/agent-privilege-model.md