Common mistakes are assuming a valid signature means a file is safe, or assuming an unsigned file is always malicious. Code signing shows origin and integrity, not intent. Defenders should check notarisation, certificate trust, bundle changes, and whether a signed component is being loaded or run from an unusual location. Signed malware and abused certificates both occur.
Why macOS code signing mistakes happen in practice
code signing on macOS is often misunderstood as a trust verdict rather than a provenance check. The common failure is treating the presence of a signature as proof that a file is harmless, while ignoring notarisation status, certificate trust, bundle consistency, and whether the binary is being executed from an unexpected path or is being wrapped by another process. Those gaps matter because the platform can still run signed code that is unwanted or abused.
A second mistake is focusing only on the top-level app bundle. On macOS, the trust question is usually about the whole execution chain: nested helpers, scripts, plug-ins, launch agents, and post-download modifications can all change the real risk picture. A file can remain signed while its behaviour becomes suspicious if the surrounding bundle has changed, the developer certificate has been abused, or the runtime location is inconsistent with normal deployment.
Defenders should also separate two ideas that are often conflated: whether the code came from the expected publisher, and whether the code should be allowed to run in the current context. That distinction is why code signing needs to be paired with runtime policy, reputation signals, and environment-specific controls rather than used as a standalone allow rule.
What to verify before you trust a signed macOS binary
The first check is whether the signature is intact and whether notarisation is present where you expect it. That confirms the software has not been altered since signing and that it has passed Apple’s distribution gate, but it still does not tell you the code is safe. Use it as a validation step, not a blanket endorsement.
The second check is certificate context. Certificate trust, expiry, revocation, and the reputation of the signing identity all matter, especially when a signed component is deployed at scale or used in an administrative workflow. If the certificate has been abused or the signing key has been stolen, the signature may remain technically valid while the software is still dangerous.
The third check is bundle integrity and execution path. A signed app launched from an unusual location, loaded through an unexpected helper, or modified after packaging deserves closer scrutiny. For teams building signing pipelines, NHIMG’s Code Signing Security Guide is a useful reference for key protection, timestamping, revocation, and response to stolen signing material.
How signed malware and certificate abuse change the threat model
Signed malware changes the defender’s assumptions because signature-based trust does not prevent malicious intent. Attackers value valid signatures because they help code blend in, reduce user suspicion, and sometimes bypass weaker policy checks that were designed around unsigned or obviously suspicious files. That is why a signed binary can still be the right thing to investigate.
Stolen or abused certificates create a different problem: the software may look legitimate to both users and controls even after the publisher has lost control of the signing material. In that situation, the issue is not just the file itself, but the trust relationship behind it. Related cases often force organisations to rotate signing keys, revoke certificates, and review every release channel that depended on the compromised material. NHIMG’s Cryptographic Key Management Guide is the right companion when the question becomes how to protect, rotate, and inventory signing keys.
macOS environments also need to consider the broader software supply chain. A signed application can still be problematic if the build pipeline, release process, or update path was compromised before signing occurred. For that reason, the trust decision should include the provenance of the build, not only the certificate attached to the final artifact. The Machine Identity, PKI and Certificate Lifecycle Guide is relevant when teams want to understand certificate lifecycle discipline beyond a single app-signing event.
What good macOS code-signing practice looks like
Good practice is to treat signing as one control in a larger verification chain. That means checking signature validity, notarisation, and certificate trust, but also comparing the bundle against the expected release, watching for new helpers or loaders, and confirming the binary’s execution path matches how the software is normally deployed.
It also means having an incident path for signing abuse. If a signed application is behaving unexpectedly, assume the issue may be compromise, repackaging, or certificate misuse until proven otherwise. In that case, preserve evidence, review related update channels, and decide quickly whether certificate revocation, re-signing, or forced replacement is required. Teams that manage signing in CI/CD should also keep a clear inventory of which signing identities are used where, because certificate sprawl makes abuse harder to contain.
GitHub code signing certificate theft 2022 and AnyDesk breach 2024 both illustrate why certificate control and revocation readiness matter when signing material is exposed.
Risk and Threat Considerations
Code signing creates a trust signal that attackers actively try to abuse. The main risks are over-trusting signed files, under-checking bundle changes, and failing to notice when a valid certificate has been stolen or misused. Those failures can let malicious code run with a legitimacy veneer that slows detection.
Failure mechanism: Defenders treat signature validity as proof of safety, or they miss that a trusted certificate, a repackaged bundle, or an unusual execution location has changed the effective risk.
Impact: Malicious or repurposed code can reach endpoints, evade casual inspection, and persist long enough to trigger broader compromise, especially when users and allowlists rely too heavily on signing status alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Signed binaries still require software inventory and release-path validation. |
| Recommendation — Track approved macOS software and investigate signed binaries that appear outside the expected inventory. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Code signing is an integrity control, and the question is about misreading that signal. |
| IA-5 — Authenticator Management | Stolen signing keys and certificate misuse turn key lifecycle into the core trust issue. | |
| Recommendation — Validate software integrity signals before allowing execution or distribution. Protect, rotate, and revoke signing credentials and certificates on a defined lifecycle. | ||
| NIST SP 800-57 | Key Management Lifecycle | The question materially involves protecting and rotating signing keys after compromise. |
| Recommendation — Apply key lifecycle controls to code-signing keys, including rotation, revocation, and destruction after compromise. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen code-signing keys and certificates are identity-bearing secrets that can be abused. |
| Recommendation — Reduce exposure of signing keys and monitor for leakage in build and release paths. | ||
Practitioner Guidance
What to verify: Verify signature integrity, notarisation, certificate trust, bundle consistency, and the actual execution path before deciding a signed macOS file is low risk. If any one of those signals is inconsistent, treat the item as suspicious and inspect the release chain rather than the binary in isolation.
Common mistake: The most common error is using code signing as a binary yes-or-no safety verdict. That mindset misses abused certificates, repackaged bundles, and signed payloads that are legitimate in origin but hostile in purpose.
Practitioner takeaway: Code signing should increase confidence in origin and integrity, not replace behavioural, provenance, and deployment-context checks. The safest operational stance is to trust the signature as evidence, then verify the release, the certificate, and the runtime context before you trust the code.