Release Radar Ep02: Four Vendors Put Deadlines on Your Calendar in One Month

Semgrep turns off the policy screen on November 1. Black Duck pulled Java 8 from Detect, and everything under Java 17 goes in the next major release. Sonatype shipped 4 breaking changes with Nexus Repository 95.

Release Radar reads through enterprise release notes every two weeks, so nobody on your team has to dig through 30 sets of them looking for the one line that matters. Episode 02 covers August 4 to August 21, 2026 with 13 releases, on screen, one page at a time.

Semgrep August 2026 is the one that actually has a timer set to it. Migration to unified policies begins August 24 and the current Policies experience ends November 1. Support can give you room, but not a reprieve. What changes is how enforcement behaves on pipelines that are already running, so treat it as a migration rather than an upgrade.

Black Duck Detect 12.0.0 removes Java 8 outright and points at the EU Cyber Resilience Act as the reason. Everything under Java 17 goes at Detect 13, and Docker Inspector goes with it. That reaches your build agents, your shared images, your developer laptops and any wrapper script that calls Detect.

Sonatype Nexus Repository 95 carries 4 documented breaking changes, and every one of them breaks something that works perfectly well today. None of that shows up in a version comparison.

Checkmarx One 3.62 is the biggest release in the batch. AI Triage and AI Remediation both went generally available on a credit model, with a consumption screen that projects when you run out.

Also covered: Sonatype IQ Server 205.3, TestRail 10.7.0, Perforce BlazeMeter 3.2 and Tricentis qTest September 2026.

Every release covered in this episode is written up in full under product release updates. New episodes publish on the first and third Tuesday of each month.

Open (0:00)

Just told everyone the policy screen they use today switches off on November 1st, and Black Duck just pulled Java 8 out of their Detect product. And also pulls Java 17 on the next major release. Sonatype shipped four breaking changes in their Nexus 95 product, and every single one of them breaks something that works today. And with a lot of other vendors, we've got a lot of dates put on the calendar this month. These vendors have been suggesting things, and this month they actually started scheduling them.

Why this month has a timer on it (0:36)

All of this impacts what our teams do, and because a recommendation can usually wait, a set date is a set date. Let's go through all 13 releases and pull out the ones that actually have a timer set to them. I'm Chris Carpenter with Merito. Every 2 weeks I parse release notes for the tools that our customers actually run, and we do it so nobody on your team has to dig through 30 sets of them looking for one line that matters to them. What you're looking at right now is our own blog pages for merito.com.

What you're looking at (1:05)

Everything I cover is written up on this page this site, and all of it is linked below. The chapters are grouped by vendor, so jump straight to that stack if that's what you came for. And this particular series covers August 4th through August 21st, 2026, and we're going to start with Black Duck. Black Duck Detect BDD 12 changes what gets scanned with Python.

Black Duck Detect 12.0.0 (1:26)

And this one's going to surprise people a little, but if you use the uv detector, detect will now read every dependency group in the file instead of just the default one. So, your linting and your testing packages, they show up for the first time when you run the scan, and your findings counts going to go up the day after you upgrade the first time. And there's a setting that you can use to narrow this down, narrow back a little bit. And there's also a matching pair for choosing the npm workspaces in and out. So, put all of these into a template for your pipelines that they'll inherit and do this because a lot of workspace teams you'll have a lot of teams that leave these out and that'll just be a gap in your inventory.

A bigger item in Detect 12 is a set of dates and Black Duck is pointing to the Cyber Resilience Act. That's the CRA. Java 8 is out of product right now and everything under Java 17 goes away with Detect 13. Docker Inspector goes at 13 as well and support for it on Red Hat and CentOS is already gone in 12 as well. Close look at every place your Detect actually runs because this one has a lot farther reach than most of the other upgrade notes that we cover.

This is going to cover your build agents. It's going to touch your shared images, your developer laptops, and any wrapper script that calls Detect. A scan that passes on old runtime today is no longer promised. It just means that the date hasn't arrived yet. So, as I mentioned the clock is starting for a lot of these and what you should do is go and find every job using Docker Inspector right now while you still have a little bit of time and test out the replacement for it.

One more from Detect and it's kind of a thing that cost somebody an entire day when we're trying to figure out what broke and what's what troubleshooting needs to be done. But, if you use the scan service, a set host address has to get through all of your firewalls first. And the scan fails right after a pipeline change. Your detect config is fine, but the answer sits with your network team. So, book that conversation, get them on a meeting, and book it before you actually do the upgrade cuz they're going to be able to help get you through some of the network and download controls. Checkmarx One 3.62 is probably the biggest release in this entire batch.

Checkmarx CxONE 3.62 (4:14)

And AI triage and remediation both went GA. That's generally available. And the AI triage looks at whether a finding is reachable and exploitable. And the AI remediation product allows us to write the actual fix. And both of them spend Checkmarx credits every time they run.

And there's a new screen showing your balance. And with the announcement we've all been waiting for it to go GA. AI triage looks at whether you have a finding, whether it's one of those are your top consumers. So, it also projects when you're going to run out, which is probably the number that the platform owner is going to care about most. Two limits worth knowing about before you plan the rollout.

Risk orchestration in SAST is only right now. So, you can't start AI triage on a SCA scaffolding from the first screen. And the automatic pull request only works on GitHub repository integration projects, which is not widely seen. It's a shorter list than most people expect. So, take a closer look at which of your projects qualify and see your credit budget before you turn automatic triage anywhere.

Risk orchestration is the new landing screen, and it collects data a little bit differently than how you're used to. So, it collects data from every engine and drops it into a ranked table. And calling it a dashboard really under sells what it provides cuz it's really going to give us just another way to show how work is divided up. Someone can now own how all the work is collected across your team instead of trying to manage it outside of outside of another tool. And I would really take a closer look to show to see what tools and what queues should stay with each of the scanners and then see how the numbers compare to what you already report today.

And the audit trail for 3.6.2 now records what a finding looked like before and also what a finding looked like after. And it captures the person and the time, whether it came from a bulk action or which triage method might have been used. And that's the record that you want someone to see when they ask for a batch of the criticals that got marked down as non-exploitable last quarter. So, it's very good for our audit findings. And two jobs come out of this.

The first is mapping those events to the controls that you already published and then the second is the what your SIEM picks up and because an audit log no one collects is a audit log nobody has. So, we now have We now have the data. Most of us have a dependency gate that somebody quietly switched off and this release tries to explain why and I think it does a pretty good job. If you fail a build over 900 inherited vulnerabilities, your developers learn to work around all of those vulnerabilities. They I'm not going to say they game the numbers, but they know how to work around those vulnerabilities and they know how to how to make the gate pass.

So, 3.62, we scroll into focus here. So, 3.62 lets you narrow that down to one condition, which is the new risk arriving in a production dependency. We'll want to make sure that we be careful with the wording on this because the net of it means that what pull request actually pushes into your branch you protect. It does not mean everything that the scanner noticed for the first time this morning when it actually ran. So, if you get that backwards and you rebuild the same noisy gate your team has already learned how to ignore it.

One more from Checkmarx and it is the AI supply chain piece. And we find the screen here. Okay, there we go. So, finding the AI parts of your stack, it's now a step that you have to build in your pipeline and now you have the capability. So, you're able to run this and it has its own CLI scan type.

What comes out of this is essentially an AI bill of materials where it will name your models, your agents, all of your SDKs, and the various different MCP components. Customers as well as regulators, they're starting to ask for exactly this. So, once you start playing around with this, figure out who actually reads this, who owns it, and where does this artifacts going to live. We have Microsoft's July update.

Microsoft Azure DevOps July 2026 (9:12)

And I wanted specifically to talk about Gradle here. So, for Azure DevOps, this is mostly documentation-led and there's one new task I would say that's worth your time. Basically, ADO now authenticates with your Gradle build. So, you're able to tie your Azure artifacts through a service connection instead of using that credential file that you use in your build file. A service connection hopefully has an owner and a review date and a rotation process and a password in a script is exactly none of those.

Hopefully, no one will notice is on the SSH task itself. Outputs coming back from a remote machine used to be able to run that pipeline login command and July essentially turns that off by default. So, you probably will notice it if you are using it and if you don't use it, then you won't notice it. But, there's also a PowerShell deployment task heading for retirement as well and I would highly recommend you go and count how many pipelines still call it. You can find that pipeline call in our blog post.

I can post it in the comments below as well. It's items in the same update and the first is about our PATs, which is the personal access tokens. A token generally belongs to a person, so it should not be a part of your nightly build. It shouldn't be in any logs. It shouldn't be part of any of that.

And the second is permission performance. And if your groups are nested deeply enough, Azure DevOps slows down working out who can do what. Flattening that helps and I'd say it does help, but you have to make sure that you keep your separation of duties, so your auditors are going to be able to see who is doing what and that's essentially what they're checking for.

Perforce BlazeMeter 3.2 and 3.3 (11:15)

Perforce is next and BlazeMeter 3.2 gives service virtualization a version history on every transaction edit. That's kind of cool. It records who made each change and you put those two revisions side by side and you can also roll back to the one that previously worked. A virtual service becomes a production critical the day that the real system goes dark, which is when people start editing it under pressure. So, being able to have the ability to go back to the one that actually worked previously is going to be huge.

Here's the failure that cost you days without it. Somebody adjusts a stub and the suite starts passing for the wrong reason. Maybe it's doing what you didn't want it to actually do and you release evidence becomes worthless. So, tracking that down, it used to mean that you'd have to start interviewing people and now you just get to look at the difference between the two different scripts. The log analysis reaches multi-tests in 3.2 and it groups what it finds by scenario instead of one giant long list and each scenario will get a ranking and each one of those rankings gives you somewhere obvious to start on a run that potentially covers six user journeys.

So, read that ranking as a recommendation. I wouldn't rely on it 100% cuz it knows nothing about your environment and it has no idea what you agreed to ship, but hopefully it gives you a little bit of extra information to make a decision and go try to find whatever the issue was. Next step, we have BlazeMeter 3.3. This actually came out 2 weeks after the 3.2 and with it came the API monitoring and you can now export any request as a curl command. Your normal values fill in themselves and anything that's marked as a secret will stay as a placeholder in that output.

So, you can now attach a working request to a defect without putting a live token in that ticket that will essentially live on forever. With the API definition feature, we've got the imports. API definition imports retain operational context. So, now you are able to import a Swagger or OpenAPI file, which brings a variable across and not just the shape of the actual request. So, your test arrives closer to being in a runnable state and it doubles as an exit route from another tool that you can actually export OpenAPI.

Fix in our radar agent 1.35, and it fixes the OAuth token request for public clients that are routed through your private router agent. And this was where the public token request, they were sending an empty client secret. So, plenty of identity providers reject that just outright. And you can now go, I would go and rerun those flows after you do this upgrade. Semgrep 2026 July is in this window, and July is where the agentic workflows went into public beta.

Semgrep July and August 2026 (14:40)

And their chain static analysis and their and they essentially fixed the tooling with a model that gets a narrow job rather than like a free hand. So, what comes out is a finding an analysis reads and argues with and hopefully routes onward. That's a very different product from an agent that we turn loose to go fix things on their own, and it's really the only shape that a bank or an insurer can actually put its name to. So, what I would do is point at your code, find where your current rules are a little bit thin, and then hold on to its output and hold that next to what your people have actually found. And of course, record who's actually finding this stuff, and I'd just point out that's do a pilot first, and that pilot will hopefully help you find things and a Q&A of findings that nobody actually owns is going to end poorly.

It's just going to be a very long list of a lot of things probably will stress a lot of people out and not be useful. Multi-license package used to trip your policy the moment any one of its licenses hit a band list. The July changes that to a unanimous finding, so it only gets blocked where every license attached to it is unacceptable. So, for anyone who's running a thousands of open-source components, that clears out that steady drip of exceptions that no one really wanted to follow up on or no one really needed. Semgrep has supply chain incidents can and now be posted to a Slack channel of your choosing.

And the shape of those notifications can be adjusted where you can basically be notified if it's something that you should go look into. When that notification comes in, that answer it's supposed to pertain to your most recent bill of materials. And that'll essentially turn your SBOM generation into a live control. A three-month inventoried list will probably answer a lot of questions confidently. It's kind of like what AI does, but it'll be wrong.

It'll be confidently wrong, which is a very big problem, and you'll believe it because it arrived in Slack. And so, now we've got a way to circumvent that. So, you'll basically set an owner and set a refresh schedule, and you'll decide what happens on the builds where that generation actually fails. Is the one that actually has a timer. So, this is the clock that we were talking about earlier.

So, they put two dates on the calendar. And Semgrep starts moving customers onto the unified policies from August 24th. And by the time you're seeing this video, that'll probably be August 24th. But the screen you use today switches off on November 1st. And Chrome, if you open a ticket, you'll be able to request that they postpone the update, but they can't give you reprieve from the actual update.

So, treat this as a migration and not an upgrade. What's going to change is how you enforce and how that enforcement behaves on the pipelines that you're already running. Before the deadline, you'll want each one of your owners to go to each policy area and write a list of the exceptions. And provide evidence that your critical repos keep their controls. Very important.

So, they didn't know about and those dependencies are They're going to find the dependencies during the actual release, and that's going to be a problem. One more from August, and this one will probably show up on a chart before anyone explains it. It's essentially fixing a bug, and it's making our reports a little more accurate. The count on the projects page now includes findings under review, not just the untouched projects. So, nothing got worse, and nothing got exploited, but every trend line that you haven't relabeled is going to be bending in an upward fashion, and trying to fix reporting logic this week to I would recommend that you fix reporting logic because you don't want to have to try to explain what a phantom spike is, especially if someone had noticed that the numbers were off in the first place.

So, this one is definitely fixable. We just have to fix it before anyone sees it. Sonatype shipped two things during this window, and IQ Server 205.3 is a maintenance release, but it is totally worth a read.

Sonatype IQ Server 205.3 and Nexus 95 (19:26)

So, on this authentication resilience here, we've got these the concept of failed logins, and they used to be really expensive to process. A directory outage would be pushed to it just pushed the server's processor through the roof. And once it one incident would then become two, and your policy checks got super slow. All while they're trying to complete teamwork on that directory, and 205.3 makes that rejection cheap again. So, that dependency that you didn't own in the first place, it can't take your control plane down with it.

And the bigger story from this release is that this now sits on the 205 release train, where reachability analysis now covers .NET. It runs from the command line, and also from Jenkins and ADO and Bamboo and GitHub Actions and GitLab. So, that changes the question because you stop asking whether it's a bad library that's bundled, and you start asking whether your code actually calls it. Most of a critical backlog turns out to be shipped, unused, and mostly harmless. And proving that gives your engineers their gives them a lot of time back.

It also creates a decision because somebody has to be allowed to sign off on a not reachable result, and they have to be able to visit it later. There's also a second win for Java teams where the components that they've got, they used to be buried inside of a fat jar, and now they can get their own status. So, those were all inner builds all along, and packaging was the reason that no one can see them. The firewall also pulls the whole waiver process inside the product. A developer usually requests one.

And the administrator approves or rejects it, and a renewal prompt goes out before anything lapses. So, take a closer look at who's allowed to approve, and how long that waiver can last, because that's where I see a lot of programs leak. Next, for breaking changes. Every one of them, as I said before, breaks something that worked perfectly well in your [environment] today. Those that mix and or need any sort of brackets added, or they result to something that you never intended.

That can be really problematic. And publishing a duplicate to Ansible Galaxy, it now answers with a different code. So, if you've got an old pipeline in there that matches, then it will now fail. There's There is a search index that you need to rebuild, and it needs to have certain permissions for that setup. And also, there's a little bit of custom code that needs to be worked through.

It'll just need some slight touches. But, none of that shows up in a version comparison. So, you'll need to walk your selectors. You'll need to look at your API callers, and also your pipeline logic. And do that before you actually go into upgrade mode.

If you need [us] to come in and kind of walk you through some of that, we're glad to help. TestRail had a hotfix earlier in the month, and it fixed some custom field behavior that an administrator would go in, and they would adjust a configuration and it wouldn't essentially take.

TestRail 10.6.2 and 10.7.0 (22:53)

Those custom fields they had a some risk ratings and they also had some compliance classifications. So, you're you had an edit that would essentially misbehave. Your saved filters only returned half of an answer. A substantial one in 10.7.0, which hit the default track on August 19th, so very recently, importing a batch of test cases or moving a suite no longer waits for TestRail and it tallies every open run. And so everything's getting a little bit faster.

Anyone running hundreds of live tests had to it turned to suite maintenance and it turned into a scheduled event with a calendar invite essentially. So, we no longer have to wait for the suites. They're much faster on this release. That speed comes with a little bit of a trade because your totals can be briefly out of sync and they can still describe the state before your edit. That number on the screen, it's not always the number of record and that's more of a policy question rather than a defect.

So, decide who's allowed to reshape a suite while the go live decision is still open and which refresh you'll treat as the real one. And move your big restructuring work away from any of your gate windows because that's what's going to cost you nothing and it's going to be just a matter of re-suite re-sequencing and your order of operations. Leaving an admin screen mid-edit will now prompt you before you actually before you lose the change. And that matters because a new API key used to display on the screen and then it never actually exists. So, your integrations fail a later because you gave a key to somebody and then you weren't able to actually accept it and no one can say which key the system actually thinks is the live key.

Also have quite a few reliability fixes. There are 12 in total and it's great to see that TestRail's investing in their product, but this is the one that this is the one in here that's the biggest is the bulk editing. So, when you're editing more than 100 test cases all at once, it was writing to those custom fields into the wrong places and that one corrupted the metadata for your release and a lot of those gates read from those metadata fields. So, check anything that you bulk edited recently and make sure that this latest release makes those issues not an issue anymore. Tosca Cloud's August release lets the contributor role delete assets and folders.

Tricentis Tosca Cloud and qTest (25:47)

And this one this update actually rewrites what that role means and most of us to be honest, we handed out this role when we couldn't delete anything. So, a folder that looks dead to one team, it's often popping up on another team's test suite or even worse, popping up on a playlist that overrun that runs overnight. And what you should do is you should map which workspaces has the things that you cannot lose and then find out who owns each of those modules underneath them. qTest September notes This one's kind of a big one cuz we mentioned it last release radar knowing that it was going to come down the pipe, but every qTest Manager user is switched onto a refreshed interface and nothing else moves underneath it. So, all of your cases, all of your integrations, and all of your execution history, it'll all stay exactly where they are. The fun part is that you can actually decline it.

And declining it freezes those users out of everything that Tricentis builds next. So, you're going to want to treat this as a dated exception where you need to track whose name is actually on that exception because you're not going to be able to see who is on the old interface. They're just you're going to have features that show up in future releases, and these people will not see them, and you will not know that they do not have them.

Four vendors, one month (27:33)

The dates for this month, we have Semgrep's old policy screen. That goes on November 1st. And the migration for that starts on August 24th. We've got Java 8, and that's out of the Black Duck Detect. And everything under Java 17, that goes in the next release.

You're not You're just not going to have it. And Docker Inspector goes with it as well. Nexus 95 had four breaking changes. They reached their default track on August 19th, so that is exciting. That's four vendors in one month, and every one of them picked a date instead of making a recommendation.

By picking a date, I mean they are actually forcing their users to make changes within their organization and their platform. So, do plan on making upgrades. And if here's what it actually means because a recommendation really sits on a backlog, and a set date puts that work on the calendar. So, somebody on your team has to own the upgrade process, and someone has to plan and road map and figure out the inventory of everything that breaks with that next release. And then that evidence, of course, you've got to control what evidence you have for the upgrade and make sure you planned it accordingly.

So, that job is usually it's not really a built into anyone's week and it becomes everybody's problem. So, if you're ready if you're already working out how to staff any of this, put it in the comments and because I'd rather help you build and rather build a deep dive around any of those real questions that you have and we can build those into the next release radar or we can make an entirely new video. 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 hopefully it's a lot faster than reading through 13 sets of release notes all by yourself.

Close (29:18)

Again, if you have any questions, put them in the comments and I'll make another video around your actual questions. So, again, like, subscribe. Thank you for watching. Appreciate it. My name is Chris Carpenter with Merito.