GitLab 19.0, released May 21, 2026, ships two capabilities that address problems sitting near the top of most European DevOps teams’ security backlogs: a native Secrets Manager that stops long-lived credentials from appearing as plain-text pipeline environment variables, and an expanded AI-powered Developer Flow that handles more of the friction in the review and merge process without pulling engineers out of their primary workflow.
GitLab Secrets Manager: job-scoped credentials by design
The most structurally important addition in 19.0 is the built-in Secrets Manager, now in public beta for Premium and Ultimate subscribers. Its central design decision is that secrets are scoped per CI/CD job by default, using the same group and project RBAC controls and audit logging already applied to code access and pipeline configuration.
In most CI/CD environments today, secrets enter pipelines as environment variables set at the project or group level. Any job in any pipeline that references those variables can read them for the duration of the run, and depending on how the pipeline is structured, credentials intended for a deployment step can be inadvertently accessible to earlier build or test steps. When a supply chain attack compromises a build dependency, that over-scoped access is precisely what allows the attacker’s payload to sweep credentials from the environment. The Miasma npm supply chain attack disclosed at the start of June exploited exactly this pattern, harvesting AWS, Azure, and GCP credentials from CI runners that had over-privileged secrets in their environment.
GitLab’s Secrets Manager addresses this by treating each secret as a resource with its own access policy, restricting which jobs within which pipeline stages can retrieve each credential, and recording every retrieval in the audit log. It integrates alongside existing connections to HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager, so organisations already using a dedicated secrets management system can adopt it incrementally.
For European organisations subject to NIS2, the job-scoped design also produces an audit trail that directly addresses the supply chain security requirements in Article 21 of the directive, which requires essential and important entities to document and manage security risks in their software supply chains.
Developer Flow across the full merge request lifecycle
GitLab 19.0 extends Developer Flow, the platform’s AI-assisted coding agent, to handle the full merge request lifecycle rather than just initial code generation. Two new beta capabilities are included.
The first is a “Resolve with Duo” button that appears on reviewer comments. When a developer clicks it, Duo evaluates both the comment and the current branch, proposes a specific code change, commits it, and leaves a summary for the next reviewer to evaluate. The goal is to reduce the back-and-forth that currently makes reviewer-feedback cycles the main bottleneck in most teams’ deployment frequency, without removing human judgement from the loop.
The second is one-click rebase-and-merge for teams using semi-linear or fast-forward merge methods. Conflict resolution, rebasing, and the final merge step are handled automatically through a single button press, with the AI performing the analysis and conflict resolution steps before prompting the developer to confirm.
Both capabilities read project-specific standards from an AGENTS.md file before committing, meaning the AI operates within documented coding conventions rather than applying generic patterns to a codebase it has no context for.
Self-hosted model support and expanded dependency scanning
GitLab 19.0 also extends support for self-hosted open source models within the Duo Agent Platform. European organisations with strict data residency requirements, or those subject to sector-specific regulations that restrict the use of third-party AI services, can now run the full Developer Flow and AI Assistance toolset against models they host and control themselves.
Dependency scanning in 19.0 gains full transitive dependency chain coverage for Maven, Gradle, and Python packages. Previous versions scanned direct dependencies; this update traces the full tree. Most supply chain vulnerabilities appear in transitive dependencies rather than packages a team explicitly chose, and most CI security scanning was blind to them. Covering the full tree closes a gap that has contributed to several significant incidents this year.
What this means for European engineering teams
GitLab is the platform of choice for a significant share of European enterprise and public sector DevOps environments, particularly in DACH, Benelux, and the Nordics, where self-managed deployment on private infrastructure is a common procurement requirement. The combination of job-scoped secrets and self-hosted AI model support in 19.0 addresses both security and data governance requirements without introducing a cloud or managed service dependency.
The practical improvement in compliance posture between GitLab 18.x and 19.0 is meaningful. CI/CD credential exposure was the entry point in several supply chain incidents this year, including the Quasar QLNX campaign in late May and Miasma in early June. GitLab Secrets Manager, even in public beta, is worth evaluating now rather than waiting for general availability. The audit trail alone has value for NIS2 reporting obligations.
If you want help assessing your current CI/CD credential exposure, evaluating GitLab 19.0 for your team, or designing a secrets management architecture that aligns with NIS2 supply chain security requirements, contact Excello Digital. We help European engineering teams build pipelines where credential exposure is a contained and auditable risk.