gitlabAug 12, 2026

How GitLab tracks vulnerabilities through refactors and reformatting (opens in new tab)

GitLab improved vulnerability tracking to prevent duplicate findings after harmless code changes such as added comments, blank lines, or reformatting. Its normalized Scope+Offset fingerprint ignores non-functional lines while still identifying vulnerabilities by their enclosing scope and relative location. In testing, the method eliminated duplicates in a worst-case benchmark and is now available as `scope_offset_compressed`. ## The Problem with Line-Based Tracking - Vulnerabilities can appear to be new when developers: - Add comments or blank lines - Reformat files - Move functions or other code - Duplicate findings force security teams to repeat triage and reduce confidence in scan results. - GitLab’s 2022 Scope+Offset method improved on line-based tracking by using: - The narrowest enclosing scope, such as a module, class, or function - The finding’s line offset within that scope - This reduced unnecessary re-auditing by about 30%, but comments and blank lines could still change the offset. ## Normalized Scope+Offset Fingerprinting - The improved method ignores comments and blank lines when calculating a vulnerability’s fingerprint. - Because these lines do not change program behavior, they no longer change the vulnerability’s identity. - The approach preserves the previous method’s precision and reuses the scanner’s existing parse tree, so scan times are unaffected. - It does not require changes to the security report format and works with heterogeneous SAST toolchains. ## Benchmark Results - Researchers tested 439 source files across: - C/C++, C#, Go, Java, JavaScript, Python, and Ruby - They generated 2,247 commits, each adding a comment or blank line immediately before a known vulnerability. - The original method produced 1,361 duplicate fingerprints, representing a 77% increase over baseline. - The normalized method produced zero duplicates and reduced unique fingerprints by 43%. ## GitLab Availability - The algorithm is available in GitLab as: - `scope_offset_compressed` - It supports C#, C/C++, Go, Java, JavaScript, Python, Ruby, and PHP. - The accompanying research paper, *Vulnerability Tracking using Normalized Scope+Offset*, is scheduled for presentation at the ASE 2026 Industry Showcase. For teams using GitLab security scanning, `scope_offset_compressed` provides more stable vulnerability tracking without slowing scans or changing existing report integrations.

sastgitlabdevsecopsstatic-analysis+3

gitlabAug 3, 2026

Secure every commit to production with Claude and GitLab (opens in new tab)

Claude’s security tools can identify and fix vulnerabilities during coding, but they do not govern everything that happens afterward. The post argues that GitLab should secure the remaining path to production through enforced scans, approval policies, data controls, lifecycle-wide coverage, and audit evidence. Together, Claude handles in-session authoring while GitLab provides organization-wide governance. ## From In-Session Findings to Enforced Controls - GitLab applies security configuration profiles across projects and pipelines, preventing teams from bypassing required scans. - Merge request approval policies enforce separation of duties, ensuring an agent or developer cannot approve and merge its own changes. - Critical vulnerabilities can block merges until a designated approver reviews them. - Vulnerability reports and security dashboards permanently track whether findings were detected, dismissed, or resolved. ## Turning Security Activity into Audit Evidence - Compliance controls require scans to run on every merge request and expose findings for human review. - Pipeline logs, approval records, and audit events provide reproducible evidence of what was scanned and who approved each change. - Compliance frameworks such as SOC 2, PCI DSS, and FedRAMP can map evidence to named requirements. - Compliance status reports show which controls have passed, failed, or remain pending, including activity involving agents. ## Controlling Sensitive Data Sent to Models - Context exclusions prevent secrets, proprietary files, and regulated data from being sent to AI models. - Self-managed GitLab environments and self-hosted models can keep code and inference within an organization’s boundary. - Teams can select approved models, restrict model access, and prevent code from being used for training. - GitLab Duo prompt guardrails detect secrets and limit the content available to prompts, reducing prompt-injection risk. ## Scanning Beyond the Coding Session - Session-based reviews cannot detect vulnerabilities introduced after code is written, such as newly disclosed dependency flaws like Log4Shell. - GitLab provides dependency, container, infrastructure-as-code, secret, and DAST scanning across the delivery lifecycle. - Security Review Flow uses reasoning to identify business-logic flaws, authorization errors, and race conditions that deterministic scanners may miss. - Advanced SAST produces reproducible, CWE-mapped results, providing more consistent evidence than potentially variable LLM-based findings. ## Consistent Coverage for Humans and Agents - Claude’s plugin primarily reviews code written and committed within its session. - Developer shell commands, including Claude’s `!` shell escape, may fall outside that review scope. - Claude Security can review broader codebases when explicitly invoked by a developer or administrator. - GitLab pipeline scans and merge request policies apply to every change, regardless of whether it was written by a human or an agent. GitLab’s policies and lifecycle-wide scanning provide the durable controls needed after an AI coding session ends. Teams can use Claude for immediate security feedback while relying on GitLab to enforce consistent review, protect sensitive data, block unsafe releases, and maintain audit-ready evidence through production.

sastgitlabmcpinfrastructure-as-code+4

gitlabJun 18, 2026

One vulnerability view: From scanner coverage to AI governance (opens in new tab)

GitLab 19.1 presents a unified approach to application security and AI governance. It lets organizations enforce third-party SARIF-compatible scanners across every project, centralize findings, and automate remediation. At the same time, new AI governance features record agent activity and require approval for sensitive actions, enabling faster development without sacrificing accountability. ## Enforcing Complete Scanner Coverage - Security scanners are often configured separately for each project, creating coverage gaps and policy drift. - GitLab 19.1 allows administrators to enforce third-party scanners across all projects. - SARIF-compatible scanner results flow into GitLab’s unified vulnerability view. - Findings use the same governance and remediation workflows as GitLab-native results. - GitLab Duo Agent Platform can: - Triage findings with SAST False Positive Detection. - Generate merge requests through Agentic SAST Vulnerability Resolution. - Automatically remediate third-party scanner findings before production. ## Improving Secret Detection - Secret detection now scans every commit on a newly created branch, rather than only the latest commit. - This helps identify credentials introduced in earlier commits. - Secret False Positive Detection, now generally available, provides: - A confidence score for each finding. - An explanation displayed in the vulnerability report. - Developers can focus on genuine exposures instead of test credentials, placeholders, and example tokens. ## Governing AI Agent Actions - AI coding agents can create merge requests, invoke tools, commit code, and modify projects. - GitLab’s AI audit event streaming beta records every agent action and sends it to existing audit log destinations. - Agent tool approval guardrails let administrators configure each tool to: - Run automatically. - Require human approval. - Remain blocked. - Sensitive operations, such as writing files or deleting resources, can therefore require explicit review. - Approval decisions are also recorded, creating an auditable history for incident response and compliance. ## Governed Autonomy GitLab’s overall goal is to combine autonomous development with enforceable controls. Organizations can prove scanner coverage, automate vulnerability remediation, restrict risky agent behavior, and review a complete audit trail of what agents did. The practical recommendation is to centralize scanner governance and configure approval requirements for high-impact AI actions, allowing agents to work quickly while keeping security and accountability under human control.

sastgitlabdevsecopsvulnerability-management+4

gitlabMay 28, 2026

Agentic coding is only as good as its context (opens in new tab)

Coding agents are only as effective as the context they can access. Repository-only agents may produce compiling fixes, but they often miss issue requirements, CI rules, security policies, and review standards. Integrating agents with GitLab’s issues, merge requests, pipelines, and security controls produces better-aligned code, fewer review cycles, and safer releases while preserving human approval. ## From Repository Context to Full Lifecycle Context - GitLab tutorials demonstrate progressively richer workflows using Claude Code and Codex. - **Repository only:** The agent reads local files, interprets the prompt, and runs the build, but lacks acceptance criteria, organizational requirements, and review expectations. - **Repository plus issue:** Through GitLab’s MCP server, the agent can read issue descriptions, labels, milestones, and implementation notes. - It can correctly link changes to issues, such as adding `Closes #32`. - Tools such as `get_issue` and `create_merge_request` connect implementation work to planned work. - **Working inside the merge request:** GitLab’s Code Review Flow provides feedback, which the agent can address by adding tests, improving documentation, and fixing validation gaps. - New commits automatically trigger CI/CD. - Human reviewers can inspect the result in the same merge request. - The tutorials report fewer review rounds and shorter merge times. ## Why Platform Visibility Matters - Platform teams determine: - Which agents and tools are permitted - How agent output is verified - Where human approval is required - Important context lives in the DevSecOps platform: - Issues define requirements. - CI/CD configuration defines quality standards. - Review instructions establish coding conventions. - Security scanners enforce vulnerability policies. - Merge requests bring automation and human review together. - IDE- or terminal-based agents generally see only the files provided to them, while the platform sees the full lifecycle, including deployment targets and approval rules. - Consequently, the platform—not the agent alone—largely determines what can ship safely. ## Security Implications of Faster Code Generation - Agents produce code and remediation patches faster, increasing both the number of vulnerabilities and the number of security fix merge requests. - The bottleneck shifts from finding vulnerabilities to deciding which AI-generated fixes should be reviewed and approved first. - Effective prioritization requires broader context, including: - Application data flows - Deployment environments - Project-wide code - Organization-wide security policies - GitLab’s security layer can filter false positives, confirm vulnerabilities, and use surrounding repository context to propose fixes. - Agentic SAST vulnerability resolution creates a merge request with the proposed remediation. - CI/CD validates the change, while a human reviewer retains final approval. - Strong quality gates and security controls applied within merge requests reduce the chance that vulnerabilities reach production. ## Repository Instructions with `AGENTS.md` - The tutorials use `AGENTS.md` to provide project-specific instructions. - These files can describe: - Repository structure - Commands to run - Code-quality expectations - Files or areas that must not be changed - Language and framework conventions - CI image-pinning requirements - Concurrency patterns - Custom instructions help agents operate consistently with project standards, even before they receive broader platform context. Organizations should connect coding agents to the systems that define requirements, quality, security, and approval. Repository access may enable a working patch, but lifecycle context is what makes that patch trustworthy and ready to merge.

sastgitlabci-cdmodel-context-protocol+3

gitlabMay 26, 2026

Full security scanner coverage of your codebase in minutes (opens in new tab)

GitLab 19.0 introduces security configuration profiles, enabling teams to centrally apply SAST, dependency scanning, and secret detection across many projects without editing individual `.gitlab-ci.yml` files. Profiles address coverage gaps caused by organizational growth, inconsistent configuration, and rapidly increasing AI-driven development. By applying default profiles in bulk, teams can achieve broad scanner coverage within minutes. ## Why Manual Scanner Configuration Falls Short - Per-project YAML configuration becomes difficult to maintain as organizations add repositories and teams. - Scanner settings can drift between frontend, backend, and older projects. - Pipeline changes may accidentally remove security scanners. - New projects may receive scanning while existing projects remain unprotected. ## Security Configuration Profiles - Profiles are centralized group-level settings defining how and when scanners run. - Teams can apply one profile to many projects through the GitLab UI. - GitLab provides default profiles for: - Static application security testing (SAST) - Dependency scanning - Secret detection - Default profiles use recommended settings and require no manual YAML changes. ## Scan Triggers and Coverage - SAST and dependency scanning run on: - Merge request pipelines, identifying vulnerabilities introduced by the proposed changes. - Pipelines on the default branch, maintaining a complete view of its security posture. - Secret detection supports both pipeline triggers plus push protection. - Push protection detects and blocks secrets during `git push`, before they enter the repository. - Push protection is event-based and therefore does not have a scan date in the security inventory. ## Practical Security Use Cases - Security teams can select hundreds of projects from the security inventory and apply scanners in bulk. - SAST can catch insecure code patterns before a merge request is approved. - Dependency scanning can detect compromised packages before they reach production. - Secret detection can block accidentally committed API keys immediately, avoiding later remediation and credential rotation. ## Getting Started - Available on GitLab Ultimate for GitLab.com, Self-Managed, and Dedicated. - Navigate to **Secure > Security inventory** for a group. - Select projects, choose **Manage security scanners** from **Bulk Action**, and select **Apply default profile to all**. - Review scanner status in the **Tool Coverage** column: - Green indicates full activation. - Partial coverage indicates some triggers are enabled. - Gray indicates the scanner is not configured. - Existing `.gitlab-ci.yml` settings can coexist with profiles, but inventory status may be inaccurate during the transition. Check the project’s **Security Configuration** page for the most reliable profile status. Organizations using GitLab Ultimate should apply default security profiles broadly, then review coverage and project-specific configurations to ensure every relevant trigger is active.

sastgitlabci-cdyaml+4

gitlabMay 13, 2026

5 ways to fix misleading vulnerability severities with policy (opens in new tab)

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities. ## How Severity Override Policies Work - Policies run automatically on every default-branch pipeline. - Rules match findings by: - CVE identifier - CWE identifier - File path - Directory - Available actions: - **Set Severity** to informational, low, medium, high, or critical - **Increase Severity** by one level - **Decrease Severity** by one level - Manual overrides by authorized users take precedence. - GitLab records automated changes in vulnerability history and audit events. ## Downgrading Low-Risk CVEs in Internal Services - Internal tools and services may have substantially lower exposure than public-facing applications. - A policy can reduce the severity of selected CVEs found under paths such as `internal/**/*`. - The `decrease` operation lowers severity by one level—for example, Critical to High or High to Medium. - Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments. ## Upgrading Injection Vulnerabilities in Production Code - XSS (`CWE-79`) and SQL injection (`CWE-89`) are frequently exploited vulnerability classes. - Findings involving these CWEs under `src/**/*` can be forced to **Critical**. - Combining this override with a merge request approval policy can require security-team review before affected code reaches production. ## Normalizing Severity Across Scanners - SAST, dependency, and container scanners may assign different severities to the same CVE. - A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High. - This produces more predictable triage and approval thresholds across scanning tools. ## Incorporating Exploitation Intelligence - CVSS is largely static and does not reflect changes in real-world exploitation. - EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks. - Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating. GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.

sastgitlabvulnerability-managementyaml+4

gitlabMay 13, 2026

Harden your pipeline perimeter for the era of AI-assisted coding (opens in new tab)

AI-assisted coding brings humans, agents, and third-party code together in the software pipeline, increasing the speed at which vulnerabilities can be introduced. The post argues that security tools must become part of the development workflow rather than separate portals. GitLab Ultimate presents this as a three-part control plane: see every risk, automatically enforce policy, and help developers fix vulnerabilities in context. ## See Every Project, Risk, and Action - The Group Security Dashboard consolidates SAST, SCA, secret detection, container, IaC, DAST, and fuzz-testing results across projects. - Security Inventory identifies projects that have never been scanned, exposing governance gaps hidden by project-level dashboards. - Credentials Inventory tracks tokens, owners, scopes, expiration, and revocation status, enabling rapid response to compromised credentials. - Token Lifetime Enforcement applies mandatory maximum lifetimes to tokens. - Audit Event Streaming sends events such as token creation, permission changes, MR approvals, and role updates to SIEM systems in real time. - Group-wide SBOM search helps identify open-source dependency exposure across the project portfolio. ## Enforce Policies Automatically - Scan Execution Policies inject mandatory SAST, SCA, and secret-detection jobs into production pipelines and prevent removal or bypass through configuration such as `[skip ci]`. - Pipeline Execution Policies enforce platform-owned CI templates, closing gaps created by ungoverned or “shadow” pipelines. - MR Approval Policies automate requirements for protected branches, approvers, and code owners. - The Compliance Center maps controls to SOC 2, ISO 27001, NIST, and PCI DSS while providing live dashboards and audit trails. - Secret Push Protection rejects credentials before they enter Git history and records bypass attempts. ## Fix Vulnerabilities in the Development Workflow - The MR security widget displays SAST, SCA, container, IaC, and secret findings directly alongside code changes before they reach the default branch. - Advanced SAST uses cross-file taint analysis to trace untrusted input from source to sink. - GitLab Duo helps identify likely false positives and explain the reasoning behind its assessment. - The Duo Security Analyst Agent prioritizes issues using exploitability, exposure, and business context in addition to CVSS. - Agentic Vulnerability Resolution can create fix merge requests for high-impact SAST findings, allowing developers to review and merge changes through the normal approval process. The practical recommendation is to make security controls native to the pipeline. For organizations adopting AI-assisted development, GitLab Ultimate’s integrated visibility, automated enforcement, and AI-supported remediation are presented as a way to maintain security without sacrificing delivery speed.

sastgitlabci-cddevsecops+4

gitlabApr 16, 2026

Automate remediation with ready-to-merge AI code fixes (opens in new tab)

GitLab 18.11 makes Agentic SAST Vulnerability Resolution generally available, using AI to analyze vulnerabilities, generate code fixes, test them, and open ready-to-merge merge requests. The release aims to reduce developer context switching and AppSec triage while addressing vulnerabilities before production. It also adds faster scanning, risk-based prioritization, and stronger security governance. ## Automated Remediation in the Developer Workflow - Confirmed SAST true positives automatically enter GitLab Duo Agent Platform’s remediation flow. - The agent: - Analyzes the vulnerability in context. - Generates a root-cause fix. - Validates the change with automated tests. - Developers receive a ready-to-merge MR with a confidence score. - Incremental scanning for Advanced SAST provides results before a complete scan finishes. - The approach addresses the growing remediation burden as AI-generated code increases vulnerability volume. ## Prioritizing Vulnerabilities by Business Risk - Vulnerability scoring now uses CVSS 4.0 for more detailed exploitability assessment. - Policy-based severity overrides can use: - CVE information. - CWE classifications. - File paths and directories. - Approval policies can block or warn on merges based on: - Known Exploited Vulnerabilities (KEV). - EPSS score thresholds. - The Top CWEs dashboard chart helps teams identify recurring vulnerability classes and address systemic causes. ## Security Controls and Scanner Coverage - The new Security Manager role gives security teams permissions to: - Enforce scanners. - Configure security policies. - Manage triage and remediation. - Maintain compliance frameworks and audit streams. - The role excludes code modification and deployment permissions, keeping access appropriately scoped. - SAST configuration profiles allow teams to define scanning centrally and apply it across group projects without maintaining project-level YAML or relying on developers for configuration. GitLab 18.11 combines agentic remediation, faster and more risk-aware scanning, and centralized governance. Organizations seeking to reduce vulnerability backlogs can use these capabilities to automate routine fixes while preserving developer oversight through merge requests and confidence scores.

sastdevsecopsai-mlsecurity+3

gitlabApr 16, 2026

GitLab 18.11 release notes | GitLab Docs (opens in new tab)

Agentic SAST Vulnerability Resolution is now generally available in GitLab 18.11 through the GitLab Duo Agent Platform. It autonomously analyzes critical and high-severity SAST findings, proposes code fixes, and creates ready-to-review merge requests. The feature is designed to accelerate remediation while giving reviewers confidence assessments and the option to apply fixes directly from vulnerability details. ## Availability and Integration - Available with GitLab Ultimate. - Supported on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. - Runs: - As part of a SAST scan - After SAST false-positive detection - Manually for individual SAST vulnerabilities ## Automated Vulnerability Analysis - Examines each finding and reasons through the surrounding code context. - Generates proposed fixes for critical and high-severity SAST vulnerabilities. - Automatically opens a merge request containing the remediation for review. ## Review and Remediation Workflow - Provides quality assessments to help reviewers evaluate the likely reliability of each proposed fix. - Lets users apply resolutions directly from vulnerability details pages. - Feedback is welcomed through GitLab issue 585626. ## Practical Recommendation Teams using GitLab Ultimate can enable the feature to streamline SAST remediation, while still reviewing agent-generated merge requests before merging changes.

sastgitlabcode-qualitydevops+3

gitlabMar 19, 2026

GitLab 18.10 brings AI-native triage and remediation (opens in new tab)

GitLab 18.10 adds AI-powered security features designed to reduce vulnerability triage noise and speed remediation. GitLab Duo Agent Platform can assess whether SAST and secret-detection findings are likely false positives, explain its reasoning, and— for verified SAST issues—generate tested fixes in merge requests. These capabilities are available to GitLab Ultimate customers using the Duo Agent Platform, with some features still in beta. ## SAST False Positive Detection - Generally available for new critical and high-severity SAST findings. - Uses LLM-based agentic reasoning to assess whether a vulnerability is likely real or a false positive. - Adds: - A confidence score - An AI-generated explanation - A “Likely false positive” or “Likely real” badge - Findings can be filtered in the Vulnerability Report so teams can prioritize likely real vulnerabilities. - The assessment remains a recommendation that teams can review and audit. ## Agentic SAST Vulnerability Resolution - Currently in beta. - For findings judged unlikely to be false positives, the agent: - Reads the vulnerable code and its surrounding context - Generates a proposed fix - Validates the fix with automated tests - Opens a merge request for developer review - The merge request includes code changes, a confidence score, and an explanation of the remediation. - Developers should still carefully review AI-generated changes before merging. ## Secret False Positive Detection - Currently in beta. - Identifies likely test credentials, placeholder values, example tokens, and other dummy secrets. - Provides confidence scores, explanations, and visual badges in the Vulnerability Report. - Runs automatically on the default branch and can also be triggered manually with “Check for false positive.” - The goal is to help teams focus on exposed credentials that represent genuine risk. GitLab 18.10 extends AI assistance across the vulnerability lifecycle: filtering out misleading findings, explaining security assessments, and proposing validated code fixes. Teams using GitLab Ultimate and Duo Agent Platform can use these features to reduce review effort while retaining human control over security decisions and merges.

sastgitlabvulnerability-managementmerge-requests+4