What’s new in Eficode ROOT: October 2023

Fine-grained personal access tokens enter public beta

This release of GitHub Enterprise Server brings the fine-grained access tokens to the public domain. The feature is still in development and is subject to change with later releases.

You can now create fine-grained personal access tokens to your personal repositories or, if permitted, to the repositories owned by your organization as well. Organization and enterprise owners can enable or disable the use of fine-grained access tokens in organization-owned repositories.

With fine-grained personal access tokens, you can create secure tokens with limited access and privileges to resources. Not only can you limit the token to having access to selected repositories only, but you can now define repository permissions and account permissions granted to the token on a very detailed level, making it easy to adhere to the principle of least privilege.

See the documentation for managing your personal access tokens on github.com for more details. 

Enhancements for Advanced Security

No GitHub Enterprise Server release would be complete without evolutionary updates for the Advanced Security pack.

This release includes advanced goodies, like a default setup for code scanning for all compiled languages supported by CodeQL, including Go, Java, and C. Default setup makes it a breeze to quickly enable automatic code scanning without configuring a workflow. Repository administrators and security managers also have the option to choose which languages to include or exclude in the default setup. How convenient.

GitHub Enterprise Server 3.10 also includes public beta support for C# 11 features in CodeQL, as well as support for Swift (up to version 5.8.1) and Xcode (up to version 14.3.1). Swift analysis is not yet supported in the default setup mentioned above, so it requires the advanced setup for the time being.

There’s also a possibility of filtering code scanning alerts by language or file path using search queries language: and path:.

Check out the GitHub Enterprise Server 3.10 release notes for a complete overview of all Advanced Security updates included in this release. 

Control over self-hosted runners

Organization owners now have the option of preventing members from creating self-hosted runners at the repository level, which can improve the integrity and security of your GitHub Enterprise instance.

Projects generally available

GitHub Enterprise Server 3.8 shipped with the first public beta of the new Projects feature (see What’s new in Eficode ROOT: April 2023). Projects has now received the final buffing and polishing it needed to escape for its “beta” label.

Now Projects simply is.

As described by GitHub themselves, a project in the GitHub context is an adaptable spreadsheet, a task board, and a road map that integrates with your issues and pull requests on GitHub, allowing you to plan and track your development work efficiently and effectively.

Projects allows you to create multiple views by filtering, sorting, and grouping your issues and PRs. You can also add custom fields to track metadata specific to your team. A project doesn’t enforce any particular methodology. Instead,  it provides flexible features that you can tailor to fit your team’s needs and processes.

See the Learning about Projects pages on github.com to find out more..

We’re simply scratching the surface of what this latest release has to offer, so head over to GitHub Enterprise Server 3.10 release notes on github.com to learn more about all changes, enhancements, and updates in version 3.10.

Webhooks for emoji reactions

You can now set up webhooks that trigger when someone adds or revokes an emoji reaction. You know, like reacting to an issue or a merge request with an emoji.

Magnificent.

Customizable roles with granular security permissions

Group owners and administrators can now build new custom roles on top of an existing base role. You can take one of the base roles and build your own permission scheme.

This release of GitLab also introduces new granular security permissions, which can be used with a custom role and help build roles that adhere to the principle of least privilege.

Currently, there are a limited number of permissions available for a custom role. But the range of available permissions will be expanded in the coming releases of GitLab.

Check out the release announcements for customizable roles and granular security permissions on gitlab.com for nifty video clips that detail how to take advantage of the new custom roles.

Global id_token for smooth transition from JWT

GitLab 15.9 (Eficode ROOT release 2023-03) announced the deprecation of older versions of JSON web tokens in favor of the new id_token.

In the earlier versions of GitLab, migrating to id_token required jobs to be individually modified to accommodate this change. Starting with this release of GitLab, things just got a lot easier. You can now set id_tokens with a global default value in your .gitlab-ci.yml. which automatically sets the id_token configuration for every job.

See the documentation on id_token on gitlab.com for more details on this one. 

Notifications for expiring accesses and tokens

This release of GitLab also introduces new notifications accesses or access tokens that are getting close to their best-before date.

If a user has an expiration date set for their group or project access, GitLab will send a reminder of the expiring access seven days in advance.

Additionally, group and project access tokens generally consumed by all sorts of automation kit can (and probably should) have some kind of expiration date. Going forward, administrators and group owners will receive an advance notification of the impending expiration.

Bubbling under

As always, what we have above is just the tip of the iceberg. If you’ve been using workspaces in GitLab, the feature has now been expanded to work with private projects as well,  with a possibility for addressing vulnerability status changes in bulk on the Vulnerability report.

Everything we’ve mentioned here so far has been covered in greater detail on GitLab 16.4 release announcement on gitlab.com 

Security analysis on GitLab dashboards

Using GitLab with SonarQube? You’re in for a treat!

This release of SonarQube further enhances its GitLab integration by making SonarQube security analysis an integral part of GitLab dashboards. When your SonarQube instance is configured with GitLab, vulnerability issues get automatically synced from SonarQube to GitLab.

Simply navigate to the Vulnerability Report to see the results of the SonarQube scan. For SonarQube Community Edition users, the vulnerability report contains issues related to the main branch, while Developer Edition and higher gain extended support for providing the report across all branches.

Check out the GitLab integration documentation on sonarsource.com for more details. 

Flex that main branch

On commercial editions of SonarQube (Developer Edition and higher), changing the project’s main branch has now become a breeze. 

Project administrators can easily shift the project’s focus by designating another existing branch as the main one for their project. Changing the main branch doesn’t destroy any history asSonarQube will preserve all of the historical data, analysis, and insights tied to the previous branches designated as the main ones.

Streamlining reviews through SonarLint enhancements

Synchronization features between SonarLint and SonarQube have been enhanced to support “muting” issues directly within VS Code environment before SonarQube even completes its analysis.

For a developer, it allows classifying issues as either “Won’t fix” or “False positive” beforehand. This will prevent them from unnecessarily reappearing in your IDE and from being flagged for review in SonarQube once the analysis is finalized, paving the way for a more streamlined, clutter-free coding and code review experience.

Enhanced cloud secret detection

SonarQube 10.2 expands its cloud secrets detection feature and is now capable of detecting secrets across 29 cloud services, with a comprehensive range of over 60 different kinds of secrets and tokens.

End in sight for Java 11

We all knew it was going to happen one day–and that day is approaching quickly.

The release of SonarQube 10.2 marks the deprecation of Java 11 as a scanner runtime environment. Java 11 will still continue to work as the scanner-side runtime for the time being, but its days are now officially numbered.

SonarQube 10.3, which we anticipate to be released by the end of 2023, will do away with Java 11 runtime support. You must join the Java 17 gang to continue scanning your projects with SonarQube. Naturally, we recommend you do so as soon as possible to avoid unnecessary interruptions to your workflow.

Meanwhile, in the LTS land, the tale doesn’t unfold quite so quickly. While all of this will eventually trickle down to the LTS, that’s not today and not in version 9.9.x. But as soon as SonarQube 10 hits the LTS street sometime in late 2024, rest assured it will be Java 17+ for all.

Fixes on the LTS

The October release of Eficode ROOT also delivers a patch update to version 9.9.2 for SonarQube LTS. This one, like others before it, sticks to the LTS ethos of not breaking things between releases. 

There are also fixes to bugs that in some situations, might have caused SonarQube to crash, corrections to security issues discovered with the earlier versions.

Full disclosure on the SonarQube 9.9.2 LTS patch can be found through release notes for 9.9.2 on sonarsource.atlassian.net. 

Improved Xray user experience

The user experience of Xray features has been improved in multiple ways in our October release:

There are overview dashboards for Artifacts, Builds, and Release Bundles that aggregate vulnerabilities, violations, and security data in one screen.

For build trends, there are overview widgets that aim to help you understand the trend of violations, vulnerabilities, and such between different build versions of your software. You can also easily filter vulnerabilities from the overview widgets.

Xray scanning of Release Bundle v2

This release of Xray enables the support for scanning Release Bundle v2. You can now validate the security risk of a Release Bundle v2 using Xray. In the event that risks are detected in the Release Bundle, you have the option to block its promotion and distribution.

Check out the Scan Release Bundles (v2) with Xray documentation on jfrog.com for a step-by-step guide on using the new feature. 

Miscellaneous improvements and bug fixes

There are also other enhancements and fixes worth mentioning included in this release:

• Artifactory now also supports populating the Docker Project ID field for remote repositories, allowing GCR.io users to utilize their private Docker repositories.
• The number of roles allowed per project has been increased from 10 to 30.
• On Xray, the Contextual Analysis scanners now get automatically updated with the vulnerability database sync without having to upgrade Xray itself.
• On Artifactory, looking up groups using the Synchronize LDAP Groups feature could result in the JFrog Platform UI becoming unresponsive if there were a lot of configured groups. This has now been fixed.
• The Set Me Up screen in JFrog Platform UI could take a long time to load for non-admin users with limited permissions (This has also been fixed.)

Ephemeral agents on Kubernetes

Bamboo 9.3 introduces a new type of remote agent known as an ephemeral agent. These are single-use remote agents run on a Kubernetes cluster, which starts on demand, carries out a single build or a deployment, and then shuts down.

Not only does this allow cost-optimization and “infinite” scalability on public cloud computing resources, but it also makes the whole build environment vastly more secure with pod and container isolation–each agent starts up in a fresh environment, which leaves no room for cross-contamination between builds.

Check out the documentation on ephemeral agents on atlassian.com to learn more.

Support for pull requests from GitHub repositories

Bamboo is now able to detect Pull Requests off of directly cloned and forked GitHub repositories. This feature can be enabled from the plan configuration page or with Bamboo specs.

See the documentation for using plan branches on atlassian.com for more details.

YAML Specs validator  

In the good old days, troubleshooting your Bamboo YAML Specs meant making changes to source code and pushing these "fixes" to the version control system, often in quite a repetitive manner.

Our October release of Bamboo takes away this fun, too, including a new YAML Specs validator that allows you to quickly and reliably fine-tune and validate your YAML Specs right within the Bamboo UI.

The validator is available from the Specs menu in Bamboo’s top navigation bar. To learn more about how it works and what it can do, please head over to Validating YAML Specs documentation on atlassian.com. 

The usual monthly update for Jenkins Core

In October, Jenkins Core on Eficode ROOT gets updated to the latest LTS version complemented by the usual bundle of joy that is the Jenkins Plugin updates.

Due to the inherent uniqueness of Jenkins deployments, as always, a complete list of changes pertaining to your special Jenkins is available via your friendly ROOT support team.

Breaking change of Matrix Authorization Strategy

We are now rolling out the new version of the Matrix Authorization Strategy plugin that we warned you about last month. It will be a breaking change for anyone configuring job permissions programmatically using either Configuration as Code, Job DSL, or Pipeline plugins for doing so.

In all use cases, the previous permissions element has been replaced with a new entries list, which provides a more elaborate element syntax decoupled from the serialized XML configuration format of Jenkins. Please refer to the Matrix Authorization Strategy release notes here for examples.

Another breaking change in Azure VM Agents

Our October release also includes a breaking change in the Azure VM Agents plugin, which affects those using Configuration as Code for configuring Azure VM Agents.

The plugin renames the attribute cloudName to just name. You’ll need to adapt your templates accordingly.

More on this particular change can be found via the release notes for the plugin on jenkins.io.