Incident Overview
OpenAI is rotating all of its macOS code-signing certificates and will fully revoke them on May 8, 2026, following a supply chain attack involving a malicious version of the Axios package. This attack targeted the open-source HTTP client library used in OpenAI's code-signing workflow. Although OpenAI confirmed that neither user data nor the certificates themselves were compromised, the company is treating this as a potential exposure requiring full certificate rotation.
The malicious Axios package was version 1.14.1, linked to North Korean threat actors tracked as UNC1069. OpenAI engaged a third-party security firm to investigate the incident and determine the scope of exposure.
Timeline of Events
While the exact timeline of the compromise has not been publicly disclosed, key dates include:
- Discovery: Detection of the malicious package in the code-signing workflow.
- Response: Immediate engagement of a third-party incident response firm.
- Certificate Rotation: Initiated following investigation.
- Full Revocation: Scheduled for May 8, 2026.
Developers using OpenAI's signed macOS applications have over a year to transition to new certificates, necessitating immediate planning.
Control Failures and Gaps
This incident highlights several control gaps that allowed a supply chain attack to reach production infrastructure:
1. Dependency Verification
The malicious Axios package entered the build pipeline undetected, indicating missing or inadequate controls for verifying package integrity. Your team should check package hashes against known-good values and use lock files to prevent unexpected version changes.
2. Isolated Build Environments
If your code-signing workflow shares dependencies with other parts of your infrastructure, a compromise in one area can expose sensitive operations. Code-signing should occur in a hardened, isolated environment with minimal dependencies.
3. Certificate Access Controls
While the certificates weren't stolen, a compromised package interacting with the signing workflow indicates insufficient segmentation. Store certificate private keys in hardware security modules (HSMs) or cloud key management services with strict access policies.
4. Supply Chain Monitoring
Automated monitoring did not detect the package compromise before OpenAI's internal investigation. Implement tooling that alerts on unexpected package changes, new maintainers, or suspicious package behavior.
Relevant Standards
Several standards address controls that could have prevented or limited this incident:
NIST 800-53 Rev 5
- SR-3 (Supply Chain Controls and Processes): Requires provenance records and integrity verification for supply chain elements.
- SR-4 (Provenance): Mandates documenting and monitoring the provenance of system components.
- SR-11 (Component Authenticity): Requires anti-counterfeit measures and detection of counterfeit components.
- Control 8.30 (Outsourcing): Addresses risks associated with outsourced development and external code.
- Control 8.31 (Separation of Development, Test, and Production Environments): Ensures code-signing infrastructure is isolated from general development environments.
NIST Cybersecurity Framework (CSF) v2.0
- ID.SC-01: Identifies and prioritizes suppliers and third-party partners.
- ID.SC-02: Identifies and documents software components within products and services.
Actionable Steps for Your Team
OpenAI's response demonstrates effective incident handling: immediate rotation despite no confirmed compromise, third-party investigation, and transparent communication. Implement the following:
Immediate Actions:
Audit Code-Signing Workflow Dependencies: List every package, library, and tool accessing your signing infrastructure. Document versions and maintainers.
Implement Package Hash Verification: Use lock files and verify hashes before installation. Configure your CI/CD to fail on hash mismatches.
Isolate Signing Operations: Move code-signing to a dedicated environment with minimal dependencies. Avoid signing on developer machines.
Store Certificates in HSMs or Cloud KMS: Use services like AWS CloudHSM, Azure Key Vault, or Google Cloud KMS for API-based signing without exposing private keys.
Within 30 Days:
Deploy Dependency Monitoring: Use tools like Dependabot, Snyk, or Socket to alert on new package versions, maintainer changes, and suspicious behavior.
Establish Certificate Rotation Procedures: Plan and test your certificate rotation process, including user notifications and transition timelines.
Review Your Incident Response Plan: Ensure you have a retainer or relationship with an incident response provider and can investigate supply chain compromises.
Within 90 Days:
Implement Software Bill of Materials (SBOM) Generation: Use tools like Syft or CycloneDX to generate SBOMs for your builds.
Require Multi-Party Approval for Signing Operations: Implement approval workflows requiring human verification.
Conduct a Supply Chain Risk Assessment: Map every external dependency in your critical workflows and prioritize based on access to sensitive operations.
The Axios compromise illustrates that even well-maintained open-source projects can be targeted by sophisticated threat actors. Your defense strategy should focus on verifying dependencies, isolating them, and having a plan for when they fail.
