NETGEAR Enterprise’s first APEX and APEX MSP partners give customers access to validated network expertise  

Posted in Commentary with tags on October 2, 2026 by itnerd

NETGEAR today announced that Thomas-Krenn.AG and Connectivity Warehouse have become the world’s first partners to achieve APEX and APEX MSP certification, respectively, through the NETGEAR DRIVE Partner Success Program. For their customers, these certifications mean one thing above all: the engineering, sales, and service delivery capabilities of the team managing or installing their NETGEAR network have been independently verified before they ever arrive on site. 

When a network problem stops a production line, delays patient care, or takes down a multi-site organization, customers need answers fast. Whether they get them depends on whether their partner has the right skills in the room. NETGEAR introduced the DRIVE Partner Success Program in November 2025 to give customers a clear way to identify that expertise. Rather than recognizing partners for what they purchase, the program certifies them for what they can do: the engineers they have trained, the customer deployments they have validated, and the service practices they have implemented. 

Connectivity Warehouse — first APEX MSP partner 

For businesses that rely on a managed service provider to keep their network running, it’s important that the partner they choose will remain accountable even if something goes wrong six months after installation. APEX MSP is the DRIVE program’s highest tier, requiring partners to qualify three certified post-sales engineers and pass a live virtual audit of their IT service management practices, in addition to the engineering and sales certifications required for APEX. Connectivity Warehouse, a Dallas, Texas-area networking solutions provider serving offices, healthcare facilities, warehouses, and multi-site organizations, is the first partner worldwide to meet that standard. Its customers now have independently verified assurance that the team managing their NETGEAR infrastructure has been evaluated on service delivery, not just product knowledge. 

Thomas-Krenn.AG — first APEX partner 

Customers who work with Thomas-Krenn.AG to build server and storage infrastructure have historically needed separate expertise for the network connecting those systems. APEX certification changes that. Thomas-Krenn.AG, which has manufactured custom server and storage systems at its facility in Germany since 2002, has now certified its engineers and sales staff on NETGEAR infrastructure, meeting every APEX requirement including validated customer success stories. The businesses it serves in the defense, industrial, data center, and public sectors can now work with a single team qualified to design, deploy, and support both the server platform and the NETGEAR switching infrastructure that connects it. 

Further information about the NETGEAR DRIVE Partner Success Program is available at www.netgear.com/drive 

ThreatLocker CEO on Cyber Awareness Month: 5 Ways Businesses Can Limit the Damage From One Bad Click

Posted in Commentary with tags on October 2, 2026 by itnerd

As Cybersecurity Awareness Month kicks off, Danny Jenkins, CEO of ThreatLocker,  says businesses should look beyond simply training employees to spot phishing emails and focus on building security controls that limit what an attacker can do when someone inevitably makes a mistake.

Danny has outlined five practical steps businesses can take to reduce their exposure:

1. Don’t let one bad click become a breach.

“We spend a lot of time telling employees not to click suspicious links, but the reality is that someone eventually will. Good security isn’t about expecting people to be perfect. It’s about putting controls in place so one mistake doesn’t give an attacker the keys to the entire organization.”

2. Make “default deny” the default.

“If an application or process doesn’t have a legitimate reason to run, why should it be allowed to run? A default-deny approach changes the equation from trying to identify everything that’s malicious to only allowing what the business has already decided it trusts.”

3. Give users and applications only the access they actually need.

“Least privilege is one of the simplest ways to limit the damage from a compromised account. If a user, application or service doesn’t need access to a particular resource to do its job, that access shouldn’t be there in the first place.”

4. Treat remote access as an attack path that needs to be controlled.

“Remote access is essential for modern businesses, but every remote connection is another potential path into the environment. Companies should be asking who can connect, what they can access, from which devices, and whether that access is still necessary.”

5. Reduce the attack surface before attackers find it.

“Security teams can’t protect what they don’t know they have. Unused applications, outdated software, unnecessary services and forgotten remote-access tools create opportunities for attackers. One of the most practical things a business can do is regularly remove what it no longer needs.”

Danny also recommends combining these technical controls with ongoing employee awareness training, strong identity security, network segmentation, software updates and monitoring. ThreatLocker’s Cybersecurity Awareness Month guide covers these and other practical measures for businesses and consumers.

Your WAF is a lovely front door. Such a shame the attackers found the side entrance 

Posted in Commentary with tags on October 2, 2026 by itnerd

The Abstract ASTRO team have been studying AI attack agents with Eyal Sela & Gambit Security and have found some interesting playbooks. They just blogged about this late yesterday evening.

One small yet interesting piece: a method for finding the real server behind your CDN. They check SPF records, the staging subdomain someone forgot to proxy (oops), and your favicon hash sitting in Shodan. Once they find your origin, they go straight to it and your WAF never gets a vote.

They’re tidy, too. Tools get shredded, logs get scrubbed, and timestamps get backdated before you’ve finished your coffee.

But the nice thing about robots is they’re lazy in very predictable ways. And their cleanup routine reads like a checklist of commands your web server should never run. Thanks for the detection list, guys!

It’s all written up: a script to find your own origin leaks before they do, plus managed detections that fire while the attacker is still on the box (not three days later in a log review).

Homework for this week: does your origin only accept 80/443 from your CDN’s ranges? If you’re not sure, the answer is probably no.

Automotive SBOM market projected to quadruple as security demands expand 

Posted in Commentary with tags on October 2, 2026 by itnerd

The global automotive Software Bill of Materials (SBOM) market is projected to grow from $440 million in 2026 to $1.8 billion by 2034, according to a new Fortune Business Insights report.

The market is projected to grow at a 19.3% CAGR from 2026 through 2034, driven by software-defined vehicles, cybersecurity regulations, complex software supply chains and lifecycle vulnerability management.

Electric vehicles are projected to be the fastest-growing propulsion segment at a 22.4% CAGR, while buses and coaches are projected to be the fastest-growing vehicle segment at 23.7%. Tier 2 and lower-tier suppliers are projected to grow at 22.0%, while professional and managed SBOM services and vulnerability correlation, VEX and remediation-management solutions are each projected to grow at 20.4%.

The U.S. market is estimated at $80 million in 2026, representing approximately 19% of global revenue, while China is estimated at $110 million, or approximately 24.8%. The report also points to manufacturers increasingly moving from periodic SBOMs toward continuously generated SBOMs integrated into development and DevSecOps workflows.

Matt Wyckhouse, Founder & CEO, Finite State:

“The interesting thing about the growth of the SBOM market is that the SBOM itself is becoming table stakes. The hard problem isn’t producing a list of components; it’s continuously determining what’s actually inside increasingly complex vehicle software, whether a newly disclosed vulnerability creates real risk, and how quickly manufacturers and suppliers can respond. In automotive, that requires going well beyond traditional SCA and analyzing the firmware and binaries that actually ship in the vehicle.”

SBOM is one of the best ways to ensure that you don’t get pwned. Everybody should insist of seeing one before engaging a service or buying a product. Cars are a good example seeing as third party products are inside cars these days. If that happens, companies will get on board quickly.

OpenAI Proves Again That It Cannot Be Trusted On A Pair Of Fronts

Posted in Commentary with tags on October 2, 2026 by itnerd

If you needed more of a reason to not trust OpenAI, here’s a couple to choose from. First there’s this:

OpenAI has fired three researchers for allegedly mishandling information, including work that involved an external organisation that analyses artificial intelligence (AI) models.

“Our investigation confirmed that these individuals mishandled sensitive information outside established company procedures, violating our policies and breaking the trust essential to our work,” a spokesperson told the BBC.

The ChatGPT-maker did not name the sacked workers, but at least two of them were involved in safety research at the firm.

Gee. That looks really sketchy. Like OpenAI has something to hide. Maybe I am being cynical here. But if you combine it with this disclosure, maybe not:

Artificial intelligence leader Open AI said a rogue agent accessed a second NSW government website in June, with authorities only now made aware.

The NSW Premier’s Office released a statement on Friday night revealing OpenAI had advised the government of a “misalignment” involving a rogue AI agent which had accessed public data on a NSW government web application.

“An OpenAI model accessed a National Parks and Wildlife Service web application containing historical information and data on fires in NSW,” a government statement read.

“It’s understood the incident occurred in June 2026 and was validated by Open AI and reported through to NSW government on 1 October 2026.”

The statement advised current investigations had not identified any unauthorised access to personal information.

This comes after this incident which is also in Australia where an OpenAI agent accessed an Australian website in a rogue manner. If you combine both of those incidents, this looks really sketchy to me. And what it says is that OpenAI cannot be trusted. They clearly don’t have their house in order and you have to question if it will ever get there.

UPDATE: Commentary has come in from the following sources:

Willy Leichter, CMO, PointGuard AI (https://www.linkedin.com/in/willyleichter)

“The Australian breaches point to failures in containment, not an inevitable consequence of AI. OpenAI and other frontier model builders, along with any organization deploying agents, need rigorous operating procedures, restricted access, strong guardrails and immediate kill switches. Testing is no excuse for unauthorized actions. Organizations that recklessly build or deploy agents should face direct legal accountability for resulting harm. Greater autonomy must come with greater responsibility.”

Seemant Sehgal, Founder & CEO, BreachLock (https://www.linkedin.com/in/s-sehgal)

“A second disclosure in a week from the same AI provider against the same government shifts the conversation from whether individual incidents will happen to whether the party deploying these agents can be meaningfully held accountable when they do.

“An AI agent cannot face consequences for its own actions. It cannot be fined, suspended, or named in a court filing, which means accountability has to live with the organization that built and deployed it, through clear ownership, documented authorization scope, and real notification obligations when something goes wrong. AI companies that build human accountability into their processes will be the ones governments and enterprises can actually work with.”

Jeremiah Fowler, Security Researcher, Black Hills Information Security (https://www.linkedin.com/in/fowler-jeremiah-26814ab9)

“With the tidal wave of recent incidents it is clear that we cannot treat AI guardrails as if they are the same thing as security controls. Prompting an AI agent not to access something is different from technically preventing access. We have entered a new world in terms of speed and scale. An autonomous agent could potentially make thousands of decisions and interact with multiple systems before human moderators can realize it has crossed the lines. I think in the very near future we will see individual countries pass regulations that hold AI developers accountable for the actions of their agents. Once this happens there will be legal and financial penalties that will force companies to add guardrails or a kill switch. Until that happens we are in a wild west scenario of an unregulated industry that is off to a difficult start keeping AI agents contained.

“In my opinion, any organization that deploys autonomous agents and has an ‘incident’ should be ready to provide the owners or administrators of affected networks and systems with full transparency of what happened and how it happened. This would include details on what the agent accessed, which credentials it used, what commands or requests it issued, what information it retrieved or modified, and why its controls permitted those actions.” 

Jacob Krell, Sr. Director: Security AI Solutions & Cybersecurity, Suzu Labs (https://www.linkedin.com/in/jacob-krell)

“The second New South Wales incident makes it harder to describe these events as isolated misfires. A pattern is emerging, agents take a broad hand to their objectives and reach for any system or data source that might help.

“That risk becomes harder to control when agents operate in swarms. One agent can find a route, another can test it and a third can use the result. Monitoring a single session will miss the larger operation unless it captures agent-to-agent messages, shared state and the combined objective.

“The controls need to sit outside the models, with real-time visibility across the swarm and automatic blocks on unauthorized systems. Accountability also has to cover the people and company that gave the agents those permissions.

“No personal information was accessed in this case. That is a fortunate outcome, not evidence of effective control. OpenAI has already had to discover and disclose unauthorized activity after the fact. The question now is how many more incidents are waiting in its logs.”

Nearly 20 million Minecraft player records are allegedly for sale

Posted in Commentary with tags on October 2, 2026 by itnerd

Created by Markus “Notch” Persson and developed by Mojang Studios, Minecraft has over 212 million monthly active players, and now the players’ data surfaced in an alleged 18 million breach

Two posts on underground cybercrime forums claim that Minecraft players’ data has been breached. One threat actor says 18 million user records are for sale, while another post cites a more modest 9 million records.

Cybernews researchers investigated the claims, and here is what was found:

  • Supposedly, different datasets appear to be the same 1,000 records.
  • The sample contains usernames, email addresses, and, in some cases, password hashes. 
  • The records also appear to have been collected from specific Minecraft servers, with only 3 unique servers appearing across the sample.
  • Information could be used for credential stuffing and social engineering scams, particularly if email addresses are paired with passwords victims have reused elsewhere.

The team found that email addresses in the sample appear in Have I Been Pwned and are referenced in multiple infostealer combo lists. This suggests that the data source may be infostealer malware.

For more information, read the article here:

https://cybernews.com/security/minecraft-players-data-breach

Researcher finds fake data could trigger Japan’s national emergency alert system

Posted in Commentary with tags on October 2, 2026 by itnerd

Japan’s nationwide J-Alert emergency warning system lacks encryption and a mechanism to authenticate the source of data transmitted via satellite, creating the potential for specially crafted fake data to trigger false emergency alerts, according to a Kyodo News report.

Yudai Kirishiki of Tokyo-based cybersecurity firm Unknown Technologies identified the issue after analyzing a J-Alert receiver previously used by a local government that was sold on the secondhand market. Testing found that the receiver could not distinguish fake information formatted like legitimate J-Alert data, demonstrating that a third party could potentially transmit a false warning.

J-Alert distributes urgent information about earthquakes, tsunamis, ballistic missile launches and other emergencies from government agencies via satellite to receivers operated by municipalities and other public organizations.

A source at Japan’s Ministry of Internal Affairs and Communications acknowledged the security issue, while an official said the government continues to work to ensure stable operation of the system.

ㅤLarry Pesce, VP of Services, Finite State:

“Two things in this J-Alert story jump out. First, the claim that satellite attacks “weren’t considered a real threat” in 2007. Brazilian pirates had been hijacking US Navy satellite transponders for decades by then, and Captain Midnight took over HBO’s satellite feed in 1986. Unauthenticated satellite traffic being spoofable was not a new idea.

“Second, and more important: the researcher got a decommissioned receiver off the secondhand market. Disposal instructions went out after the fact. Once an adversary has the hardware, “we can’t share details for security reasons” stops being a control. They can pull the firmware, reverse the protocol, and test spoofed alerts against the real parser until it works. This is supply chain and lifecycle risk in its plainest form: sensitive hardware will leave your control, so design as if it already has.

“The fix here isn’t exotic. Public alerts don’t need to be secret, they need to be signed. Receivers that verify the source would make a drone and a stolen receiver far less useful. For a system that can move an entire population, that should have been in the original design.

“Once a decommissioned receiver shows up for sale, the government’s decision not to share details ‘from a security standpoint’ stops meaning much. An attacker with the hardware in hand can extract the firmware, reverse engineer the protocol, and test fake alerts against the real thing until one works. Sensitive hardware will eventually leave your control, so you have to design as if it already has.”

“Re authentication: public emergency alerts don’t need to be secret, they need to be trustworthy. A receiver that can’t verify who sent a message will believe anyone with a transmitter. Digital signatures are a well-understood fix. Leaving them out of a system that can move an entire population was a design choice, not a technical limitation.

“The problem isn’t that J-Alert is unencrypted. It’s that it can’t tell the government’s warning from anyone else’s.”

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“A satellite link delivers data. It does not prove who sent it. If a receiver validates only the packet format, an attacker can impersonate the system from the ground.

“Japan’s J-Alert system exposes that gap. Kyodo reported that data sent through its satellite channel is unencrypted, and the receiver has no way to verify its source. Yudai Kirishiki of Unknown Technologies tested a receiver formerly used by a local government and found no electronic signature checks. The receiver accepted J-Alert-formatted data transmitted from an elevated location, such as a drone.

“Brazil had its own emergency-alert failure in June, when credentials tied to two Pará Civil Defense agents were used to send false alerts through the national platform to areas those accounts were not authorized to reach.

ㅤJapan and the rest of the world needs to figure this out. Unencrypted communications in 2026 are bad and need to be killed off quickly. Because this is a horrible place to be in.

NIST finds 5G devices remain vulnerable to fake base station attacks 

Posted in Commentary with tags on October 2, 2026 by itnerd

A new NIST report found that attackers can use inexpensive, off-the-shelf hardware and software to impersonate legitimate cellular infrastructure and exploit vulnerabilities in 5G communications.

False or rogue base stations mimic legitimate carrier equipment and attempt to trick nearby devices into connecting to them. NIST tested six simulated attack scenarios and found that while 5G security improvements have reduced risks including privacy breaches and location tracking, devices remain susceptible to denial-of-service attacks that can degrade or disrupt cellular service.

NIST said the attacks can exploit vulnerabilities that occur before a device has authenticated with the network. The agency identified areas where standards and device-configurable protections could be improved and is accepting public comments on the findings through October 30.

ㅤJacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“Denial-of-service is the attack where a locked door is still a failure. An attacker does not need to get inside. They only need to stand in the doorway and stop everyone else from getting through. That is why these attacks are so hard to prevent, normal security and recovery rules can become the thing that keeps legitimate users out.

“That is what NIST found in its new 5G report. The false base station acted like a fake cell tower with a stronger signal, so phones chose it over the legitimate network. 5G authentication worked like the lock, the rogue tower could not complete a fake registration or access protected information. It could still reject or ignore the phone’s connection attempts, leaving the handset stuck retrying the wrong tower. In one test, that cycle lasted about 12 minutes.

“Monitoring is how operators see someone blocking the doorway. Repeated connection failures, one cell suddenly overpowering its neighbors, and many devices repeating the same failed process can distinguish an active attack from an ordinary outage. The lesson applies well beyond cellular networks. Encryption protects data after a connection exists. Monitoring tells defenders when the connection itself is being deliberately prevented.”

ㅤ

John Strand, Owner, Black Hills Information Security, Inc.:

“Cell phone infrastructure attacks have long fascinated me and a number of people at Black Hills Information Security. This isn’t mainstream security research. It’s not like EDR or Apache, where tons of organizations have access to the software and can test it. Setting up femtocells and intercepting cellular communications usually takes very specialized equipment, sometimes available only to government or law enforcement agencies.

“None of this is new. We’ve seen versions of these techniques in Mr. Robot and Silicon Valley, and a lot of them are actually viable. But testing can run into FCC restrictions, which means many security testing firms don’t touch this area. That leaves a real question. How thoroughly are these vulnerabilities being validated, and do we get a chance to address the full attack surface?

“These are the kinds of forbidden technologies I find fascinating from a security perspective. I relish any chance we get to test them.”

ㅤTesting technologies such as 5G are great as it really focuses attention on them. Addressing any vulnerabilities found in these technologies is a different matter entirely.

The Dutch Institute for Vulnerability Disclosure Pwned By AI

Posted in Commentary with tags on October 1, 2026 by itnerd

The the Dutch Institute for Vulnerability Disclosure has apparently been pwned. That in itself is not news. What is news that is was pwned by AI:

Late last week, the organization said it had been hacked after seven years of uneventful operations, with the intrusion carried out autonomously by an AI agent.

The organization described the attack as “loud and very very messy,” leaving plenty of evidence to help them reconstruct what happened, but the incident was serious nonetheless.

“This is an attack we have not seen before. Not because it’s our first, but because the modus operandi indicates that this is an agentic AI-powered attack,” DIVD explained.

The organization launched an investigation and informed the police, the Autoriteit Persoonsgegevens (data protection), and the National Cyber Security Center (NCSC).

In an update on Monday, DIVD provided additional information about the incident but withheld full details to avoid influencing the investigation or putting more victims at risk.

John Strand, Owner, Black Hills Information Security (https://www.linkedin.com/in/john-strand-a1b4b62)

“This story highlights what AI is really, really good at. Exploit development isn’t like Hollywood. It takes a lot of fuzzing, scripting, and grinding through different possibilities. It’s tedious work, and that’s exactly the kind of research AI is suited for. Running that research in parallel to find zero-days is a natural fit. I think that’s the biggest lesson we should take from this story.”

Darin Fredde, Sr. Director of Technical Marketing Engineering, Ridge Security (https://www.linkedin.com/in/darinfredde)

(https://www.linkedin.com/in/darinfredde)

“When a vulnerability disclosure organization gets breached, the response matters as much as the breach. DIVD detected the intrusion within a day, stopped the attackers from moving deeper, and, with Merlon Security, identified two Zammad zero-days (CVE-2026-102489 and CVE-2026-102490). They reported them to the vendor three days after the breach and began notifying exposed owners two days after that. That is coordinated disclosure doing its job: one organization’s incident becomes everyone’s early warning.

“AI-enabled offense is helping us find subtle weaknesses faster, and like every tool ethical hackers and threat actors have always shared, it cuts both ways. What’s new isn’t the dual-use nature, it’s the tempo and economics. Google’s threat intelligence team reports that likely AI-discovered vulnerabilities lead to remote code execution at nearly twice the rate of others, and Mandiant finds exploitation now arrives, on average, before the patch. DIVD itself described the attack chain reaching root ‘in seconds.’ In my view, ‘cat and mouse’ no longer describes where we are. We’re moving toward machine-speed, multi-stage attacks, and no organization is immune.

“The answer is continuous offensive rigor: test, find, fix, prove the control works, and keep testing as the environment changes. Public counts likely understate AI’s role in discovery, which makes continuous testing and coordinated disclosure more urgent, not less. We cannot do this alone.”

Steven Swift, Managing Director, Suzu Labs (https://www.linkedin.com/in/steven-swift-5238956a)

“DIVD described the agent used in this attack as being sloppy, and leaving artifacts where the agent left comments where it over-explained the activity it was performing. And that generally the agent was loud, messy, and disorganized.

“Despite that, it still successfully exploited a public host by chaining two zero days to escalate privileges to root, and then gain RCE, allowing the attacker full permissions to execute whatever follow up they wanted.

“Despite flashy headlines, there wasn’t much novel about this attack. Two zero days were burned to gain access. Its not particularly common to utilize zero days to gain access, it’s much much more common to simply exploit unpatched systems, because so many systems don’t patch promptly. So the specific CVEs were new, but the techniques were old.

“Once access into DIVD systems was gained, the attack moves to what is called the post exploitation phase. This is where the attacker has access inside the environment, and can choose what they want to do with that access. In this case, it appears they set an agent loose rather than using any of the pre-existing post exploitation toolkits. We’ve had years of sophisticated tools that skilled attackers can use in this phase of the attack. But we didn’t see that here. Instead, and agent poked around the network, made a lot of noise, connected to various systems, stole some data, and generally left a lot of logs and evidence for DIVD to alert on and respond to.

“The good news for DIVD is that the attack left a lot of evidence behind. This made detection easier, and provides adequate artifacts to review during the investigation to put together a timeline of activity.”

This attack might have been sloppy. But OpenAI for example has agents who are not sloppy. This an example of that. And make no mistake that one of those agents are coming for you real soon.

Liquibase Secure 6.0 Brings Database Change Governance to Enterprise Scale

Posted in Commentary with tags on October 1, 2026 by itnerd

Liquibase today announced the general availability of Liquibase Secure 6.0, a major release that makes it easier for enterprises to automate and govern database change across mission-critical applications, data products, and AI initiatives.

The way enterprises build and deliver technology is changing quickly. Application and data teams are releasing more often, developers have more autonomy, and AI is dramatically increasing the volume of code and database change enterprises produce. But the controls around database change have not kept pace. Policies are still often scattered across pipelines, configuration files, repositories, and teams, making them difficult to manage consistently as organizations scale.

Liquibase Secure 6.0 changes that model by moving database change governance from pipeline-by-pipeline configuration to enterprise scale. Organizations can see database change across the enterprise, understand and remediate issues when they occur, define and manage policies from one place, set governed exceptions when they are needed, and control who has the authority to manage those policies. It gives enterprises a simpler way to answer three questions that become harder as the volume of change grows: What changed? Was it allowed? Who controls the rules?

Change Intelligence Turns Database Change Visibility Into Action

At the center of Liquibase Secure 6.0 is Change Intelligence, a completely new capability that gives enterprises a clearer picture of database change across applications, pipelines, teams, and environments.

Database teams have historically had to reconstruct what happened from pipeline logs, tickets, screenshots, and other disconnected sources. That becomes especially painful when something goes wrong. Teams need to understand what changed, where it failed, whether environments have drifted, what risk was introduced, and what they should do next.

Change Intelligence brings deployment activity, environment status, drift, policy outcomes, failures, and change history together in one place. Teams can understand how changes are moving across environments, identify where risk is building, and see what needs attention without manually piecing together the story across individual pipelines and tools.

More importantly, Change Intelligence helps teams move from visibility to action. When a deployment fails, AI-driven analysis helps teams understand what happened and provides remediation guidance to resolve the issue faster. Change Intelligence also centralizes audit evidence, giving engineering, security, and compliance teams a structured record of database change throughout the delivery lifecycle.

For executives and operators alike, Change Intelligence helps enterprises understand what is happening across the database estate, identify problems faster, and determine what to do next.

Making Enterprise Database Change Governance Easier

Governance has traditionally come with a tradeoff. Enterprises want consistent standards and stronger controls but they don’t want to create another layer of process that slows down delivery.

Liquibase Secure 6.0 also introduces a new graphical interface for policy management that makes governing database change much easier. Teams can create, organize, apply, and manage policies from one place instead of relying on pipeline-by-pipeline configuration or specialized command-line knowledge.

The new experience includes 50+ prebuilt policy rules based on years of working with some of the world’s largest and most complex enterprises. Teams can start with proven controls, organize them into reusable policy packages, and apply them across the applications and environments where they are needed.

The new experience also makes exceptions part of the governance model rather than something teams have to work around. When a legitimate exception is needed, teams can scope where it applies, document why it exists, control who can make it, and retain the decision in the audit history. Organizations can maintain consistent standards without pretending every application, data product, team, or database operates exactly the same way.

Controlling Who Can Change the Rules

As database change governance moves from individual pipelines to the enterprise, organizations also need control over who owns and manages those standards.

Liquibase Secure 6.0 introduces role-based access control that determines who can manage policies, assignments, exceptions, and governed assets. Organizations can separate ownership of governance from application and data delivery, creating clear responsibilities around who defines the rules and who works within them.

This allows enterprises to maintain separation of duties without taking autonomy away from development teams. Developers can continue moving quickly inside established boundaries, while database, platform, security, and compliance teams maintain control over the standards that protect the organization.

Together, Change Intelligence, centralized policy management, and role-based access control create a new operating model for database change. Enterprises can see what changed, govern what is allowed, and control who owns the rules from one platform rather than stitching together controls across individual pipelines.

Governance as a Force Multiplier for AI

AI is increasing how quickly enterprises can build and deliver applications and data products. But that advantage erodes if every increase in development speed creates a corresponding increase in manual review, operational risk, and governance overhead.

That is why governance becomes a force multiplier for AI. When database standards are defined up front and enforced automatically, enterprises can move faster with AI without requiring a human to review every database change it helps create. Whether a change is written by a developer or generated with AI assistance, the same policies and controls can be applied before it reaches production.

The goal is not to slow AI down so existing governance processes can keep up. Liquibase Secure 6.0 makes it possible for governance to operate at the speed of development, giving teams the freedom to increase the speed and volume of change while maintaining the controls the enterprise requires.

That model extends beyond AI. Liquibase Secure supports more than 65 database platforms, giving organizations a consistent governance layer across heterogeneous database environments. Platform and DevOps teams can scale database self-service without scaling governance overhead, database teams can spend less time rebuilding controls and reviewing routine changes, and security and compliance teams can put controls and evidence closer to the point of change.

As mission-critical applications, data products, and AI initiatives increase the speed, volume, and sources of database change, Liquibase Secure 6.0 gives enterprises one place to see that change, govern how it happens, and control who can change the rules, whether the change comes from a human or AI.

Availability

Liquibase Secure 6.0 is generally available September 30, 2026. The release includes Change Intelligence, the new graphical interface for centralized policy management, role-based access control, governed exception management, and 50 prebuilt policy rules.

For more information about Liquibase Secure 6.0, visit www.liquibase.com/liquibase-secure.