usnistgov/macos_security
1
0
Fork 0
mirror of https://github.com/usnistgov/macos_security.git synced 2026-02-03 05:53:24 +00:00
Code Issues 21 Actions Packages Projects Releases Wiki Activity

Incorrect logic in system_settings_softwareupdate_current #31

New Issue
Open
opened 2026-01-19 18:28:59 +00:00 by michael · 2 comments
michael commented 2026-01-19 18:28:59 +00:00
Owner
Copy Link

Originally created by @phaninder-scalefusion on GitHub.

Summary

The system_settings_softwareupdate_current rule uses LastFullSuccessfulDate to determine if the device is up-to-date. This is unreliable because the value changes even when running softwareupdate -l, without confirming update status.

Steps to reproduce

  1. Run the compliance script that checks LastFullSuccessfulDate.
  2. Run softwareupdate -l.
  3. Notice that the compliance check reports the device as up-to-date even when updates are pending.

Operating System version

(macOS 13 / 14 / 15 – reproducible across builds)

Intel or Apple Silicon

Both

Current behavior

Reports device as compliant when updates are still available.

Expected behavior

Compliance should only report up-to-date when no new software updates are available.

Relevant logs

defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist LastFullSuccessfulDate
# Shows a recent date even though updates are pending

Possible fixes

softwareupdate -l 2>&1 | grep -q "No new software available." && echo "0" || echo "1"

Originally created by @phaninder-scalefusion on GitHub. ### Summary The `system_settings_softwareupdate_current` rule uses `LastFullSuccessfulDate` to determine if the device is up-to-date. This is unreliable because the value changes even when running `softwareupdate -l`, without confirming update status. ### Steps to reproduce 1. Run the compliance script that checks `LastFullSuccessfulDate`. 2. Run `softwareupdate -l`. 3. Notice that the compliance check reports the device as up-to-date even when updates are pending. ### Operating System version (macOS 13 / 14 / 15 – reproducible across builds) ### Intel or Apple Silicon Both ### Current behavior Reports device as compliant when updates are still available. ### Expected behavior Compliance should only report `up-to-date` when no new software updates are available. ### Relevant logs ``` defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist LastFullSuccessfulDate # Shows a recent date even though updates are pending ``` ### Possible fixes `softwareupdate -l 2>&1 | grep -q "No new software available." && echo "0" || echo "1" `
michael commented 2026-01-19 18:28:59 +00:00
Author
Owner
Copy Link

@brodjieski commented on GitHub:

The suggested fix may not correctly report the status if a system is running macOS Sonoma or Sequoia and is offered macOS Tahoe. I think the intent of this rule is to make sure that there are no security updates available for the currently running OS.

That being said, the current way the check is written is flawed (as you discovered), so we may need a new approach.

Another suggestion would be to parse the output of:

/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates

and make sure there are no available updates that contain _minor in the identifier or product key.

Maybe we do

/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates | grep -c "_minor"

and ensure the result is not greater than 0?

Curious your thoughts on this approach.

@brodjieski commented on GitHub: The suggested fix may not correctly report the status if a system is running macOS Sonoma or Sequoia and is offered macOS Tahoe. I think the intent of this rule is to make sure that there are no security updates available for the currently running OS. That being said, the current way the check is written is flawed (as you discovered), so we may need a new approach. Another suggestion would be to parse the output of: ``` /usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates ``` and make sure there are no available updates that contain `_minor` in the identifier or product key. Maybe we do ``` /usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates | grep -c "_minor" ``` and ensure the result is not greater than 0? Curious your thoughts on this approach.
michael commented 2026-01-19 18:28:59 +00:00
Author
Owner
Copy Link

@rs1278 commented on GitHub:

Adding my $0.02 FWIF

The approach of
/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates | grep -c "_minor"
seems valid.
Returning 0 as compliant.
Returning nonzero as a finding.

Apple has planned to remove the softwareupdate binary from macOS 27, so softwareupdate -l 2>&1 | grep -q "No new software available." && echo "0" || echo "1" will be deprecated.

@rs1278 commented on GitHub: Adding my $0.02 FWIF The approach of `/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist RecommendedUpdates | grep -c "_minor"` seems valid. Returning 0 as compliant. Returning nonzero as a finding. Apple has planned to remove the softwareupdate binary from macOS 27, so `softwareupdate -l 2>&1 | grep -q "No new software available." && echo "0" || echo "1"` will be deprecated.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#31
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?