This post explores how custom AutoPkg processors are potentially vulnerable when used as pre/post-processors. While one of AutoPkg’s main advantages is its secure by default design, there is a gap when dealing with custom processors used as command line arguments.

Today I’m introducing VirusTotalReporter, an AutoPkg processor designed to return file report information from VirusTotal. Heavily inspired by the well loved and widely used VirusTotalAnalyzer by Hannes Juutilainen, VirusTotalReporter’s goal is to provide as much detection data as possible to make informed decisions within AutoPkg recipes and workflows.

Starting in macOS 13.4, there is no longer a way for Mac admins to programmatically manage beta program enrollments. During the 13.4 beta cycle it was announced seedutil is deprecated, to be removed entirely in a future release, and the only path forward to enroll in beta programs being Apple IDs.

In the past, when working with static Mac hardware, I would add secrets to recipe overrides and keep them only locally on the Mac used to run AutoPkg. While still mostly insecure, at least those secrets weren’t also available in a code repo, and less prone to being compromised. With ephemeral CI runs though, this isn’t possible. A secret store which can be referenced at runtime, outside of the repo becomes necessary. Thankfully my colleagues at Gusto had encountered this before and already had a solution to avoid committing plain text secrets.

Troubleshooting technology issues this past year has been especially challenging due to the distance coronavirus has forced upon us. Getting good data to help our users has been more difficult when it’s not possible to be in front of their computer. Mac admins who have worked with Apple support or filed feedback know the very first data point usually requested is a sysdiagnose. No logs, no help. A sysdiagnose contains a voluminous amount of log files which can help pinpoint exactly what’s gone wrong with a Mac.