What’s new in Eficode ROOT: August 2025

Set maximum user session length (all tiers)
Administrators can now define the maximum length of a user session, based on either the initial sign-in time or the last recorded activity. Users will receive notifications before their session expires, but they will not be able to extend or override it. This feature is disabled by default. [Learn more here.]

Restrict user invitations (Premium, Ultimate)
Organizations using Premium or Ultimate can now disable user invitations to groups or projects. This enables tighter control over who can access your GitLab environment. The setting is managed at the instance level and applies across the entire GitLab deployment. Administrators themselves still retain the ability to invite users. [Learn more here.]

New member invitations can now be disabled. 

GitLab for Slack: Support for multiple workspaces (all tiers)

For GitLab Self-Managed and GitLab Dedicated customers, the GitLab for Slack app now supports multiple workspaces. This enhancement enables smoother integration across federated Slack environments, making it easier for larger organizations to stay connected with their GitLab workflows.

To enable this feature, please contact us directly. [Learn more here.]

Streamlined cleanup: Delete groups and placeholder users (all tiers)

With GitLab 18.0, placeholder users are now automatically deleted when their associated top-level group is removed. If these users are also linked to other projects, the deletion applies only to the top-level group—preserving project history and attributions elsewhere.

This improvement simplifies user management by reducing clutter from unused placeholder accounts. [Learn more here.]

Automate Jira issue creation from vulnerabilities (Ultimate)

You can now configure the creation of Jira issues from vulnerabilities using the project integrations API. Previously, this setup required manual configuration through the Project settings page. This update enables greater automation and consistency across projects. [Learn more here.]

View inactive personal access tokens (all tiers)

To enhance traceability and security, GitLab now retains and displays inactive personal access tokens. Previously, tokens were no longer visible after expiration or revocation. This change allows administrators and users to review historical token usage more effectively. [Learn more here.]

Filter by bot or human users in the Admin area (all tiers)

For GitLab instances with a large mix of human and bot users, administrators can now filter the user list by user type. This enhancement supports:

• Quick identification and management of human users separately from automated accounts

• Targeted administrative actions based on user type

• Streamlined auditing and user management workflows

[Learn more here.]

LDAP authentication with GitLab username (Premium, Ultimate)

LDAP users can now authenticate requests using their GitLab username, even if it differs from their LDAP username. Previously, such mismatches resulted in authentication errors. This update enables greater flexibility in naming conventions between GitLab and LDAP, without disrupting approval workflows. [Learn more here.]

AI capabilities with GitLab Duo (Premium, Ultimate, Duo Pro, Duo Enterprise)

GitLab Premium and Ultimate now include GitLab Duo—bringing a suite of powerful, AI-native features directly into your development workflow. These capabilities, such as Code Suggestions and Chat within the IDE, enable teams to:

• Analyze, understand, and explain code

• Write secure code more efficiently

• Generate tests to maintain code quality

• Refactor code to improve performance or integrate specific libraries

These enhancements accelerate development while maintaining high standards for security and quality. [Learn more here.]

GitLab Duo chat code suggestions.

Automated reviews with Duo Code Review (Premium, Ultimate, Duo Enterprise)

Duo Code Review now supports automatic execution on merge requests—eliminating the need for manual activation each time. By updating your project settings, you can configure GitLab Duo Code Review to run automatically on all eligible merge requests.

Once enabled, Duo Code Review will automatically analyze merge requests, excluding drafts or those with no changes. This automation ensures consistent, AI-assisted code reviews across your codebase, helping maintain high standards of quality and security. [Learn more here.]

Automatic GitLab Duo code review can now be enabled.

Repository X-Ray now available on GitLab Duo Self-Hosted (Premium, Ultimate, Duo Enterprise)

Repository X-Ray now supports Code Suggestions for GitLab Duo Self-Hosted (currently in beta). This feature is now generally available for GitLab Self-Managed instances, bringing AI-powered insights directly to your on-premises environment. [Learn more here.]

Faster completions with Code Suggestions prompt caching (Premium, Ultimate, Duo Pro, Duo Enterprise)

Code Suggestions now includes prompt caching, significantly reducing code completion latency by avoiding repeated processing of previously submitted prompts and inputs.

Importantly, cached data is never logged to persistent storage, ensuring user privacy. If needed, prompt caching can be disabled via the GitLab Duo settings. [Learn more here.]

GitLab Duo Core configuration.

Improved context in Duo Code Review (Premium, Ultimate, Duo Enterprise)

Duo Code Review has been enhanced to deliver more accurate and context-aware analysis—resulting in higher-quality code reviews and fewer irrelevant suggestions. Key improvements include:

• Understanding proposed changes: The system now uses the merge request’s title and description to better understand the intent behind code changes.

• Recognizing cross-file relationships: By analyzing all diffs simultaneously, Duo Code Review can detect patterns and dependencies across multiple files—reducing false positives.

• Fitting modifications into existing patterns: The full content of changed files is now included in the review process, enabling a more holistic assessment of how changes align with existing code structures.

[Learn more here.]

GitLab improved context review.

Security scanners now support MR pipelines (all tiers)

GitLab now offers greater control over how Application Security Testing (AST) scanners run within merge request (MR) pipelines. This opt-in feature helps teams balance security with pipeline performance.

The new environment variable, AST_ENABLE_MR_PIPELINES, lets you control scanner behavior:

• Stable templates: Default to branch pipelines. Set AST_ENABLE_MR_PIPELINES: "true" to enable MR pipelines when a merge request is open.

• Latest templates: Default to MR pipelines. Set AST_ENABLE_MR_PIPELINES: "false" to fall back to branch pipelines instead.

This enhancement applies to all security scanning templates—except for API-Discovery.gitlab-ci.yml, which now also defaults to branch pipelines as of GitLab 18.0, aligning it with other Stable templates.

[Learn more here.]

Enhanced merge request review experience with new review panel (all tiers)

The merge request review experience has been significantly improved with the introduction of a dedicated review panel. Previously, it was difficult to view and manage all draft comments before submission due to a fragmented interface.

Now, a collapsible drawer provides a clear, organized view of all pending draft comments. A numbered badge indicates the total number of unresolved comments, and opening the panel reveals a scrollable list—making it easier to review and refine your feedback before submitting.

[Learn more here.]

Enhanced review panel.

View downstream pipeline job logs in VS Code (all tiers)

With the latest update to the GitLab Workflow extension, you can now view job logs from downstream pipelines directly within your VS Code editor. Previously, accessing logs from child pipelines required navigating through the GitLab web interface—this update brings that visibility closer to where you work.

[Learn more here.]

Job logs from downstream.

ORCID identifier support in user profiles (all tiers)

GitLab user profiles now support ORCID (Open Researcher and Contributor ID) identifiers. This enhancement is especially valuable for researchers and academics, providing a persistent digital identifier that ensures accurate attribution and recognition of professional contributions.

By integrating ORCID, GitLab becomes more accessible to the research community and better aligned with scholarly workflows. [Learn more here.]

ORCID identifier in user profile.

New active parameter for Groups and Projects REST APIs (all tiers)

A new active parameter has been added to the Groups and Projects REST APIs, making it easier to filter resources by status.

• Setting active=true returns only non-archived groups or projects not marked for deletion.

• Setting active=false returns only archived groups or those marked for deletion.

• If left undefined, no status-based filtering is applied.

This enhancement streamlines API calls and improves workflow efficiency by allowing you to easily target specific group and project states. [Learn more here.]

View open merge requests affecting a file (all tiers)

You can now quickly see all open merge requests that are modifying the specific file you're viewing in the repository. This enhancement brings several key benefits:

• Proactive conflict resolution: Spot potential merge conflicts early and take action before they disrupt development.

• Reduced duplication: Avoid duplicating work already in progress by other team members.

• Improved collaboration: Instantly gain visibility into ongoing changes, enhancing team coordination and efficiency.

A badge displays the number of open merge requests affecting the file. Hover over it to see a popover with a list of those merge requests. [Learn more here.]

Enhanced visibility of in-progress code changes.

Archived project visibility in the compliance projects report (Premium, Ultimate)

The compliance projects report now includes visibility into whether a project is archived—an essential improvement for comprehensive compliance oversight across both active and archived projects.

This enhancement introduces:

• An archived status badge displayed alongside each project in the compliance report

• A filter that lets you toggle between archived, non-archived, or all projects

These updates provide clearer context when reviewing compliance frameworks within your group or subgroup. [Learn more here.]

Multiple matches per file in code search (Premium, Ultimate)

The beta version of exact code search has been enhanced to display multiple matches from the same file in a consolidated view. This update brings several usability improvements:

• Improved readability: Results are displayed as they appear in your editor, reducing visual clutter by collapsing nearby matches.

• Enhanced context: Adjacent matches are shown together, preserving the code context.

• Efficient navigation: The number of matches per file is clearly indicated, making it easier to explore results.

This update makes it faster and easier to identify and understand code patterns across your repositories. [Learn more here.]

Exact code search multiple match UI demo.

Epic support in GitLab Query Language views (Beta) (Premium, Ultimate)

GitLab Query Language (GLQL) views have been enhanced with support for epics as a queryable type. You can now search for epics across groups and filter by parent epic—significantly improving planning and tracking workflows.

This update simplifies epic-level querying and organization, making it easier to manage large-scale initiatives within GitLab. [Learn more here.]

GitLab Query Language views enhancements (all tiers)

GitLab Query Language (GLQL) views have received several key improvements that enhance usability and flexibility:

• Support for the >= and <= operators across all date fields

• A View actions dropdown for easier access to view-related operations

• A new Reload action for refreshing query results

• Introduction of field aliases

• Ability to alias columns with custom names in GLQL tables

These enhancements make it easier to create, customize, and interact with data views in GitLab. [Learn more here.]

Enhanced CODEOWNERS file validation with permission checks (Premium, Ultimate)

GitLab now performs comprehensive validation of CODEOWNERS files—going beyond basic syntax checks to ensure your approval workflows function smoothly.

When viewing a CODEOWNERS file, GitLab automatically validates the first 200 unique user and group references, checking that:

• All referenced users and groups have access to the project

• Users have the appropriate permissions to approve merge requests

• Groups have at least Developer-level access

• Groups include at least one user with merge request approval permissions

This proactive validation helps detect configuration issues early, reducing the risk of broken approval flows and ensuring your designated Code Owners can fulfill their review responsibilities. [Learn more here.]

Achieve SLSA Level 1 compliance with CI/CD components (all tiers)

GitLab now makes it easier to meet SLSA Level 1 compliance by introducing CI/CD components that enable signing and verifying provenance metadata for your artifacts.

These reusable modules wrap Sigstore Cosign functionality and can be seamlessly integrated into your GitLab Runner workflows—ensuring the integrity and traceability of your build artifacts.

[Learn more here.]

Maven virtual registry now in beta (Premium, Ultimate)

GitLab's new Maven virtual registry, now available in beta, simplifies Maven dependency management by consolidating multiple upstream repositories under a single endpoint.

Previously, each dependency source—such as Maven Central, private repositories, or GitLab’s own package registry—required separate configuration. This led to slower builds and more complex security reviews. The virtual registry resolves these challenges with centralized management and intelligent caching.

Key benefits:

• Simplified configuration: One endpoint for all Maven dependencies

• Improved build performance: Faster builds through smart caching

• Enhanced security: Centralized access control integrated with GitLab authentication

• Reduced overhead: Less configuration effort for platform engineers

The upcoming General Availability (GA) release will introduce a web-based UI, shareable upstream functionality, lifecycle policies for cache management, and improved analytics.

Current beta limitations:

• Up to 20 virtual registries per top-level group

• Up to 20 upstreams per virtual registry

• API-only configuration (UI coming at GA)

[Learn more here.]

Delayed project and group deletion now available for all users (all tiers)

GitLab now offers delayed deletion and deletion protection for all users—including personal projects in user namespaces. Previously limited to group namespaces, this safety feature places deleted projects and groups into a "pending deletion" state rather than removing them immediately. [Learn more here.]

On GitLab.com, the default grace period is 7 days, during which time the project or group can be recovered—helping prevent accidental data loss without requiring complex recovery procedures.

By making data protection a default capability, GitLab reinforces its commitment to keeping your work safe. [Learn more here.]

Project and group delayed deletion protection.

CI/CD job token allowlist enforcement: Strengthening project-level access control (all tiers)

GitLab is enforcing stricter controls on CI/CD job token access through the Authorized groups and projects allowlist setting. This change improves security between projects and affects both new and existing projects.

Background

• The Authorized groups and projects setting was introduced in GitLab 15.9, replacing the older Limit access to this project option (renamed in GitLab 16.3).

• When set to Only this project and any groups and projects in the allowlist, job tokens from outside the allowlist are blocked.

• In new projects, this setting is now enabled by default.

• In older projects, the default may still allow job tokens from any project unless the allowlist was explicitly configured.

What’s changing?

• Starting in GitLab 17.6, administrators on GitLab Self-Managed and GitLab Dedicated can enforce this setting instance-wide.

  • This prevents project maintainers from selecting the All groups and projects option, ensuring stricter access control.

• In GitLab 18.0, enforcement will be enabled by default on:

  • GitLab.com

  • GitLab Self-Managed

  • GitLab Dedicated

  Note: While the setting will be active by default, existing project-level configurations will not be changed automatically for Self-Managed and Dedicated instances. Admins can disable enforcement post-upgrade if needed.

What you should do:

• Prepare your allowlists:
  If your project uses CI/CD job tokens for cross-project access, populate the Authorized groups and projects allowlist accordingly and set the access control to Only this project and any groups and projects in the allowlist

• Use the tracking feature (introduced in GitLab 17.6) to identify which projects are accessing your project using job tokens.

• Use the migration tool (introduced in GitLab 17.10) to automatically populate the allowlist from the job token authentication log. This simplifies preparation ahead of general enforcement in GitLab 18.0.

⚠️ Important: The migration tool will be removed in GitLab 18.3, so we recommend completing this process before then.

Removal of Limit access from this project setting for CI/CD job tokens (all tiers)

GitLab is completing the deprecation of an older CI/CD job token security setting in GitLab 18.0.

• Originally introduced in GitLab 14.4 as Limit CI_JOB_TOKEN access, this setting was renamed to Limit access from this project in GitLab 16.3.

• A superior alternative—Authorized groups and projects—was introduced in GitLab 15.9. It uses an allowlist to precisely control which groups and projects can access your project using a job token.

• The older setting was deprecated in GitLab 16.0 and will be removed entirely in GitLab 18.0.

What to know:

• The deprecated setting is disabled by default for all new projects.

• From GitLab 16.0 onward, once disabled, this setting cannot be re-enabled.

• To manage access securely, use the Authorized groups and projects setting instead.

API Discovery CI/CD template will default to branch pipelines (all tiers)

In GitLab 18.0, the default behavior of the API Discovery CI/CD template (API-Discovery.gitlab-ci.yml) will change to match other Stable security scanner templates.

What’s changing:

• Before GitLab 18.0: Jobs in the template defaulted to run in merge request (MR) pipelines when an MR was open.

• Starting in GitLab 18.0: Jobs will run in branch pipelines by default.

• To continue using MR pipelines, set the following variable in your pipeline configuration: 

  AST_ENABLE_MR_PIPELINES: "true"


This change promotes consistency across AST templates while still allowing teams to opt into MR-based scanning when needed. The implementation is tracked in GitLab issue #410880.

Major version update for Application Security Testing analyzers (all tiers)

In GitLab 18.0, all Application Security Testing (AST) analyzers will receive major version updates to their container images.

What you need to know:

• If you’re using custom CI/CD job definitions (i.e., not the default included templates) or have pinned specific analyzer versions, you’ll need to:

  • Remove the pinned versions, or

  • Update your pipeline to use the new major versions once GitLab 18.0 is released.

• GitLab versions 17.0 through 17.11 will continue receiving updates to the current analyzer versions until the release of GitLab 18.0.

• After GitLab 18.0 is released, new features and bug fixes will only be delivered in the updated major version of the analyzers.

• GitLab will not remove any existing container images from the GitLab container registry, but:

  • Deprecated analyzer versions will no longer receive updates.

  • As per GitLab’s maintenance policy, security patches will only be backported to the latest 3 minor releases.

Specifically, the following analyzers will no longer be updated after the GitLab 18.0 release:

• GitLab Advanced SAST: version 1
• Container Scanning: version 7
• Gemnasium: version 5
• DAST: version 5
• DAST API: version 4
• Fuzz API: version 4
• IaC Scanning: version 5
• Pipeline Secret Detection: version 6
• Static Application Security Testing (SAST): version 5 of all analyzers
• kics
• kubesec
• pmd-apex
• semgrep
• sobelow
• spotbugs

Behavior change for Upcoming and Started milestone filters (all tiers)

In GitLab 18.0, the behavior of the “Upcoming” and “Started” milestone filters will change.

• The updated filtering logic is outlined in GitLab issue #429728.

• This change applies to the GitLab UI and GraphQL API.

• The REST API will remain unchanged, continuing to use the existing milestone filtering behavior.

Be sure to review the issue if you rely on these filters in dashboards, boards, or custom integrations.

Updated default behavior for DAST_DEVTOOLS_API_TIMEOUT (all tiers)

The default behavior of the DAST_DEVTOOLS_API_TIMEOUT environment variable is changing in GitLab 18.0 to provide more adaptive scan performance.

• Before GitLab 18.0: The timeout was a fixed 45 seconds.

• Starting in GitLab 18.0: The timeout will be dynamically calculated based on other scan timeout settings, making it more context-aware.

• The new behavior of both the filters is outlined in issue 429728.

Why this matters:

• The previous 45-second value often exceeded the effective timeout of other scan operations.

• The new behavior ensures that DAST_DEVTOOLS_API_TIMEOUT is aligned with actual scan behavior and improves reliability across more scenarios.

To lessen potential disruptions, we will incrementally adjust the default timeout value according to this schedule:

Dependency Proxy token scope enforcement (all tiers)

The Dependency Proxy for containers accepts docker login and docker pull requests using personal access tokens or group access tokens without validating their scopes.

In GitLab 18.0, the Dependency Proxy will require both read_registry and write_registry scopes for authentication. After this change, authentication attempts using tokens without these scopes will be rejected.

This is a breaking change. Before you upgrade, create new access tokens with the required scopes, and update your workflow variables and scripts with these new tokens.

To assess how this change impacts your GitLab Self-Managed instance, you can monitor authentication logs for warning messages in GitLab 17.10 and later. In your auth_json.log file, look for entries that contain Dependency proxy missing authentication abilities. If you're using GitLab Helm charts or GitLab Dedicated, then the logs will be in component: "gitlab" and subcomponent: "auth_json". These entries show authentication attempts using tokens without the required scopes, which will fail after upgrading to GitLab 18.0.

Deprecate Terraform CI/CD templates

The Terraform CI/CD templates are deprecated and will be removed in GitLab 18.0. This affects the following templates:

• Terraform.gitlab-ci.yml
• Terraform.latest.gitlab-ci.yml
• Terraform/Base.gitlab-ci.yml
• Terraform/Base.latest.gitlab-ci.yml

In GitLab 16.9, a new job is added to the templates to inform users of the deprecation. The warning can be switched off by overwriting the deprecated-and-will-be-removed-in-18.0 job with a placeholder job in the affected pipelines.

GitLab won't be able to update the terraform binary in the job images to any version that is licensed under BSL.

To continue using Terraform, clone the templates and Terraform image, and maintain them as needed. GitLab provides detailed instructions for migrating to a custom built image.

As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com or the new OpenTofu CI/CD template on GitLab Self-Managed. CI/CD components are not yet available on GitLab Self-Managed, but Issue #415638 proposes to add this feature. If CI/CD components become available on GitLab Self-Managed, the OpenTofu CI/CD template will be removed.

You can read more about the new OpenTofu CI/CD component here.

REST API endpoint pre_receive_secret_detection_enabled is deprecated

The REST API endpoint pre_receive_secret_detection_enabled is deprecated in favor of secret_push_protection_enabled. We are renaming some API fields to reflect the name change of the feature pre_receive_secret_detection to secret_push_protection.

GitLab added the new API field name, but will no longer remove the old field name in GitLab 18.0 as originally announced.

GitLab will still update the database to remove the old pre_receive_secret_detection_enabled database column, but you'll be able to use either API field name. Both will reflect the value of the new secret_push_protection_enabled database column.

Rename options to skip GitGuardian secret detection

The options to skip GitGuardian secret detection, [skip secret detection] and secret_detection.skip_all, are deprecated. You should use [skip secret push protection] and secret_push_protection.skip_all instead.

While we recommend using the new wording, GitLab will remove the old option in GitLab 18.0.

Reject container image pull policies not in allowed_pull_policies

All configured pull-policies should be present in the allowed_pull_policies configuration specified in the runner's config.toml file. If they are not, the job should fail with an incompatible pull policy error.

In the current implementation, when multiple pull policies are defined, jobs pass if at least one pull policy matches those in allowed-pull-policies, even if other policies are not included.

In GitLab 18.0, jobs will fail only if none of the pull policies match those in allowed-pull-policies. However, unlike the current behavior, jobs will use only the pull policies listed in allowed-pull-policies. This distinction can cause jobs that currently pass to fail in GitLab 18.0.

Toggle notes confidentiality on APIs

Toggling notes confidentiality with REST and GraphQL APIs is being deprecated. Updating notes' confidential attribute is no longer supported by any means. We are changing this to simplify the experience and prevent private information from being unintentionally exposed.

Packages and repositories

Hex Repositories

Hex repositories in Artifactory allow you to deploy and resolve Hex packages. Learn more here.

NVIDIA NIM Models

JFrog Artifactory now offers integration with NVIDIA NIM, enabling the caching of NVIDIA NIM models within Artifactory through a remote repository. NVIDIA NIM provides a suite of microservices designed to accelerate the deployment of foundation models across various cloud environments or data centers, prioritizing data security. It delivers production-grade runtimes, complete with continuous security updates, stable APIs, and enterprise-grade support. For additional details, please consult NVIDIA NIM Repositories. 

New Machine Learning Layout for Hugging Face Repositories 

With the new unified Machine Learning layout, all new Hugging Face repositories will now be created using this format. Users have the option to manually migrate existing Hugging Face repositories to the new Machine Learning layout. The legacy layout for Hugging Face repositories will be deprecated in July 2025, at which point all remaining repositories using the legacy layout will be automatically upgraded to the Machine Learning layout. Learn more here.

Added Support for Chocolatey and PowerShell Clients in Nuget Repositories

Artifactory now supports PowerShell (version 1.0.5 or newer) and Chocolatey (version 1.2.0 or newer) for interacting with NuGet repositories. Learn more here.

Complete Docker and OCI List Manifest Image Overwrite

Overwriting a `list.manifest` file now automatically removes all prior sub-manifests. This streamlines storage and eliminates the need for manual cleanup. Learn more here.

Support Added for the PyPI JSON API in remote, local  and virtual repositories

Artifactory's local repositories now offer support for the PyPI JSON API, including most attributes. However, the following attributes (JSON keys) are not supported:

• Deprecated keys: `releases`, `downloads`, `has_sig`, `bugtrack_url` (as outlined in the PyPI JSON API documentation)
• Sub-keys within the `info` section: `description_content_type`, `dynamic`, `license_expression`, `license_files`, `maintainer`, `maintainer_email`, `project_urls`, `provides_extra`, `requires_dist`
• The `vulnerabilities` key

Added Support for Listing Folder Items in Conan Smart Remote Repositories

For Conan Smart Remote Repositories, a new setting called "List Folder Items" is now available. This feature can be enabled by checking the "List Remote Artifacts" box when creating the repository, which allows for the listing of folder items.

Improved Access for Go Remote Repositories

Go remote repositories now support the ability to access subgroups in GitLab.

​​Bearer Authentication for Remote Repositories

Added Bearer Authentication support for remote repositories.

Compile list of inconsistent Federated repositories and New API for removing Federation members

A new API is now available, allowing you to retrieve a list of all Federated repositories within your local Artifactory instance that have configuration mismatches with one or more remote members. Once you have this list, you can use the Synchronize Federated Member Configuration REST API to synchronize each mismatched member. Learn more here how to get a list of inconsistent federated repositories.

Introducing a new REST API, designed to simplify the removal of a member from all repository Federations. This is particularly useful when decommissioning a site, as the API will remove the member from every Federation it was part of on that specific site. Learn more here. 

Added Tags for RPM local repositories

Enhanced package management for clients like `dnf` and `yum` now includes support for `Recommends` and `Suggests` dependency tags within the `primary.xml` metadata of RPM local repositories. This enhancement improves the recognition of optional dependencies.

Additionally, the inclusion of `Recommends` tags in `primary.xml` can now be configured using the feature flag `yum.local.install.recommended.dependencies.enabled`. 

Properties Tab for RPM Remote Packages

RPM package properties, downloaded from remote repositories, are now calculated and displayed in the Properties tab of the UI. Learn more here.

RPM Repositories - SHA-256 checksums have been integrated into Local and Virtual repositories

Jfrog improved the security of our local and virtual repositories by adding SHA-256 checksums to their `repomd.xml` files. This update ensures that package integrity verification meets the same high security standards as remote repositories.

Previously, local repositories lacked SHA-256 checksums in their `repomd.xml` files, which increased the risk of undetected package tampering or corruption.

To enhance security through SHA-256 checksums for package integrity verification, update your configuration by setting `yum.local.repomd.calculate.sha2.enabled = true`.

API Key Deprecation Control

With API Key having reached End of Life in Q4.24, this version introduces a new checkbox in the JFrog platform UI to manage its usage deprecation. By default, the Disable API Key Usage checkbox, located under Administration > Security > General, will be deselected. To block API Key usage in your environment, you must select this checkbox. Learn more here.

Improved Performance of the Repository Selection Field in Set-Me-Up

The performance of the repository selection field in Set-Me-Up has been improved by promoting a search-first approach.

Cleanup Policies

Support for Vagrant and Hex in Cleanup and Archive

Cleanup and Archive now support Vagrant and Hex packages.

Support for Alpine and SBT in Cleanup and Archive

Cleanup and Archive now support Alpine and SBT packages.

Improved Cleanup Release Bundle V2 Report

The Cleanup Release Bundle V2 report has been improved. Learn more here. 

Support for Conda in Cleanup and Archive

Conda packages are now supported in Cleanup and Archive.

Policy Conditions - Cleanup Packages

Adding Property-based Policy Condition

Jfrog improved package cleanup functionality with a new property-based policy condition. This allows you to include or exclude specific package versions from cleanup, providing more precise control over which packages are retained or removed. Learn more here.

Adding days/weeks selection for Time-based Policy Condition

Package cleanup functionality has been enhanced, allowing for time-based policy conditions to be configured using days or weeks. This new feature enables more precise control over package cleanup based on specified timeframes. Learn more here.

Release Lifecycle Management

Improved Release Lifecycle Management Kanban board

The Release Lifecycle Management Kanban board has been overhauled to offer a more comprehensive overview, prominently displaying failed promotions. Learn more here.

Auto-creation of Release Bundle v2 versions after build promotion

Artifactory now automatically generates a Release Bundle v2 when a build is promoted via the JFrog CLI or REST API. This Release Bundle is also promoted to the build's target repository environment, if applicable. Both copy and move promotions are supported. This feature enhances visibility and control over your release candidate throughout the SDLC. Learn more here.

Evidence

The Evidence service now supports all databases compatible with Artifactory. Additionally, the Evidence service is now enabled by default across all installation types. 

Users can attach external evidence to artifacts residing in a local repository that is part of a virtual repository. Learn more here. 

The `repositoryKey` and `path` fields have been deprecated from the Get Evidence and Search Evidence GraphQL APIs. These have been replaced by the `subject` field, which now encompasses `repositoryKey`, `path`, `name`, and `sha256`.

It is possible to view a list of evidence files associated with a specific package version within a selected repository. For more details, consult the View the Package Evidence Table.

As of Artifactory version 7.111, the Evidence service is available for all installations. Learn more here. 

JFrog Platform Improved Project Navigation

The Projects navigation menu has been updated with UI usability enhancements. It is now located in the sidebar and highlights project filtering, which clarifies context switching between individual projects and the "All Projects" scope.

Support for Reading Permissions Scoped Tokens

Non-admin users can now access the Get User List, Get a List of Groups, and Get All Permissions REST API endpoints by using a scoped token. Learn more here.

Get Token Last Used Information

The JFrog Platform now supports getting a token’s ‘last used’ timestamp when using Get Tokens and Get Token By ID REST APIs.

Supported Worker Features

JFrog now offers support for creating event-driven workers. These workers can be configured to trigger before a token expires.

Additionally, the following events are now supported:

• Alt Response event is now supported.
• Alt All Responses event is now supported.
• Alt Remote Content event is now supported.
• After Download Error event is now supported.
• Before Download Request event is now supported.
• Before Build Info Save event is now supported.

Noticeable features and enhancements 

Xray added support for SBOM component properties in compliance with the German SBOM Regulation (BSI TR-03183) and the Indian SBOM Regulation (CERT-IN SBOM Guidelines).

They also added support scanning podspec.json (extension of Cocoapods).

The Export Component Details v2 REST API now supports passing an array of objects instead of a single JSON. This allows you to generate SBOM reports for multiple artifacts at a time and the aggregated reports will be returned in a “multiple_components_report.zip” file.

Enhanced the Xray-Jira integration by adding the Jira Status Retrieval feature. Xray users can now view the status of related Jira tickets without leaving the Xray platform.

Added an option to exclude specific file names from a scan when they exist in the resource (artifact/build/release bundle).

Added a new capability to Xray policies, allowing a grace period for violations before blocking downloads.

You can now export audit data in CSV format directly from the UI under Curation > Audit. For automation, the same data is available via the Approved/blocked-audit REST API. Get your audit reports easier, whether clicking or coding!

JFrog curations

Curation now allows users to connect repositories by package type, providing a complete overview of all curatable ecosystems within Artifactory. Users can easily manage these connections, view status updates for each package type, and set up automatic connections for new repositories. Disconnection notifications keep users informed, ensuring continuous management and oversight.

Should a blocking action occur during an audit, the system can now automatically generate tickets or notifications via Webhook events. When the curation process encounters a blocked package, an event is triggered and sent to a designated webhook. This event provides comprehensive details about the blocked package, including:

• Package Information: Identifying details of the requested package.
• Requester Details: Information about the user or entity that requested the package.
• Policy Violation: A description of the specific policy violation that led to the package being blocked.

JFrog integrates the Exploit Prediction Scoring System (EPSS) to streamline vulnerability management. EPSS provides a statistical probability of a Common Vulnerabilities and Exposures (CVE) being exploited, allowing security teams to focus remediation efforts more effectively.

A new relaxed condition has been added to the custom CVSS (Common Vulnerability Scoring System) policy. This enhancement ensures that policies will no longer block a corresponding CVE if its EPSS score falls below a pre-defined threshold, providing greater flexibility and improved prioritization.

Enhanced Control & Visibility with New Webhooks and Curation Waivers

Monitoring for Waiver Requests has been enhanced. It is now possible to create tickets or notifications in external systems to track the creation and updates of Waiver Requests and their associated documentation. Two new Webhook events have been introduced specifically for Waiver Request creation and updates, facilitating tracking of these exceptions. For technical details, refer to the Webhooks documentation.

Additionally, a new webhook has been added, dedicated to Curation policy configuration changes. This enables security teams to receive automatic alerts regarding any alterations to Curation policy conditions. This webhook provides real-time insight into policy rule changes, though it does not detect changes in label or package applications.

Finally, the Waiver feature for Curation is now available, accessible via the JFrog jf curation-audit CLI command. This functionality allows for explicit exclusion of specific packages or versions from Curation policy restrictions, enabling precise control over compliance.

API & Ecosystem Expansion

Beyond the new webhooks and waiver capabilities, we're also expanding the reach and support of Curation:

You can now create, read, update, and delete Curation policies and conditions using the REST API. This provides full programmatic control over your Curation rules, enabling seamless integration with your existing automation workflows.

Furthermore, Curation now supports Rust repositories. This extends our robust artifact management and security capabilities to the growing Rust ecosystem, ensuring that your Rust packages are managed and curated with the same level of control as your other dependencies.

Catalog Now Supports Google Maven Repositories

JFrog Catalog solution now officially supports Google Maven repositories. This means you can seamlessly integrate and manage artifacts from Google's extensive Maven repository directly within your JFrog environment. This enhancement simplifies dependency management for projects relying on Google-hosted libraries, ensuring a more unified and efficient workflow for developers.

CLI: See Violations at a Glance!

For those leveraging JFrog CLI for their Git repository scanning, JFrog introduced a valuable new enhancement to streamline your security oversight.

A new "Violations" column has been added to the Git Repositories tab within the Scans List. This means you can now quickly and easily see the violation count for each Git commit directly from the UI. This provides immediate visibility into the security posture of your code at a commit level, allowing for quicker identification of problematic changes and more efficient remediation efforts. No more digging through detailed reports just to get a high-level overview – the violation count is now right there, front and center, where you need it!

Advanced Security: Introducing the Custom Scanner

Advanced Security capabilities are enhanced with the powerful new Custom Scanner. This feature allows you to define highly specific search patterns to detect sensitive information across both your artifacts and source code.

The Custom Scanner is designed to scan both binary and text files, providing comprehensive coverage. This means you can now proactively identify and flag confidential data, proprietary algorithms, or other critical information that might inadvertently be present within your development ecosystem, ensuring a stronger security posture.

Highlights:

• SonarQube Advanced Security is now Generally Available as an add-on for Enterprise Edition and above. It delivers comprehensive SAST and SCA coverage—including open-source and AI-generated code.

• Key AI features are also now GA:

  • AI CodeFix provides real-time, in-IDE remediation suggestions.

  • Autodetection of AI-generated code helps manage and secure AI-assisted development workflows.

These updates empower teams to produce faster, more secure, and higher-quality code—supported by intelligent, automated assistance.

General Availability of SonarQube Advanced Security (Enterprise)

Advanced Security expands core security by supporting open-source code and offers new capabilities, including:

• Enhanced visibility of security and licensing risks for each dependency version in pull requests and overall code.
• Configurable Quality Gates to include dependency risk scores, preventing high-risk dependencies from entering production.
• Configurable company license compliance policy allowing organizations to define and enforce custom policies within SonarQube.
• Immediate insights into project dependency health through the project overview screen, which now displays dependency risk counts.
• Discovery and analysis of dependency risks across multiple applications and portfolios.
• Enhanced API access for SCA results and Software Bill of Materials (SBOMs), enabling seamless integration with other tools and custom reporting.
• Broad and growing language coverage for SCA, starting with Java, C#, Python, JavaScript, TypeScript, Go, Rust, and Ruby, for quick analysis of third-party dependency vulnerabilities and licensing issues.

Static Application Security Testing (SAST) for Kotlin now available (all tiers)

GitLab now supports SAST for Kotlin, including taint analysis, extending security coverage to Kotlin-based projects.

This addition helps teams identify and remediate vulnerabilities early in the development process—bringing the benefits of automated code scanning to Kotlin applications and improving overall application security posture.

Continued additions to secrets detection

SonarQube's secret detection capabilities are continuously improving, now covering over 300 patterns to address the evolving security needs of cloud applications. This includes the ability to detect secret leaks in hidden files and files within directories that start with a dot.

AI capabilities

Leverage AI CodeFix directly in the IDE (Enterprise)

AI CodeFix integration with SonarQube for IntelliJ and VS Code offers developers real-time code remediation suggestions.

Autodetection of AI code (Enterprise)

Autodetection of AI code for Copilot-generated code is not limited anymore to GitHub projects. 

Compliance capabilities

More MISRA:C++2023 rules (Enterprise)

Expanding our MISRA:C++2023 rule coverage for enhanced compliance checks in safety-critical systems, Eficode ROOT now offers early access to MISRA Compliance. 

New security reports for CWE and OWASP Mobile (Enterprise)

SonarQube now provides security reports aligned with the latest CWE Top 25 for 2024 and OWASP Mobile Top 10 for 2024 standards.

Default Quality Gate

As a Quality Gate administrator you can now set a default Quality Gates that is not compliant with Clean as You Code. Learn more here.

Languages

Introducing support for Rust

Initial support Rust offers:

• 85 rules
• Code Coverage import (LCOV and Cobertura formats)
• Cognitive Complexity metric
• Cyclomatic Complexity metric
• Import of Clippy output as external rules (JSON format)

Support for Java 22 

SonarQube now supports Java version 22, ensuring developers can analyze their code with confidence when using the latest Java versions. New Java 22 rules:

• S7466: Unnamed variable declarations should use the var identifier
• S7467: Unused exception parameter should use the unnamed variable pattern
• S7475: Types of unused record components should be removed from pattern matching

Support for PySpark

Support for PySpark, a popular Python API to leverage Apache Spark, adds the help data engineers need to identify and address potential issues in their large-scale data processing workflows. New PySpark rules:

• S7193: PySpark DataFrame toPandas function should be avoided
• S7468: PySpark dropDuplicates subset argument should not be provided with an empty list
• S7469: PySpark's DataFrame column names should be unique
• S7470: PySpark's RDD.groupByKey, when used in conjunction with RDD.mapValues with a commutative and associative operation, should be replaced by RDD.reduceByKey
• S7471: master and appName should be set when constructing PySpark SparkContext and SparkSession

New rules for mobile security

Following are the new mobile security rules that cover the OWASP Mobile top 10 for 2024 security standards. Learn more here.

SonarQube Community Build updated to 25.4.0

Kotlin analysis

For Kotlin developers, Sonar analysis is now 50% faster, thanks to over 80 rebuilt rules supporting Kotlin 2.0 and the new K2 compiler. This update means not only is Kotlin 2.0 and newer supported, but performance has also significantly improved.

Java rules

The following Spring Java rules have been added:

• S7177: Use appropriate @DirtiesContext modes
• S7178: Injecting data into static fields is not supported by Spring
• S7179: @Cacheable and @CachePut should not be combined
• S7180: "@Cache*" annotations should only be applied on concrete classes
• S7183: @InitBinder methods should have void return type
• S7184: "@Scheduled" annotation should only be applied to no-arg methods
• S7185: @eventlistener methods should have one parameter at most
• S7186: Methods returning "Page" or "Slice" must take "Pageable" as an input parameter
• S7190: Methods annotated with "@BeforeTransaction" or "@AfterTransaction" must respect the contract

Language updates

Go 1.23 now supported

SonarQube Community Build now supports the analysis of Go 1.23 code.

PHP analysis and quality profile API changes

Cyclomatic Complexity improvement for PHP

The elsif keyword is now properly included in Cyclomatic Complexity calculations for PHP code, resulting in more accurate complexity metrics during static analysis.

Deprecated and removed quality profile APIs

GitLab has removed the ProfileExporter and ProfileImporter extension points from the plugin API. As part of this change, several related Web API endpoints have been deprecated:

• GET /api/qualityprofiles/exportAPI → use GET /api/qualityprofiles/backup instead

• GET /api/qualityprofiles/exporters

• GET /api/qualityprofiles/importers

For more details and alternative methods, refer to the official Web API documentation.

Key changes in this upgrade:

• Log4j Visualizer sunset
  The experimental Log4j Visualizer, introduced to track Log4j Core downloads during the CVE-2021-44228 response, has been retired. As the industry has moved past the immediate crisis, this temporary diagnostic tool is no longer supported.

• Bower format sunset
  Nexus Repository has sunsetted support for Bower format repositories. Bower's decline in adoption and relevance has led to its deprecation. If your projects still rely on Bower, we recommend migrating to a modern alternative such as npm or Yarn.

In addition to these changes, version 3.80 includes various bug fixes and backend improvements to ensure a smoother and more reliable user experience.

Save on infrastructure: ARM Docker images now available for Nexus Repository

Sonatype has expanded architectural support for Nexus Repository by introducing ARM-based Docker images, now available on Docker Hub. This update offers greater deployment flexibility and enables teams to optimize for cost and performance when using ARM-based infrastructure.

• ARM images are available for Nexus Repository version 3.78.0 and newer

• Find them under sonatype/nexus3 on Docker Hub

• With this change, Docker tags are no longer published to the docker-nexus GitHub repository

• You can alternatively reference tags from the nexus-public repository

This enhancement broadens infrastructure compatibility while reducing operational costs—especially in environments optimized for ARM-based compute.

UI changes

Monthly Request Metrics Available in Usage Center

Sonatype Nexus Repository's Usage Center now offers enhanced visibility into monthly request patterns, empowering users to better understand their Nexus Repository usage.

New Usage Center UI.

The Usage Center now features a "Requests Per Month" panel. This panel displays both the highest and average monthly request counts for the current calendar month, with statistics updated daily.

This new feature offers a clear, data-driven insight into repository activity. It enables administrators to identify usage trends, anticipate potential bottlenecks, and ensure efficient resource allocation. By tracking these key metrics, users can make informed decisions to maintain optimal performance and responsiveness within their Nexus Repository environment.

For complete details, please refer to the Usage Center and Usage Metrics help documentation. Please note that usage metrics are not currently supported for High Availability deployments.

Updates to Licensing Page in User Interface

This August 2025 release includes updates to the licensing page within the Sonatype Nexus Repository user interface. These changes aim to enhance the clarity of our license terms. For comprehensive information, please refer to the licensing help documentation.

Nexus Repository Gets a More Modern and Intuitive User Interface

This release introduces a significant enhancement to the Sonatype Nexus Repository user interface, focusing on improved navigation and a more modern experience.

New Sonatype user interface.

Sonatype has updated the Nexus Repository UI with a responsive, React-based framework, paving the way for future enhancements and delivering a more consistent and accessible user experience.

Key improvements include:

• Modernized navigation: The main navigation is now a collapsible left-hand menu, improving screen space and feature discoverability.

• Clearer access to settings: The “Settings” panel (previously accessed via a cog icon) is now clearly labeled in the side navigation, with all familiar sub-options intact.

• Improved browsing experience: The “Browse” view, once represented by a cube icon, is now directly accessible via the left-hand menu as a labeled option.

These updates simplify day-to-day interactions with Nexus Repository and lay the groundwork for a more intuitive interface moving forward.

[Learn more here.]

New Historical Usage table offers month-to-month insights

A new Historical Usage table has been added to the Usage tab within the Licensing section of the Sonatype Nexus Repository UI. Available in both single-instance and high-availability deployments, this feature gives administrators deeper visibility into usage trends and resource consumption.

The table includes a monthly breakdown of key metrics such as:

• Total unique components stored

• Month-over-month changes in component count

• Total HTTP interactions with format-specific endpoints

• Month-over-month request volume

• Maximum storage space used by components

This consolidated view helps you monitor growth, plan for capacity, and better understand your Nexus Repository’s operational profile.

[Learn more here.]

That’s all for August—see you in September! 🚀