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.

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.

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. Reviewed October 15, 2026.