One vulnerability view: From scanner coverage to AI governance

Most enterprises use a handful of different security scanners, each configured and enforced, project by project. With no single view of what scanners run where, policies drift, blind spots go undetected, and important projects could silently go unprotected. With GitLab 19.1, you can now integrate the security scanners you already use, giving a single view of your scanner coverage. GitLab enforces third-party scanners at scale across all of your projects, and the vulnerabilities they detect get remediated automatically. On the governance side, we're launching the beta of AI audit event streaming, so you can see whether your agents are acting safely.

Enforce third-party scanners on every project at scale

For most security teams, the hardest part of application security is scanner coverage. Different scanners are set up project by project, so whether a scanner runs depends on individual teams setting it up. New projects can go unnoticed and can ship for weeks before teams realize they are not scanned. When coverage depends on tribal knowledge rather than policy, code ships unscanned, vulnerabilities ship to production, and audits expose gaps.

You can now enforce third-party scanners at scale across all of your GitLab projects. Any scanner that outputs SARIF runs under your policies, and the vulnerabilities identified flow into GitLab natively. Every finding lands in one vulnerability view governed by the same rules, so coverage becomes something you can prove rather than hope for.

From there, third-party scanner findings run through the same GitLab Duo Agent Platform auto-remediation workflow as GitLab native scanner findings. SAST False Positive Detection triages findings to prioritize those with real risk, and Agentic SAST Vulnerability Resolution opens a ready-to-merge fix to automatically remediate findings before they go into production. Your team gets coverage it can prove with one governed view across every scanner, and automated remediation for third-party findings.

Catch secrets earlier, and spend less time on false positives

Secret detection runs in your pipelines to catch leaked credentials, but teams have historically struggled with two things: missed secrets and noisy findings. On a new branch, only the latest commit gets scanned, so a secret committed earlier might ship unnoticed. The findings detected come mixed with test credentials, placeholder values, and example tokens, so developers spend time clearing noise instead of addressing real exposures.

Secret detection now scans every commit on a new branch instead of only the latest one, and Secret False Positive Detection, now generally available, adds a confidence score and an explanation to each finding, shown in the vulnerability report. Your team catches secrets wherever they were introduced, and spends time reducing risk from real exposures rather than false positives.

Decide what your AI agents can do, and prove it

Companies have adopted AI agents for coding. Agents open merge requests, call tools, and commit code alongside the developers they work for. However, once an agent is approved for a project, it can write, delete, and push without anyone reviewing the action first. Your company remains accountable for changes in the codebase, regardless of whether an agent makes them or a developer. Enterprises need to determine what an agent is allowed to do before it acts, and to show exactly what it did after.

GitLab 19.1 closes that governance gap. With AI audit event streaming, now in beta, every action an agent takes is recorded as an audit event and streamed to your audit log destinations, with the rest of your audit trail. The release also gives you control over what agents can do on your platform. Agent tool approval guardrails, also in beta, let an administrator set each agent tool to run on its own, pause for human approval, or stay blocked, so a sensitive action like writing a file or deleting a resource waits for a team reviewer before it runs. Every approval decision is recorded as an audit event for teams to retroactively review.

The result is governed autonomy. Agents can run end to end, inside the guardrails you set, and a risky action does not reach the codebase unless a person signs off on it. When an auditor or an incident responder later asks what an agent did, the answer is already in the audit trail the team runs.

Audit trail of agent activity showing an alert flagged for an agent dismissing a high-severity finding without human approval

Governed autonomy for your agents

GitLab 19.1 puts governance around the agents in your codebase, with full security scanner coverage across every project and automatic remediation of third-party scanners. You set what each agent is allowed to do before it acts, and every action lands in your audit trail.

To see what your agents can do inside the guardrails you set, and prove what they did, start a free trial of GitLab Duo Agent Platform today.