# Review GitLab Secure Files access and logging before storing signing material

> Secure Files encrypts stored files, but job output and project access still need explicit review.

- Canonical URL: https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:46+00:00
- Modified: 2026-10-15T13:36:17+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Secure Files encrypts stored files, but job output and project access still need explicit review.

## Potentially affected

This applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.

## DSE recommendation

DSE recommends treating storage protection, job exposure, and audit evidence as separate requirements.

## Article

Secure Files encrypts stored files, but job output and project access still need explicit review.

## Source facts

GitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.

Source: [GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/).

## Applicability

This applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.

## DSE recommendation

DSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.

## Verification

Use a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.

## Official reference

[GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/). Reviewed October 15, 2026.

## Primary reference

- Name: GitLab — Secure Files
- Authority: docs.gitlab.com
- URL: https://docs.gitlab.com/ci/secure_files/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Review GitLab Secure Files access and logging before storing signing material,” DSE Security, https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.