Artifact Overwrite

Artifact overwrite occurs when extracted files replace existing files with the same name in a target directory. In CI/CD pipelines, this can be dangerous if the overwritten file is later executed. The risk increases when archives are unpacked into the current working directory without isolation or path controls.

How Artifact Overwrite Happens

Artifact overwrite is a file-handling failure, not a parsing bug in isolation. It occurs when extracted content lands in a directory that already contains a file with the same name, so the newer file silently replaces the older one and may alter the behaviour of later build or deployment steps.

The problem is most dangerous in CI/CD and release workflows because overwritten files are often trusted as build inputs, helper scripts, configuration, or packaged executables. If the extraction target is shared, predictable, or writable by untrusted content, the archive contents can change what the pipeline runs next.

Why It Becomes a Supply-Chain Integrity Issue

Artifact overwrite matters because the integrity of the delivered software depends on more than signature checks or repository controls. A pipeline can still be undermined if a later stage consumes a replaced file from disk, especially when the overwrite changes a script, binary, or configuration file that is executed automatically.

This is closely related to SLSA because build provenance is only useful when the build environment preserves the intended inputs and outputs. If extraction can overwrite existing artifacts, provenance evidence may no longer match the file that actually ran.

It also connects to OWASP API Security Top 10 in the broader sense that downstream automation often trusts inputs it should validate, even when the immediate issue is file-system behaviour rather than an API flaw.

Common Failure Conditions in Pipelines

The usual failure pattern is predictable: archives are unpacked into the current working directory, filenames are reused across steps, and extraction happens without isolation, allowlisting, or collision handling. In that setup, an attacker or a malformed package does not need advanced execution rights, only the ability to introduce a conflicting filename into the extraction flow.

Overwrites become more severe when build jobs share workspaces, cache directories, or release folders. A single replacement can influence later compile, test, packaging, or deployment stages, and the effect may be hard to notice if the pipeline only checks that extraction completed successfully.

That is why archive handling belongs in the same control conversation as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially configuration management, integrity, and controlled system change.

Safe Handling and Practitioner Guidance

Why practitioners should care: Artifact overwrite is usually a pipeline-design problem, so the right fix is structural rather than reactive. The goal is to make filename collisions impossible or harmless before untrusted content ever reaches an execution path.

Use isolated extraction directories, reject unexpected path relationships, and verify that unpacked files cannot replace existing build assets. Treat archive content as untrusted input even when it came from a known repository, because the danger is often in how the pipeline stages and reuses files, not only in the source that supplied them.

For software delivery controls, OWASP SAMM is useful because it frames secure build and release practices as a repeatable engineering discipline, not a one-off hardening task.

When teams need a practical reference for hardening the execution environment around these workflows, CIS Benchmarks provide system-hardening guidance that can reduce the blast radius of a bad extraction choice.

Risk and Threat Considerations

Artifact overwrite creates integrity risk because a benign-looking archive operation can become a code substitution event. In CI/CD environments, that can redirect later execution to attacker-controlled content or to a stale file that was never meant to run.

Failure mechanism: A crafted archive, reused filename, or shared workspace causes a file to overwrite a trusted artifact, and the pipeline later executes or packages the replaced file as if it were legitimate.

Impact: The result can be build compromise, poisoned release output, unexpected code execution, or silent corruption of software delivered to downstream users.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.