Bitbucket Pipelines keeps artifacts for up to 14 days, each up to 1 GB. Shared artifacts are available to later steps, and scoped artifacts cannot be downloaded across steps. Treat artifacts as short lived working files. For anything an auditor or a later investigation needs, copy it to storage you control.
What the documentation says
Artifacts are files a step produces that you can share or export once defined in the pipeline configuration. There are three types. Shared artifacts are accessible across multiple steps. Scoped artifacts suit logs, test reports, screenshots or videos and cannot be downloaded across steps. Test report artifacts are XML and confined to a single step.
| Type | Crosses steps | Typical content |
|---|---|---|
| Shared | Yes | Build output for the next step |
| Scoped | No | Logs, reports, screenshots |
| Test report | No | XML test results |
Defaults that matter for security
By default a step downloads all artifacts from earlier steps. A step can set download: false to skip them, or list the specific names it needs. That default means a poisoned file from an early step reaches every later step, including deploy. Files must sit inside the clone directory when the step ends. Downloaded files get default permissions of 644, so scripts need chmod +x.
Steps to tighten them
- Set
download: falseon steps that do not need earlier output, and list names on those that do. - Use
ignore-pathsor narrow patterns so you do not sweep up configuration files,.envfiles or credentials. - Choose scoped artifacts for reports so they do not flow into later steps.
- Build once and deploy the same output. See build once, promote the same artifact.
- For long retention, send files to external storage such as an object store or artifact repository. The page names AWS S3, JFrog Artifactory and Google Cloud Storage, and passes credentials through environment variables, not in the file.
- Record a hash of the final deploy artifact in a place the pipeline cannot rewrite. See build artifact integrity verification.
- step:
name: Deploy
artifacts:
download: false
script:
- ./fetch-signed-release.sh
The script name is a placeholder.
Evidence after 14 days
Auditors often ask for scan results from months ago, and a 14 day window will not cover that. Keep dated scan outputs and approval records in a retained location. The post on CI pipeline output as audit evidence explains what counts.
Common mistakes
A frequent one is publishing a whole build directory as an artifact because it is easy, then finding configuration files or local credentials inside it. Another is assuming a later step will see a fresh checkout when it actually receives earlier artifacts by default. Check what a step really downloads by reading its log, and trim both what you upload and what you accept.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are tracked over time rather than inside a single run.
Safeguard's compliance and evidence automation keeps results beyond one pipeline run, and you can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can a later step read a scoped artifact?
No. Scoped artifacts cannot be downloaded across steps.
Does Bitbucket say who can browse artifacts in the UI?
The page we read does not say. Check your own workspace permissions.
Sources
- Atlassian: Use artifacts in steps, fetched 19 October 2026.
Last reviewed: 19 October 2026.
