dependency-scanning

7 posts

gitlab

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.

gitlab

When a version bump breaks your build, GitLab fixes it (opens in new tab)

GitLab’s Dependency Scanning Auto-Remediation aims to reduce security backlogs by automatically upgrading vulnerable dependencies and repairing code when those upgrades break builds. Its AI agent analyzes pipeline errors, changelogs, and code usage, then commits fixes within the same merge request. All changes remain subject to existing reviews, approval gates, and audit controls. ## Why Dependency Backlogs Grow - Transitive dependencies account for a large share of vulnerabilities; one 2025 Maven study found vulnerabilities in about 63% of latest releases through transitive dependencies, compared with 31% through direct dependencies. - Dependency remediation competes with feature work, causing high-severity issues to remain unresolved beyond PCI-DSS and FedRAMP’s 30-day expectations. - Approximately one in eight dependency updates introduces a breaking change, and even “backward-compatible” updates can break builds. - AI-assisted exploit development is also speeding up vulnerability disclosure and weaponization. ## Automated Dependency Upgrades - When SBOM-based dependency scanning identifies a vulnerable package with an available fix, GitLab automatically opens a merge request. - The upgrade targets the nearest fixed version. - If no eligible fix exists, the vulnerability remains in the report until a safe upgrade becomes available. - Each merge request is attributed to a dedicated service account for traceability. - Developers can also start remediation manually for individual findings. ## AI-Powered Breaking-Change Resolution - If the dependency upgrade causes a pipeline failure, GitLab Duo Agent Platform investigates the failure. - It considers: - Pipeline error messages - The dependency’s changelog - How the project uses the dependency - The agent commits necessary application-code changes to the same merge request. - If it cannot restore a passing pipeline, it stops and documents its findings for developers. - Supported ecosystems include Bundler, Maven, Gradle, and major Python and JavaScript/TypeScript package managers; Rust and Go support is planned. ## Safeguards and Governance - Auto-remediation never merges changes automatically. - Merge requests explain the vulnerability, target version, and AI-generated code changes. - Cooldown periods prevent repeated remediation activity from overwhelming projects. - Closed merge requests are not recreated unless a newer fix is available. - Teams can select vulnerability severities and limit upgrades to patch, minor, or major versions. - Remediation runs through the organization’s existing pipelines, access controls, approval gates, and audit trails. - Configuration can be managed at the project or group level through API-based profiles during the beta. ## Availability and Pricing - Dependency Scanning Auto-Remediation is in public beta on GitLab.com, with rollout planned for Self-Managed and Dedicated installations. - Automated version bumping is included with GitLab Ultimate. - Agentic breaking-change resolution is available through a GitLab Duo Agent Platform trial or included GitLab Credits for eligible Ultimate subscribers. GitLab recommends using the feature to turn vulnerable dependencies into reviewable, pipeline-validated merge requests, reducing manual remediation effort without sacrificing developer approval or compliance oversight.

gitlab

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

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

datadog

From single pull requests to full software packages: Detecting malicious code at scale (opens in new tab)

BewAIre evolved from a pull-request malware detector into a system for scanning dependency packages and upstream registries. Its core improvement is a two-stage pipeline: a cheap LLM filter handles routine changes, while a more capable agent investigates suspicious cases using external tools and repository context. This approach raised accuracy from 97.4% to 99.86%, eliminated false positives in a 690-diff sample, and reduced latency and cost through early exits. ## Expanding Beyond Pull Requests - Software supply-chain attacks increasingly compromise trusted dependencies such as axios, LiteLLM, and Mistral. - BewAIre initially focused on detecting malicious pull requests, identifying security testing, bug-bounty activity, and real attacks such as the Hackerbot campaign. - The team aimed to apply the same LLM-based detection to complete packages and package registries without sacrificing accuracy, latency, or predictable cost. ## Limits of Single-Pass LLM Evaluation - BewAIre began as a basic “LLM-as-judge” system that analyzed diffs through an inference API. - More capable reasoning models improved detection but increased costs. - Large diffs, especially dependency upgrades, challenged context-window limits. - Two changes addressed these limitations: - A filter-then-review escalation path. - Tool-enabled investigation allowing models to gather additional evidence. ## Two-Stage Filtering and Investigation - The filter phase: - Runs on every change using a fast, inexpensive model. - Uses straightforward prompts and diff chunking for large changes. - Produces a binary suspicious/benign decision. - Ends processing immediately when a change appears benign. - The investigation phase: - Runs only when the filter raises a concern. - Uses a stronger reasoning model in an agentic loop. - Can inspect commits, files, contributor histories, dependency metadata, and commit ranges through GitHub APIs. - Checks for reverted commits, typosquatting, suspicious contributor behavior, and dependency risks using sources such as osv.dev and Datadog SCA. ## Detecting Obfuscated Attacks - In the Hackerbot Claw example, the system identified a malicious filename containing shell command substitution. - A base64-encoded payload decoded to a `curl ... | bash` command that downloaded and executed remote code. - The investigation agent added useful context: - The contributor account was newly created, had no profile information, and had no followers. - The pull request had no reviews or approvals. - `${IFS}` obfuscation was used to evade security filters. - Combining code analysis with repository and author context made the final assessment more precise. ## Combining LLMs with Static Checks - The filter model could mistakenly treat Datadog-like typosquatting domains as legitimate without access to investigative tools. - BewAIre added preprocessing that extracts domains and compares them against a static list of known typosquatting variants. - This hybrid design improves reliability while avoiding the cost and nondeterminism of performing every check through a powerful LLM. ## Measured Results - Accuracy improved from 97.4% to 99.86% across 690 representative test diffs. - False positives fell from 17 to zero. - Most benign changes exit during the inexpensive filter stage. - Suspicious changes still receive deeper analysis, preserving broad coverage while controlling latency and cost. The practical recommendation is to combine inexpensive broad screening with selective, tool-driven investigation. Static security checks should complement LLM reasoning, especially for predictable threats such as domain typosquatting.

gitlab

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.

gitlab

Reduce supply chain risk with SBOM-based dependency scanning (opens in new tab)

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security. ## Why Traditional Dependency Scanning Falls Short - Modern applications rely heavily on third-party and deeply nested dependencies. - Supply chain compromises can affect every project that depends on a vulnerable package. - AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities. - Teams need to know not only which packages are vulnerable, but also: - How they entered the project - What dependencies they brought with them - Whether the application actually uses them ## How SBOM-Based Scanning Works - The analyzer inventories dependencies in a CycloneDX-format software bill of materials. - Components are matched against the GitLab Advisory Database to identify known vulnerabilities. - Findings appear in: - Merge requests, so developers can address issues before release - Vulnerability dashboards and reports, for centralized security oversight - GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling. ## Tracing and Prioritizing Vulnerabilities - The analyzer follows transitive dependency chains regardless of nesting depth. - Teams can see the path a vulnerable package took into the project—for example, `library-a` → `library-b` → `library-c`. - For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required. - Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute. - Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development. ## Supported Ecosystems and Input Files - The release supports more than 24 package ecosystems, with additional support planned. - Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information. - If those are unavailable, the analyzer can parse manifests such as: - `pom.xml` - `requirements.txt` - Gradle build files - Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing. ## Centralized Configuration and Enforcement - GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects. - Security and platform teams can configure scanning once instead of maintaining individual pipeline files. - Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying `.gitlab-ci.yml` files. - Centralized policies reduce configuration drift, skipped projects, and audit gaps. ## Availability and Migration - SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations. - Teams migrating from Gemnasium can run both analyzers in parallel and compare their results. - GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration. Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.

gitlab

GitLab 19.0 | GitLab Docs (opens in new tab)

GitLab 19.0, released May 21, 2026, expands AI-assisted development, work-item customization, secrets management, and dependency security. Major changes include group-level Duo review instructions, configurable work-item types, open beta access to GitLab Secrets Manager, and generally available SBOM-based dependency scanning. GitLab also introduces usage-based billing for Duo Core and adds new agent, search, model, and workflow capabilities. ## Customization and Project Management ### Group-level custom review instructions for GitLab Duo - Premium and Ultimate feature for GitLab.com, Self-Managed, and Dedicated. - Groups and subgroups can share review guidance through: ```text .gitlab/duo/mr-review-instructions.yaml ``` - A project in the group serves as the template. - Group instructions are combined with project-specific instructions. - Supported by both Code Review Flow and GitLab Duo Code Review. ### Configurable work item types - Projects can define custom types such as User Story, Bug, or Maintenance instead of using only Issues and Tasks. - Each type has its own name and icon. - Types support custom fields, status lifecycles, saved views, and issue boards. - Configuration at the top-level group or organization cascades to projects. - Administrators can enable or disable types globally or allow project-level control. - Disabling a type does not affect existing work items. ## Security and Dependency Management ### GitLab Secrets Manager enters open beta - Available to Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. - Project and group Owners can store and reference CI/CD secrets in GitLab. - Secrets are scoped to projects or groups and available only to jobs that explicitly request them. - The feature remains subject to beta support policies and may not be production-ready. ### SBOM-based dependency scanning becomes generally available - Available for Ultimate customers across GitLab offerings. - Maven, Gradle, and Python projects receive visibility into transitive dependencies and their vulnerabilities. - Automatic dependency resolution runs when no lockfile or dependency graph is available. - If resolution is unavailable, manifest scanning examines direct dependencies in files such as: - `pom.xml` - `requirements.txt` - `build.gradle` - `build.gradle.kts` - Manifest scanning is enabled by default, while full transitive coverage requires dependency resolution, a lockfile, or a manually supplied dependency graph. ## GitLab Duo and Agentic Development ### Duo Developer enhancements - GitLab Duo Developer can be triggered by: - Assigning it to an issue - Selecting **Generate MR** - Mentioning it with `@mention` in an issue or merge request discussion - It can turn feedback, to-do items, and design questions into code changes, follow-up merge requests, or research summaries. - With `AGENTS.md` and `agent-config.yml`, it can run tests and checks before committing. - Administrators can enable mention and assignment triggers for eligible projects. ### Duo Core adopts usage-based billing - Code Suggestions in the Web IDE and desktop IDEs now consume GitLab Credits. - Duo Chat becomes agentic for Duo Core users and runs on the GitLab Duo Agent Platform. - Administrators must enable the Agent Platform for the instance or top-level group to use Chat in GitLab or desktop IDEs. ### New agent and search capabilities - Exact code search supports repository filtering with the `repo:` syntax: ```text def authenticate repo:my-group/my-project ``` - Flows and external agents can trigger when a draft merge request is marked ready for review. - The merge request ready trigger is controlled by the `merge_request_ready_flow_trigger` feature flag and is disabled by default. - Claude Opus 4.7 is available in the Duo Agent Platform for complex, multistep tasks involving code review, CI/CD, and vulnerability resolution. - GitLab Duo Agent Platform Self-Hosted adds compatibility with Gemini models and supports multiple flows, including Code Review Flow and SAST vulnerability workflows. GitLab 19.0 is particularly significant for teams adopting AI agents and centralized development governance. Organizations should review Duo’s new billing model, test Secrets Manager carefully during its beta period, and enable dependency resolution to obtain comprehensive vulnerability coverage.