Package Installer (PKG)

What a PKG installer package is

A macOS PKG is a structured installer bundle that can place applications, resources, and scripts on a system in a controlled installation flow. Because it is designed to execute install-time actions, it is treated as a software trust object, not just a file container.

The key security idea is that a PKG can do more than copy files. It may run pre-install and post-install logic, change system state, write into privileged locations, and stage components for later execution. That means the package itself becomes part of the trusted build and delivery path.

Why package provenance matters

Package provenance tells you where the installer came from, who built it, and whether it has been altered in transit or after signing. For deployment teams, the issue is not only whether the payload is useful, but whether the package can be trusted to install exactly what was approved.

Signed packages reduce ambiguity, but signing alone does not make a package safe if the build process, distribution channel, or embedded scripts are compromised. A trustworthy installer also depends on controlled publishing, reproducible build practices where possible, and verification that the package matches the expected source.

How PKG files affect installation trust

PKG installers sit at a high-trust point in the macOS software lifecycle because they are expected to make changes during installation. That makes them attractive for legitimate automation, but also for abuse when a malicious package is allowed to execute with user or administrative context.

The trust problem is amplified when installers bundle post-install scripts, helper tools, launch items, or configuration changes. Those actions can create persistence, alter security settings, or introduce additional components that users do not notice during the initial install.

Common security checks for PKG packages

Security review usually starts with the package source, the signer identity, and whether the package was distributed through a channel the organisation recognises. Teams also inspect whether the installer’s contents and scripts align with what the software is supposed to do, especially when the package is used for enterprise deployment.

• Confirm the package origin before installation.
• Check signing, notarization, and release channel consistency.
• Review embedded scripts and post-install behaviour.
• Prefer package handling through trusted software distribution processes such as OpenSSF-aligned supply chain practices when the package is part of a broader software delivery pipeline.
• Use established security controls for software integrity and installation trust, including NIST SP 800-53 Rev 5 Security and Privacy Controls and the SLSA supply-chain model where build provenance matters.

Risk and Threat Considerations

PKG files can be abused when users or administrators trust a package because it looks like a normal installer. The main risk is that malicious or tampered packages can deliver scripts, payloads, or persistence mechanisms at install time, before endpoint defenses have much chance to intervene.

Failure mechanism: An attacker gets a harmful package signed, repackaged, or delivered through a trusted-looking channel, then uses the installer’s legitimate execution path to run unwanted code or place malicious components on the host.

Impact: The result can be code execution, persistence, configuration tampering, or the installation of software that weakens endpoint security and expands the attacker’s access.

Practitioner Guidance

What to watch for: Treat PKG review as part of software trust validation, not just file scanning. Packages that include scripts, unusual install paths, or unexpected privileged changes deserve extra scrutiny because those are the places where installer abuse usually hides.

Governance implication: Organisations should make package provenance, signing verification, and approved distribution channels explicit requirements for deployment teams. If a PKG is allowed into production without those checks, the installer itself becomes an uncontrolled change mechanism.

Related resources from NHI Mgmt Group

• What breaks when package governance does not use the same identity model as the installer?
• What breaks when a package installer is allowed to run shell commands during installation?
• How do security teams know if a package installer is crossing the boundary into identity harvesting?
• What breaks when an expired cloud storage bucket is still referenced by an open source package installer?