How PowerShell Gallery simplifies attacks
Installation automation in the tool presents threat actors with one key link in the kill chain of a possible supply chain attack.
Artifact Poisoning
What is artifact poisoning?
Artifact poisoning is a type of software supply chain attack where a malicious actor modifies or injects malicious code into build outputs, such as binaries, containers, libraries, or software packages, to compromise downstream users or environments.
Why is it important?
Software artifacts are often trusted blindly once built and published. If poisoned, they can silently compromise users, introduce backdoors, or act as a vector for malware. This makes artifact poisoning a high-impact, low-visibility threat, particularly in environments relying on automated CI/CD workflows and artifact reuse.
How artifact poisoning works
Common techniques include:
- Compromising the build pipeline to inject malicious code
- Altering package contents before publishing to artifact repositories
- Hijacking third-party libraries with poisoned versions
- Replacing legitimate artifacts with trojanized copies on the wire or in storage
Attackers often exploit weak controls over build agents, repositories, or access tokens, using these to modify artifacts before they're delivered or consumed.
Prevention benefits
- Preserves Product Integrity: Ensures shipped software matches what was intended and reviewed.
- Reduces Legal and Regulatory Risk: Meets growing expectations under SBOM, EO 14028, and NIST SSDF guidelines.
- Prevents Customer Impact: Stops the propagation of malware or exploitable code to downstream environments, thereby minimizing the potential for customer impact.
- Strengthens Supply Chain Trust:Supports tamper-proof software delivery practices for both internal and external stakeholders, ensuring transparency and integrity.
Artifact Poisoning vs
Topic | Focus Area | Key Differences |
|---|---|---|
Post-Compilation Scanning | Examining binaries after build | Detects issues like artifact poisoning post-build |
Binary SBOM | List of actual binary components | Helps verify artifact integrity by comparing declared vs. observed |
Malware Detection in CI/CD | Runtime detection of malicious behavior | May detect poisoned artifacts, but is reactive |
Best practices
- Use artifact signing and hash verification across the build and deploy stages
- Secure artifact repositories with strict access controls and immutability settings
- Compare binary outputs with declared SBOM entries
- Incorporate behavioral and static analysis of final build outputs before promotion
Use cases
- Open-Source Project Distribution: Ensuring that publicly distributed binaries are free from injected code.
- Vendor Risk Management: Verifying the authenticity of artifacts from third-party suppliers.
- Secure Software Updates:Scanning OTA updates and container images for tampered content before rollout to ensure integrity.
Additional considerations
- Integrate post-compilation scanning tools into your release process
- Monitor public and private repositories for suspicious changes
- Adopt provenance metadata and secure attestations (e.g., SLSA Levels) to track artifact history
- Treat any unsigned or unverified artifact as a potential risk
