Full Report
Security advice for users and maintainers to help reduce the impact of the next supply chain malware attack. The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.
Analysis Summary
# Best Practices: Supply Chain Security Against Malware Campaigns
## Overview
These practices are derived from lessons learned from coordinated supply chain attacks (like the Shai-Hulud campaigns) focusing on compromising maintainer workflows, exploiting credential trust boundaries, and leveraging malicious install-time execution scripts. The goal is to provide durable, proactive hardening steps for users and maintainers to reduce the impact of future, rapidly iterating malware campaigns.
## Key Recommendations
### Immediate Actions
1. **Audit and Rotate High-Privilege Credentials:** Immediately review and rotate all secrets, tokens (e.g., npm tokens, CI/CD tokens, cloud provider credentials), especially those stored in maintainer accounts or CI/CD environments, focusing on tokens with publication or destructive capabilities.
2. **Review Lifecycle Script Injection Points:** Scrutinize all package `postinstall` scripts and other lifecycle hooks for unexpected external calls or obfuscated logic. Temporarily disable or heavily restrict execution of unknown or unnecessary lifecycle scripts until vetted.
3. **Verify Source Code vs. Published Artifacts:** For critical dependencies, manually compare the code retrieved from the repository (source) against the package downloaded from the registry (published artifact) to detect differences caused by build-time transformations or injected code.
### Short-term Improvements (1-3 months)
1. **Implement Least Privilege for CI/CD:** Configure CI/CD runners and deployment systems to use Workload Identity Federation or OpenID Connect (OIDC) tokens instead of long-lived, static secrets for authenticating to cloud providers or registries.
2. **Mandate Granular Permission Scoping:** Reduce the scope of all required automation tokens (e.g., repository access tokens, publishing tokens) to only the minimum necessary permissions (e.g., publish to specific repository, not global access).
3. **Adopt Artifact Signing:** Implement digital signing for all published artifacts (packages, container images) to cryptographically verify the integrity and origin of supplied code before deployment or installation.
4. **Enable Automated Dependency Review:** Integrate security scanning tools that automatically vet incoming dependency pull requests for suspicious patterns, especially around dependency changes and lifecycle scripts.
### Long-term Strategy (3+ months)
1. **Fully Migrate to Trusted Publishing (OIDC):** Implement OIDC workflows to eliminate the use of static, long-lived publish tokens entirely, ensuring that publishing credentials are ephemeral and scoped only to the verified source branch/commit.
2. **Enforce Staged Approvals for Publication:** Establish a mandatory review process where published artifacts must pass automated checks and manual approval (e.g., a secondary maintainer) before being released to the main registry endpoint.
3. **Develop Comprehensive Credential Rotation Strategy:** Standardize automated processes for regularly rotating all active secrets and OIDC provider configurations across all development, testing, and production environments.
4. **Isolate Build Environments:** Use ephemeral, ephemeral, and isolated build agents for CI/CD pipelines, ensuring agents lack persistent access to secrets or command-and-control infrastructure needed for malicious self-replication or privilege escalation.
## Implementation Guidance
### For Small Organizations
* **Focus on Credentials:** Prioritize migrating from static secrets to short-lived environment variables or secret management services for registry access.
* **Use Trusted Tools:** Rely on the default security features provided by managed GitHub repositories (e.g., default branch protection, Dependabot) as a baseline defense.
* **Manual Vetting:** For critical direct dependencies, conduct periodic manual source code reviews alongside installation.
### For Medium Organizations
* **Pilot OIDC Adoption:** Begin migrating core CI/CD publishing workflows to OIDC, focusing initially on the most frequently updated or public-facing packages.
* **Implement Artifact Validation Gates:** Integrate pre-deployment checks within the pipeline that enforce artifact signature verification before deployment proceeds.
* **Establish Incident Playbooks:** Formalize specific procedures for responding to credential compromise alerts related to package publishing or dependency management systems.
### For Large Enterprises
* **Scale OIDC Onboarding:** Utilize tooling (e.g., bulk OIDC onboarding tooling) to migrate hundreds of packages to trusted publishing workflows systematically across product lines.
* **Enhance CI Environment Hardening:** Implement strict containerization and sandboxing for all build agents, explicitly limiting network egress and filesystem access to prevent lateral movement or unauthorized endpoint C2 registration.
* **Centralized Secret Sprawl Reduction:** Conduct a comprehensive audit to identify and consolidate all hardcoded or non-rotated secrets currently used for build/publish processes, decommissioning legacy static tokens.
## Configuration Examples
*Note: Specific technical configuration snippets were not provided in the source text, but the required actions point to the following technical implementation areas:*
* **OIDC Configuration:** Set up provider definitions in CI/CD systems (e.g., GitHub Actions, GitLab CI) that map specific job identities directly to ephemeral cloud/registry access tokens without storing static secrets.
* **Package Manifest Scrutiny:** Configure package manager configuration (e.g., `.npmrc`) to enforce stricter authentication methods and review any custom configuration files that might override default security behaviors.
## Compliance Alignment
These practices directly support requirements across modern security frameworks focusing on Software Supply Chain Security (SSCS):
* **SLSA Framework (Supply-chain Levels for Software Artifacts):** Implementing signing, provenance generation, and isolated builds aligns with achieving higher SLSA maturity levels.
* **NIST SP 800-218 (Secure Software Development Framework - SSDF):** Focuses on protecting the integrity of the development, build, and deployment environments.
* **ISO/IEC 27034 (Application Security):** Specifically addresses validation and verification throughout the SDLC, including integrity verification of components.
## Common Pitfalls to Avoid
1. **Reactive Mitigation:** Basing security efforts solely on mitigating the specific techniques seen in the *last* attack (e.g., only patching one specific post-install script vulnerability) rather than hardening the underlying *trust and execution boundaries*.
2. **Ignoring CI Environments:** Assuming that CI environments are inherently secure. Adversaries specifically target build agents for privilege escalation and credential harvesting to fuel replication.
3. **Credential Reuse:** Using the same high-privilege credentials across multiple repositories, platforms, or lifecycle stages, increasing the blast radius of any single compromise.
4. **Blind Trust in Updates:** Automatically accepting package updates based only on version number increments, failing to inspect content differences between the source repository and the published package payload.
## Resources
* **OpenSSF Artifact Signing Documentation:** Guidance on implementing strong cryptographic signing for packages. (Search terms: OpenSSF artifact signing)
* **npm Package Manager Best Practices:** Official guidelines for securing package maintenance workflows. (Reference: OSSF Package Manager Best Practices - npm documentation)
* **Microsoft's Shai-Hulud Detection Guidance:** Detailed indicators of compromise and investigation steps related to recent attacks. (Reference: Microsoft Security Blog guidance on Shai-Hulud 2.0)
* **GitHub Actions Security Updates:** Information regarding changes to runner capabilities and environment protections relevant to supply chain security. (Reference: Recent changes to GitHub Actions Changelog)