Checkmarx CxONE 3.64 adds one global switch that disables every AI capability on the platform, including AI features Checkmarx has not shipped yet, because future AI features are tied to the same toggle. Legal and compliance teams are likely to ask about it, so decide who owns the switch and who reports on its state before anyone changes it.
Chapter Navigation
13Release Radar Ep03: New Controls in Checkmarx, OpenText, Sonatype & More: transcript and chapter notes
Release Radar Episode 3 covers 9 enterprise software releases from August 26 to September 4 across Checkmarx, Microsoft, OpenText, Perforce, Sonatype, TestRail and Tricentis. Checkmarx shipped one switch that disables every AI feature in CxONE 3.64, including AI features that have not been built yet.
OpenText AQM added electronic signature re-authentication. Sonatype Nexus Repository 96 introduced audit log retention controls. Tosca Cloud added local groups outside the identity provider. Perfecto 26.9 changed how teams can report failures.
Written breakdowns of every release in this episode:
- Checkmarx CxONE 3.64: Centralize Scan Policy Without Losing Project Control
- Azure DevOps August 2026: Tighter Authentication and AI Review Governance
- OpenText AQM 26.1: Strengthen Traceability, Approvals, and Release Evidence
- Perfecto 26.9: More Accurate Quality Metrics and Broader iOS Test Coverage
- BlazeMeter 3.4: Faster API Monitoring Setup and Clearer Performance Evidence
- Nexus Repository 96: Reduce Azure Artifact Delivery Load and Strengthen Audit Control
- TestRail 10.7.1
- Tricentis SeaLights July and August 2026
- Tosca Cloud September 2026: Strengthen Access Governance and Playlist Configuration
Open (0:00)
Checkmarx shipped one switch that turns off every AI feature on the platform, including the ones that it hasn't built yet. OpenText AQM will demand a password on every single approval signature if that's what your audit team wants. And Sonatype move the audit log onto its own page and also put a retention setting on it. The controls this month seem to have moved up a level. Last month, these vendors put dates on all of our calendars, and this month, they handed us all switches and toggles.
What This Is (0:33)
All of this impacts who on our team is allowed to do what because a switch or a toggle nobody even knows about is probably going to bite you when it comes to permissions and setting everything up. So, let's go through all nine releases and find the ones that actually might change somebody's job description. I'm Chris Carpenter with Merito. Every two weeks, I parse release notes for the tools that our customers actually run. We do it so nobody on your team has to dig through nine sets looking for one line that matters to them.
What you're looking at are all of our blogs that we have for different product releases on merito.com. Everything I cover is written up on all of these different product releases and they are all linked below. The chapters are grouped by vendor, so jump straight to your stack if that's all you came for. Th this one covers August 26th through September 4th and we are starting with Checkmarx. CxONE 3.64 has a new organizations tab and it moves the security policy off the project and onto the control organization itself.
Checkmarx CxONE 3.64 (1:30)
An administrator switches scanners on or off for every repository underneath it as a child. And each of those settings carries a decision whether that project can override it or not. So you lock what's genuinely policy and you leave a door open for everything else. The part here to remember is that most people are going to get this wrong because consistency and control are not the same thing. So teams need to go somewhere legitimate to put in a real exception and without one they're going to go and build a second pipeline that nobody's going to see.
They'll know about it but nobody else will. So take a close look at which settings you'd actually lock and write down who approves an override before you turn any of this on or off. And you can also comment on any of the imported findings as well. So the triage record stays in the same place instead of two different systems. The total is it's only ever as good as the state model behind it.
So agree who's going to own anything that's imported and make sure you make that determination before you publish the first result because people need to know who to go to when they have questions. Governance controls for AI policy and API security. So the other big one from CxONE 3.64 is a single switch that disables every AI capability on the entire platform. The problem with this is that it is user-facing. It's backend and most importantly anything that Checkmarx ships in their next releases will be tied to this toggle.
And I just predict that it's going to be a problem. If someone turns off these AI features, they're going to get shipped features that they don't even know about, they can't use. And this is exactly where Merito can come in and help you with your CxONE platform. So, for the toggle, legal's going to ask for this probably more than people expect. And answering their question is probably like it used to take humans to go through and look to see which feature flags are set.
They're just hunting one feature at a time. And so being able to have this global toggle is going to be it's going to be great. And you're going to want to decide who actually owns it and who's going to be able to report on the state of it because the legal team's going to ask for it. And having one person own it is going to be much easier than a bunch of people trying to dig through there. The next change is a little bit more subtle, but it probably matters just as much.
And this is the state-based policy exemptions. And it allows us to essentially create an exemption. So, we'll be able to approve these exempt states. And now that stops breaking our builds and it stays visible and tracked the entire time. This is probably the most honest version of an exception and it totally beats downgrading the severity so a release can get through the door.
Mark an SCA risk as not exploitable and it comes back when a later scan finds a path that reaches it. So that risk history records why the state changed which is the difference between an automated reversal and an unexplained one. So go and check what your pipeline does with a finding that's just sitting there in the to-verify state because a lot of these gates treat that as neutral and a risk that reopened on new evidence is anything but neutral and it should not merge without being extremely loud. I expect that to trigger a warning and if it does not then you're probably going to have problems. The last one for Checkmarx is exciting.
This one is for the MCP server and it picks up container scanning. So, it will now let somebody triage a risk from inside of an assistant conversation. You can like sit on that for a second. and just let that marinate because now you've got a state change being made in the chat window and that's still a state change on your record. So you have to think through that a little bit but licensing and rolebased permissions do apply to this new this new feature. So it's worth checking the roles that you've given to everybody and making sure that those reading roles aren't the roles that are that are now doing the writing itself.
And then on the DAST side, we also we pick up Chrome and Firefox and there's a crawler built in for single-page applications too. Next up is Microsoft Azure DevOps August 2026.
Microsoft Azure DevOps August 2026 (6:43)
So we'll have some tighter authentication and AI review governance, but most of this is documentation and authentication opens it up here. But the question it puts in front of you is which login method is approved for which caller. And most of us have never actually written that down and put it in any sort of documentation. A person, a pipeline, an agent, a potential third party tool. Those are all four different risk profiles and they usually inherit one control model.
The test is whether your audit trail can tie a deployment back to an identity that somebody's somehow along the lines have approved. And if you can't then find that out now instead of during an incident. This is the Copilot piece and it's one to watch for. Yeah. You can hand Copilot a set of instructions per repository.
So then the review it writes actually knows the conventions and also all of your sensitive areas. So treat that file as engineering policy which means it's going to be version controls and it has a named owner and someone also should be reviewing this on a schedule. What it doesn't do is stand in for a branch policy. it should not be used to replace a scanner and it absolutely should not be replaced for a human being in charge of approving any sort of changes and the measure for the quality is what actually comes back out. That's what you should be gauging and instead of looking at what all of your adoption numbers look like. I feel like a lot of people get those backwards.
They say, "Oh, I've got 400 people using this feature." But, they don't actually look at the slop that might be created. And that all comes in the in the way of a flood of irrelevant comments, and it teaches all of our reviewers to just skim through it instead of actually review the data that's being presented. OpenText, AQM, that's application quality management.
OpenText AQM 26.1 (8:59)
You all might know this by the old name quality center or ALM.NET through all the different ownerships that these tools have had over the years. This is new to the release radar and this release is probably the heaviest governance content in the entire batch for this edition. project reports and business view exports come out of the web client now and you're not tied to somebody's desktop install. If you all remember business views I basically did it in Excel. So you no longer have that feature and it sounds really small until you remember what it actually used to take to build those reports and and then of course if somebody left the org then what happens to the document that was living on someone's desktop that actually built this report. So having it come out of the tool the web client is absolutely huge.
Tighter control of coverage and traceability. So the coverage change is my favorite thing in this window. You can attach requirement coverage to a test and narrow it down by configuration. So the requirement was proved on one platform. It no longer will claim that it's tied to all of the platforms.
You can actually break it down. And there's a site parameter that prevents people from creating new coverage links at all. So you can actually block that. This is what would some people would say this is a strange feature until you've actually watched that coverage position improve overnight and not a single test has been written. So if your coverage map is a controlled artifact, a lot of the life sciences, a lot of CSV, you got to make sure these things are locked down, then adding a link to it is technically a change.
And that change, you need to make sure that you've got the proper approvals and that there's the paperwork that goes along with every one of those changes. We also have our electronic signatures. They have a reauthentication policy and there's three different configurations. You can have a never a once per session and also on every single action. So the notes here they list that they list all three of them but they don't say anything about how you should choose them.
So, take a look at your policy, understand what your auditors are looking for and what level of e-signature you set. You'll choose that by exposure. So, if you have a work a shared workstation on manufacturing floor and if you have a laptop and a locked office, those two are going to have two different risk profiles. two more things that land in this same section and both change who does what. But we have the approval rights. They can actually be they can actually go down to groups now.
So you can submit, you can withdraw, resign and each can sit with different people in your organization and the access to the approval audit trail is granted separately which is which is new. So, this is exactly how you keep a reviewer out of the workflow entirely that you're reviewing. There's also a bulk submission that you can leverage. So, a release package that has like 40 different records. You can go through an approval all in one pass.
Don't tell the auditors that, but that feature is there as well. You can turn that on or off depending on how your workflow is. Perforce had two releases in this window and Perfecto 26.9 leads with the reporting and you can now drop chosen failure reasons out of your totals.
Perforce Perfecto 26.9 (12:53)
You can omit them entirely and that can be done across your report library across your CI dashboard insights and even the heat map. So the underlying results stay exactly where they were. And what that allows us to do is if there's a lab outage that stops dragging down the scorecard that's essentially supposed to be telling us about the product. This one really needs a guard rail because the same feature makes a pass rate look a lot better. If you're especially on like a Friday if you're trying to go home for the weekend, people are excited.
Maybe they've got some plans and they just start excluding some things from the list just to get a good pass rate. So publish a list of what can and cannot be excluded and put a name against each one of those categories. I would watch for the excluded volume and use that as a metric of its own. And then of course a climbing exclusion count is it might actually indicate that your test infrastructure is failing and the product itself those numbers might be just fine. So it's a good metric to keep track of.
Playwright reaches real iOS devices. Of course, this is in beta. So, this is on iOS 18 and later. And the same this is the same connection model that we use on Android. The same side that Android runs.
So, if you standardize on Playwright for web, this one is how iOS stops being the exception that it needs its own tool chain. But again, this is in beta. So pilot it across a few different journeys and then keep your existing suite for anything that might be release blocking. The airplane mode control is finally back on Android 10 Android 10 and later. And the older devices, they now just say that they very plainly can't do it in airplane mode.
So I feel like that's the better half of the change because we used to have these commands. we'd send them and then it would produce no test results. And of course, if a test result that doesn't show, you can't trust it. So that this is going to be a welcomed feature. And there are also two new language support options. We've got English in the United Kingdom context as well as English in a German one.
So, our date formats, currency, address handling, all of those regional builds, they were actually breaking and now we can see it before any of our customers do. Items inside it, they'll probably break your pipeline rather than make it better. So this first one is going to be your Safari navigation through the standard call that fails on two of the new iOS versions and virtual devices for iOS 26.4 onward only run ARM 64 builds and so why that matters would be Intel only binary just it just simply stops working. And the third one is that you have to name the Appium version explicitly when you want a particular one on a virtual device. And none of these show up as any sort of headline or anything like that because the section is titled coverage and they're sitting at the very bottom of it.
So update your supported platform list deliberately and mark which ones which one of these are going to be additions and which ones are exploratory and then which ones are allowed to actually block your release. The beta iOS coverage is it's particular and should sit outside of your certification numbers unless you genuinely want to support that platform. BlazeMeter 3.4 landed the day after Perfecto and performance reports now break down by Playwright test step.
Perforce BlazeMeter 3.4 (16:52)
So go check your flow reports login search cart payment check all of those separately instead of looking at that one number for the whole journey. That number essentially tells you that something got slower but absolutely nothing about where any sort of bottlenecks might be. it's just a YAML setting. So you can keep your old test labels wherever your dashboards and your baselines depend on that old config. And that just means that your naming convention inside your code became reporting vocabulary. There's a test connection button for Datadog and Slack now.
And it checks your settings without you having to build a monitor at all. So, it is one of those things where alerting is part of a control rather than something that you want to bolt on afterward. And a monitor that spots a failure that it can't report on, it does nothing at all. And it actually it gives us this false sense of security. So run it after every credential rotation and anytime that somebody renames a channel because this is exactly where we start to see alert notifications break. Next up is Sonatype Nexus Repository 96.
Sonatype Nexus Repository 96 (18:14)
This is the biggest release in this entire batch and Azure direct download is probably the headline out of it all. On Pro with an Azure blob store, Nexus sends a client straight to the Azure storage with a short-lived signed link. Instead of pushing every byte through the repository server itself for everyone moving big binaries out to build agents spread across multiple regions, that lifts a real ceiling off of the throughput. It validates your Azure permissions when you enable it and it drops it back to the old path whenever the link can't mint. So test the fallback and not just the happy path because the fallback is what your Tuesday morning looks like when a when a credential expires. use your managed identity where the hosting model allows it and then agree to the signed link lifetime with your security team rather than just accepting the generic default.
Audit records become easier to review and retain. So this change I like the most in 96. It's the one that the audit events persist and there's a page in the new console where you can filter them. So you set how long they're kept the retention policy and then you can look at the history for one repository on its own and the design decision underneath is that it deliberately leaves out the routine high-volume traffic. So that's precisely why it's usable and because the audit log that records everything is a log that probably nobody's going to read or at least that's it trains them to skip past it.
That's what I mentioned earlier. So the attribution got fixed for the changes that apply after the fact. So the person who started it is the person named against it. Very important to remember. And then also treat retention as a governed item where an owner and a check that reading that audit log is a privilege rather than a default.
There are two things in 96 that are removals rather than additions. The wizard that got migrated in repository 2 across repository 3 is gone. And then the script creation enforcement, it got tightened across every script operation. And it's a lot more consistent this time. So anyone still running repository 2 is now doing a documented migration as a project of its own and its own downtime conversation.
So a job that is quietly relying on creating a script is about to stop working entirely. Ordinarily the repository 3 those upgrades are untouched but this is a planning note and not a reason to sit still. So, it's not on the calendar yet, but it will be. TestRail 10.7.1.
TestRail 10.7.1 (21:24)
This is a cloud hotfix carrying exactly one change, and it's a performance correction on the 10.7.0 build. In my opinion, a hotfix with no detail is still worth a minute. It's worth my attention. So, because TestRail sits inside of a lot of these release decisions. So when it slows down, we get results that get entered late and then reports get built on the data from yesterday and the approval evidence turns up in the meeting that happens after.
So nobody logs that as an outage and it still moves your go live conversation into stale numbers which can be frustrating especially trying to figure out what the data actually is. So since the notes won't tell you which workflows improved, pick your highest volume ones and then measure them yourself. Tricentis has two releases in this window and SeaLights is the one that's probably the most meaningful.
Tricentis Sealights August 2026 (22:18)
The coverage analysis pulls coverage from every service and every test stage in one view that refreshes about four times an hour. So you'll scope it by lab, by application, by branch or by code label. and a team owning one service and a team coordinating 30, they both get that real answer out of the same screen. What that fixes is the meeting where three people arrive on three different spreadsheets and three different three different looks at the numbers. They all have the same data and the argument ends up being about the numbers instead of about the release. So hopefully that gets addressed now with this update.
Total coverage flatters you and the change coverage is the number that actually tells you something. So code somebody touched this sprint with no execution behind it is the risk. Whatever the overall percentage numbers might happen to say and the failing test, they sit in the same view. So you can see whether a test lands inside the scope you're about to ship. That's a go decision with evidence underneath it rather than a decision that might come with a percentage that's sitting next to it.
Data interpretation and adoption constraints. So read the two constraints before you build anything on top of this. It counts a test by when it ran rather than by its build when it was reported. So, those numbers won't line up in your older they won't line up in your older SeaLights reports, but hopefully they do with this with this release. And the history starts in the middle of July or whenever the customer's success contract drew the line.
So, this isn't a long-term trend yet. You still the numbers are still aggregating. And if you're still working with the integration build concept, you can't have it all right now. Tosca Cloud's September release closes this out and you can build a group inside of a project now without waiting for one to arrive from your identity provider.
Tricentis Tosca Cloud September 2026 (24:28)
It takes roles and workspace access exactly the way that a synchronized group would and that's genuinely useful for a contractor team or a pilot workspace or potentially a program that exists only for 6 months and then doesn't. It's also a second door into your permissions. And a second door is one that probably skips a few review sessions. Your auditors, they'll want local access and synchronized access and they'll want that to be told apart in the evidence. So because the approval story goes behind each one of those, it's different and your auditors will want to see the numbers differently. So, let's count up the switches from this month.
Five Vendors, One Month (25:24)
Checkmarx moved scan policy into the organization and added one button that disables all of its AI. OpenText handled a an approval rights to the groups and then put a reauthentication policy on every signature. And then we had Sonatype that gave the audit log a retention setting and Tosca cloud let an administrator create a group without having any sort of any identity provider. And then we had Perfecto that lets somebody decide which failures count in the numbers that the executives will read. That's five vendors handing out switches and toggles in one month and not one of them says who's supposed to actually own that toggle or switch.
Here's what that actually means. Because an unset switch and a deliberately set switch look identical from the outside and somebody on your team has to own the default. They have to own the exception path and they have to own the evidence that the setting was a decision rather than an accident. And that job is usually nobody's until an auditor asks who chose the value and then it's everybody's problem for about a week. But if you're already working out how to staff that put it in the comments because I'd rather build a deep dive around real questions. That's nine releases and the full written breakdown for all of them are linked below and we also have chapter timestamps.
Close (26:50)
If your month tends to look like this every month, then subscribe because we do this on the first and third Tuesday of every month and it's a lot faster than reading nine sets of release notes yourself. So, please like, comment, subscribe, and we will see you in two weeks.
Frequently Asked Questions
Release Radar Ep03: New Controls in Checkmarx, OpenText, Sonatype & More: questions and answers
Consultation request
Book a consultation with Merito
Use this form to talk through the workflow, platform fit, and delivery priorities behind this video with a Merito specialist.
Discovery
Turn the video into a working plan
Use the conversation to translate what you saw here into a practical next step for your team.
Alignment
Get the right specialist involved
We route the request to the team best suited for platform strategy, implementation, quality, or AppSec delivery work.
Get Started
Secure intake workflow
The request is protected by reCAPTCHA Enterprise and processed through Merito's standard consultation flow.