Clover Security | KnowBe4 | OX-Security | TuxCare
Q1. How does Clover's context-aware AI agent differ from traditional SAST/DAST tools in shifting security left? What early wins have you seen in reducing developer friction for enterprise teams?
Clover begins where product security actually starts: in design, long before code is written. Instead of reacting to vulnerabilities after implementation, Clover reasons about architecture, intent, data flow, trust boundaries, and business logic. It behaves like a seasoned security architect embedded inside the design process, not a scanner bolted on at the end. This is a fundamentally different model from traditional SAST and DAST.
SAST and DAST were built for an earlier era. They analyze code or running applications to detect known patterns, producing long lists of findings without understanding how the system is supposed to work. They miss broken trust boundaries, incorrect identity assumptions, or design level flaws that later become expensive, high impact issues. They also slow teams down by engaging too late, creating retroactive noise that frustrates developers and overwhelms security.
Clover’s context aware agent operates inside Jira, Confluence, GitHub and architectural documents. It interprets how components interact, how data moves, where trust is defined, and where it could break. Instead of pointing out code defects, it identifies architectural risks and logic issues that traditional tools cannot see. This shifts security from reactive chasing to proactive design quality.
Early wins from our customers follow three clear ROI themes. First, scale: small security teams support engineering groups twenty to thirty times their size. Second, quality: architectural risks are caught before implementation, eliminating rework and removing the retroactive noise developers dislike. Third, experience: teams report better collaboration and earlier, actionable guidance that fits naturally into existing workflows.
Security becomes design led and continuous, not an after the fact exercise.
Q2. What feedback have you received from early/beta customers about your platform? How has that shaped your roadmap, particularly in scaling Clover to support distributed dev teams across hybrid cloud environments?
Across industries and architectures, the same message kept repeating. Modern software development has outgrown manual product security. Teams are distributed, hybrid cloud architectures are the default, and AI coding agents are accelerating delivery in ways that make traditional review models impossible to sustain. What customers needed was not another scanner. They needed intelligence that understands context at scale.
The context brain of Clover is our most distinct capability. Customers saw quickly that Clover does not operate like a tool. It behaves like a team member that understands designs, correlates artifacts across systems, interprets intent, and identifies risks in a way that feels architectural rather than signature based. This became even more important as organizations adopted AI coding agents. Customers told us that Clover is the security enabler for this shift, providing the guardrails and reasoning necessary to adopt AI native development safely.
We heard the same patterns from companies like Lemonade and PROS. Lemonade highlighted how inconsistent human reviews were across regions and teams, and how Clover’s agent based reviewers created a shared standard. PROS emphasized scale challenges, with a 30-to-1 developer-to-security ratio making manual reviews unrealistic. Clover gave them visibility from design to code across hybrid environments and a level of consistency previously unreachable.
One message stood above the rest. Meet us where we work. Jira, Confluence, GitHub, Bitbucket and Teams are where design actually lives. Clover now operates directly inside those workflows.
This feedback shaped our roadmap. Continuous design intelligence, consistent threat modeling, design to code correlation, and context aware agents that learn and improve. The result is a model that finally allows product security to scale with the way modern teams build.
Q3. What do you want attendees at Black Hat EU 2025 to know about Clover Security? What are you hoping they will take away from your company's presence at the event?
We want attendees to leave Black Hat with a clear understanding that Clover is redefining product security for the AI native era by shifting security to where products begin, not where vulnerabilities surface. Software today is created by distributed teams, hybrid cloud environments, and increasingly by AI agents that generate and modify code continuously. Traditional AppSec tools were designed for a linear development model that no longer exists. They operate after implementation and cannot scale to meet the speed or complexity of modern engineering.
Clover takes a different approach. Our context aware AI agent works at the design layer, interpreting architecture, intent, trust boundaries and data flows before any code is written. Instead of detecting vulnerabilities after the fact, Clover helps teams design them out entirely. This is not the familiar shift left narrative. It is a new model that brings security reasoning into the earliest stages of product decisions.
Attendees should leave with three ideas. First, today’s most significant risks come from how services interact, how identity is managed, how data flows, and how trust is established across systems. Clover brings continuous, objective architectural reasoning into these decisions. Second, security can now scale with engineering. Clover embeds design intelligence into Jira, Confluence, GitHub, Bitbucket, Slack and other daily tools, removing bottlenecks and enabling consistent reviews across distributed teams. Third, AI driven development does not need to create chaos. Clover acts like an architect on the team, learning patterns, adapting to changes, and improving with feedback.
Clover makes prevention feel natural rather than reactive.
Q1. What's the most concerning evolution in threat actor tactics that you have observed over the past year? What makes it particularly dangerous from a human risk perspective?
In the last year the landscape continuously evolves but a tactic we’ve been able to monitor is a 66.9% uptick in adversaries using legitimate platforms to send their malicious content into users' inboxes and bypassing multiple layers of email filtering. This attack is something we first observed back in February of 202 and has rapidly grown on the backend of 2024. Legitimate platforms such as Google Docs, Zoom docs, SurveyMonkey, QuickBooks, Dropbox, Sharepoint all have sharing capabilities built into their services directly to share with people who may be using their platform but attacks have since flipped this on its head and approached the victims by uploading their malicious content directly to the services.
Take Dropbox as an example, if you upload a document including a credential harvesting link or a piece of malware which goes undetected by Dropbox’s checks, you now can send an email FROM Dropbox, which passes DMARC, matches Dropbox’s email format, organizations usually have allowlists for such large organizations like Dropbox, the malicious content often is hidden behind a log-in screen which limits what link scanning capabilities can find. This is a real risk to humans as all of the “tell-tale” signs of malicious emails are REMOVED from the email directly and shifted onto a “trusted” platform such as Dropbox.
Another reason why this is concerning is because these are inbuilt features into all the legitimate platforms which means they won’t be removed due to attackers exploiting them and the list of these legitimate platforms is almost endless which means attackers can pivot quickly when certain legitimate platforms are burnt.
Q2. What has KnowBe4 learned about human risk—from its simulations and from real attacks—that might contradict conventional security wisdom? Are there patterns in who falls for phishing that would surprise most CISOs and other security leaders?
Our data from millions of simulations and real-world attack analysis consistently challenges assumptions that many security leaders hold about human vulnerability. Human risk is purely dynamic, not static at all so we need to stop treating the problem as such. It’s less about who the people are but actually what emotional state that individual is in when the attack arrives.
Many security leaders are beginning to believe that with a younger, tech-native workforce, these human-level attacks will start to decline as we hire more people with more tech knowledge because they are thought to be less vulnerable. However, our data actually demonstrates that age is far less of a predictor than role, stress level, and recent training. Regardless of your age, if you have an asset that the attacker wants or are in the right position with the right amount of access, you're still a prime target. We're seeing that people are vulnerable to these attacks, especially when confidence is woven throughout our workforce because it can lead to complacency, which assumes our employees are more confident and less thorough in their investigation of potential threats.
A study we recently did, tracks and correlates the timings of phishing attacks and when those malicious emails land in individuals' inboxes. This matches with high pressure zones which are Monday mornings, end of days, during busy periods within the month. This also continues to match up when you track it around the globe and different demographic profiles and individuals are getting attacked at 9am in the United Kingdom and 9am in China. Attacks that are successful are often the most contextually relevant rather than the most complex. Technically flawless phishing attempts delivered at random times are outperformed by poorly worded emails that arrive at precisely the correct time (during a known company endeavor, vendor relationship, or stressful period).
Q3. How will KnowBe4 be using its presence at Black Hat Europe 2025 to showcase new capabilities in AI-driven phishing detection and/or security awareness training? What do you hope they will learn about closing the gap between technical controls and human behavior?
At Black Hat Europe 2025, we’re planning on expanding everyone's horizons on what Knowbe4 offers as a vendor but also communicate the new depth of the phishing attacks we’re experiencing on a daily basis. From Polymorphic emails to multi-channel attacks, to realistic deepfake recordings.
The focus is on empowering the community and expanding their knowledge on how attackers can research their organizations through OSINT, utilise artificial intelligence to rapidly expand and increase the depth of sophistication within their attacks to best showcase what the threat landscape currently looks like and what organizations should be doing to sharpen their tools and defend against these attacks.
Stop by our KB4 booth to connect with industry-leading threat intelligence experts. We'll be hosting talks and live demos that dive into our security capabilities, global threat disruption work, and rare behind-the-scenes looks at the email infrastructure adversaries use to launch attacks—insights we've gained by engaging directly with threat actors themselves.
From analysts to decision-makers, everyone is welcome at the KnowBe4 booth to explore the evolving threat landscape and emerging security challenges.
Q1. What are the new risks and vulnerabilities tied to the use of generative AI in code-creation workflows? How should organizations be addressing these risks in the SDLC?
One of the key issues with AI, it’s like unleashing a junior developer to write your critical software without regard to what’s being written. AI’s goal is to provide a functional solution to your request. That’s it. Everything else important to the development process including security receives a lower priority.
This results in several recognizable anti-patterns in generated code. Some include comments everywhere such as, “Note to Future AI Self” or avoidance of refactors such as, “Who wrote this?” reflex. AI is terrible at creating monoliths or going completely the other way and creating thousands of small files that spread logic all over the place. Let’s not overlook “phantom bugs or the Vanilla coding style”. These are just a few examples of what AI is bringing to the table.
Using generative AI in code creation is extremely risky. The core problem is that AI is pulling code randomly from a (LLM) model. Trained code has been tagged as accurate, however the problem with this, who tagged the code? Training data is pulled from sites deemed to be accurate and correct, yet I have seen where this is not the case.
Finally, I would not recommend using automated remediation tools in the SDLC without a human in the middle. Every solution needs a pair of eyes to ensure that the code presented in fact solves the finding, is in context of the code around it, and does not generate any additional security issues. Without this, anti-patterns will sneak in and potentially ruin your day.
Q2. How can organizations break down the silos that exist between the appsec team and the supply chain security team? What strategies or incentives have you seen work best to align ownership?
There are several options that I have personally seen work. Place both teams on the same floor next to each other. This is a great opportunity to create collaboration between the teams. However, in today’s remote environment, this is simply not possible for some companies.
Another option, rotate individuals through each other's team. Set aside time for each group to spend time working for the other team. When you live in each other's shoes, this changes the perception and perspective that the teams have of each other.
Thinking about using financial incentives to make this work? Tie executive bonuses to QBR metrics that force the collaboration. I would have suggested bonuses to the team members, but most companies do not have bonuses at this level. When management’s bonuses are potentially impacted, things will get done.
Finally, consider a shared dashboard. Use shared KPIs between the teams to help create unity. If the teams have a unified common goal, then they will work together to accomplish it. This has been proven to work.
Q3. What are OX Security's goals at Black Hat Europe 2025? What does your company have lined up at the event for customers, researchers and other attendees?
OX Security has several goals for Black Hat Europe. Thought leadership is front and center. Being seen as a trusted partner is very important to us. Working together to make security actionable and reduce risk is part of what drives us each day. Too often companies are stagnant and then become compromised. By removing the noise, providing solid security best practices, and working together - that’s a recipe for success.
Another goal this year is to show our new VibeSec platform. We were able to solve several key issues with generative AI. Instead of just talking about it and providing marketing material, we want to actually show it. Let the attendees try it and decide for themselves if we solved the problem.
During the event, we are presenting the “Dark side of AI: Writing unsecure code in minutes” talk. It goes through the dangers of AI generated code. This talk has been well received and has been presented at multiple conferences and meetups. Each time that has been presented, it has been changed so that attendees are not hearing the same content over and over.
Q1. TuxCare's 2025 Enterprise Linux and Open-Source Landscape Report showed a 12-fold rise in Linux vulnerabilities and plummeting confidence in open-source security. How is TuxCare incorporating these findings into its roadmap for AI-driven patch automation?
The number of vulnerabilities continues to grow, while software and its components need to be maintained for longer and longer periods. There is also more code, and more vulnerability reporting going on. As such, we are making sure we can quickly patch security vulnerabilities for a large number of open source components used by our customers. This is done by automating processes to a high degree, using AI and algorithmic approaches, while keeping humans in the loop.
Q2. What best practices can organizations adopt to fortify open-source supply chains against backdoor risks and dependency vulnerabilities in enterprise deployments?
A lot of enterprise teams still focus on the top-level components in their stack, but the real risks often hide much deeper – in transitive dependencies, outdated libraries, and build pipelines that haven’t been fully hardened. The best thing teams can do is take a layered approach. Start with provenance and integrity and then go a level deeper to make sure you actually understand what’s inside your software. SBOMs are hugely helpful here, especially when you’re dealing with older components that haven’t been actively maintained for years.
From there, it’s really about tightening the build and deployment process. Attackers can target CI/CD systems rather than the code directly, so locking down credentials, isolating runners, and using ephemeral build environments is essential. Continuous scanning plays a big role too.
Then, teams need to operate under the assumption that critical vulnerabilities will surface in components that vendors no longer support – whether they’re in the OS, application layer, runtimes, or libraries. Having a reliable, fast patching process, whether it happens internally or through a trusted provider, makes an enormous difference in reducing your exposure window.
To make a long story short, visibility, integrity, and the ability to remediate quickly form the foundation of a truly resilient open-source supply chain.
Q3. What key themes or messages will Tuxcare be emphasizing at Black Hat Europe 2025? Will your team be hosting any sessions, panels, or interactive activities attendees should know about?
At Black Hat Europe this year, we’re focusing on a simple but important idea: securing open source isn’t just about the moment a project ships – it’s about the long-term maintenance that keeps those components safe for years afterward, even well past their official end-of-life date. That applies to the OS, runtimes, libraries, software development frameworks, and applications that enterprises continue relying on long after upstream support has ended.
We’ll be talking a lot about securing the entire open-source stack, from the kernel all the way through transitive dependencies of individual software libraries. A big part of that story is how we’re using AI to enhance patch automation. Not to replace human engineers, but to give them better context, reduce patching timelines, and help organizations shrink the gap between vulnerability discovery and remediation. It’s been a major focus in our research this year, and it will be a major focus at the event as well.
We’re also dedicating time to regulated workloads – things like FIPS-validated cryptography, FedRAMP-aligned patching workflows, STIG guidance, and enterprise-grade support for community Linux distributions. Those environments require a different level of rigor, and we’re excited to show how we help teams meet those compliance expectations without slowing down day-to-day operations.
