Pin every pipe to a full version number, read its public source before first use, and review changes when you raise the version. A pipe runs a script in a Docker container inside your step, with whatever variables and files that step can see. Note that 0.x versions can change behavior between small version bumps.
What a pipe is
Pipes are reusable configuration units for Bitbucket Pipelines, handy for third-party tools. Each pipe runs a script in a Docker container containing the commands you would otherwise write into your YAML, plus extras. You reference a pipe in a step's script as pipe: with an owner, a name and a version, and pass inputs under variables.
- step:
script:
- pipe: atlassian/aws-s3-deploy:0.2.2
variables:
S3_BUCKET: example-bucket
LOCAL_PATH: build
The bucket name is an example. Bitbucket's page uses this pipe and version as its sample.
The trust question
A pipe is code you run with the step's secrets nearby. The page says the provided pipes are public, so you can read the source to see how they work. It gives no specific trust guidance for third-party pipes, so apply your own checks. Pipes also need the Docker service, which counts toward the services allowed in a step.
Versions
Pipes use semantic versioning, and you choose the version by editing the number after the colon. Bitbucket notes that 0.x.y pipes are an exception: they can introduce breaking changes between minor and patch versions. A bump from one 0.x release to the next deserves a read, not a blind edit.
| Reference | Risk |
|---|---|
| Full version such as 0.2.2 | Predictable, review before changing |
| A looser tag | Content can change under you |
| Custom pipe you wrote | You own its review and its image pinning |
Steps
- List every
pipe:line across your repositories. - Use full version numbers. Do not rely on a moving tag.
- Open the pipe's source repository and read the script and the Dockerfile.
- Give each pipe only the variables it needs. A deploy pipe does not need a workspace wide token.
- Put pipes that use secrets only on branches and deployments you protect. See Bitbucket deployment environments.
- When a version changes, read the release notes and test on a branch first.
- Pin any custom pipe's base image by digest. See pinning images and tools.
The same discipline applies to reusable actions on other platforms, as in reviewing a pull request that changes CI config.
Common mistakes
The usual slip is copying a pipe snippet from a blog or an editor suggestion and never revisiting the version. Another is passing a broad token to a pipe that needs a narrow one. A third is skipping the README, which lists every variable the pipe reads. Put a recurring reminder to review pipe versions on the same schedule as dependency updates, and keep the list in one place so you can answer which pipes you use quickly.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component is listed with a version, and treat each pipe the same way.
Safeguard's dependency and SBOM scanning covers what your code pulls in, and you can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Are Atlassian pipes exempt from review?
No. Reading the public source is cheap and applies to every pipe.
Can I write my own pipe?
Yes, Bitbucket supports custom pipes. You then own its review and image pinning.
Sources
- Atlassian: What are pipes?, fetched 19 October 2026.
Last reviewed: 19 October 2026.
