Circleci Build Artifacts
To save circleci build artifacts, you define a storage step in your pipeline job file. This step tells the runner to upload chosen files to object storage after the job finishes. Engineering teams use these stored files to save test reports, logs, and compiled app packages. Still, broad role permissions on build runners can expose sensitive data inside those saved files. Anyone who can read the project can download those files later. How circleci build artifacts work in your pipeline Every pi
CircleCI Security + Build Provenance (SLSA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To save circleci build artifacts, you define a storage step in your pipeline job file. This step tells the runner to upload chosen files to object storage after the job finishes. Engineering teams use these stored files to save test reports, logs, and compiled app packages. Still, broad role permissions on build runners can expose sensitive data inside those saved files. Anyone who can read the project can download those files later.
How circleci build artifacts work in your pipeline
Every pipeline run starts in a clean container or virtual machine. Your job pulls code, installs tools, and runs tests or build commands. When the job ends, the runner deletes the workspace and all local files. If you want to keep binary files or test logs, you must store them first.
You add an upload step at the end of your job workflow. In that step, you give a local folder path or file path to the runner. The runner compresses the files and sends them to cloud storage over a secure link. You can also set a destination prefix to group files by type or job name.
Once the upload finishes, team members can view and download the files in the web app. Teams also fetch these files through the platform API using a personal or project token. Workspace persistence is different because it only passes files between jobs in one single workflow. Stored artifacts stay available for weeks so engineers can check failed runs or grab build packages.
What native storage solves and where gaps remain
Native artifact storage solves the problem of lost build outputs and test summaries. Developers do not need to set up their own cloud buckets or write custom upload scripts. When a browser test fails, the runner saves screenshots and logs for quick review. This helps teams fix broken builds without running the whole test suite on a local machine.
Yet this native workflow leaves a clear security and operational gap during the job run. Pipeline roles decide who can trigger a build or download saved files after the run. They do not control what individual commands or database queries do while the job runs. If a build script queries a database to generate a report, it pulls raw data.
CircleCI Security + Build Provenance (SLSA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
That raw data often lands in debug logs, dump files, or test outputs on the runner. The upload step then sweeps those files into circleci build artifacts storage. Soon, plain emails, phone numbers, or card numbers sit in shared build files. Long-lived database keys stored in project variables also let any job run broad queries without checks.
Keeping sensitive data out of stored build files
To reduce risk, teams must limit what data enters the build container in the first place. Start by splitting build jobs from jobs that touch live databases or internal systems. Use narrow roles for each job instead of sharing one broad project context across every workflow. Review which folders your upload step targets so you never grab full project directories by mistake.
Teams should also check how jobs talk to backend databases and cloud services during test runs. Role settings only check who logs in at the start of a session. They do not inspect the commands sent or mask sensitive fields in query results. Adding command-level checks and field masking rewrites emails or card numbers before files hit disk. You also get a clear log of every query that each build job ran.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How are circleci build artifacts different from workspaces?
Workspaces move files from one job to the next job inside the same workflow run. Artifacts save files to long-term storage so humans or external scripts can download them after the workflow finishes.
Who can download saved files from a pipeline run?
Anyone with read permissions on the source repo can view and download the saved build files. For open-source or public projects, any user on the internet can download the stored files.
How can teams stop secrets from leaking into build outputs?
Upload only specific output folders instead of the whole working directory, and keep secrets out of debug logs. Use data masking on database queries so sensitive fields like emails or card numbers get rewritten in results.