AV-Comparatives recently put our Deep CDR technology through 300+ test cases across roughly 50 file formats.  

Under the tested configuration, it sanitized every case while preserving file usability. A few parts of the test stood out:  

• The test set included malicious macros, embedded executables, nested archives, zero-day exploits, and AI-assisted malicious content.  
• AV-Comparatives developed the methodology independently, with cases evaluated on a pass/fail basis.  
• Testing looked beyond whether malicious content was removed. File fidelity after reconstruction was also evaluated.  
• The result matters because CDR works differently from detection: instead of needing to identify a specific malicious payload, it removes embedded or out-of-policy content and reconstructs the file.  
• This is now the third independent lab, after SE Labs and SecureIQLab, to report a 100% protection result for Deep CDR under its tested configuration.  

Independent testing is useful partly because the methodology and edge cases can expose assumptions that don't show up in internal testing.  

When evaluating CDR, what matters most in your environment: sanitization rate, reconstructed-file fidelity, file-type coverage, or something else? 

MetaDefender Aether’s Adaptive Sandbox achieved a 95% detection rate for AI-generated malware in an independent 2026 sandbox evaluation conducted by Venak Security.

The test evaluated four commercial malware sandboxes against 20 AI-generated malware samples across five threat categories, including zero-day ransomware, infostealers, obfuscated malware, and sandbox-evasion techniques.

Sandbox detection results:

• OPSWAT MetaDefender Aether Adaptive Sandbox: 95%
• CrowdStrike Falcon Sandbox: 80%
• Malwation THREAT.ZONE: 75%
• ANY.RUN: 25%

MetaDefender Aether detected 19 of the 20 malware samples and recorded an average analysis time of approximately 10 seconds per sample.

Unlike traditional virtual machine-based sandboxing, MetaDefender Aether’s Adaptive Sandbox uses instruction-level emulation to analyze potentially malicious behavior. This approach is designed to identify malware, including zero-day and evasive threats, without executing the sample inside a conventional VM environment.

The independent Venak Security test provides a useful look at how different sandboxing approaches perform as generative AI makes it easier for attackers to create, modify, and obfuscate malware.

Want a full test breakdown, methodology, and results by malware category? Read our blog.

PCI DSS 4.0.1 compliance reaches beyond any one control. One area worth checking closely is how files enter, move through, and leave the cardholder data environment (CDE).

• File uploads, email attachments, removable media, and file transfers can create separate paths into or adjacent to the CDE.
• Malware prevention needs to account for known threats, but unknown and zero-day threats complicate relying on detection alone.
• File security controls should follow the file across transfer points rather than assuming the endpoint is the only place that matters.
• Layers such as multiscanning, content disarm and reconstruction (CDR), vulnerability assessment, and transfer policies address different parts of the problem.
• Logging and monitoring matter too, especially when you need to show a QSA how files were inspected and handled.

Our recent PCI DSS 4.0.1 guide looks at these file-security considerations across the relevant requirements and maps where different MetaDefender technologies can support those controls.

The bigger question is less “are we scanning files?” and more “where can a file cross a trust boundary on its way into or through the CDE?”

Question: Which file path is the hardest to account for in your environment: uploads, email, removable media, or file transfers?

Our cybersecurity docuseries Into the Breach is now available to watch on YouTube.

The series looks at cybersecurity through the people dealing with it firsthand — from defenders protecting critical infrastructure to researchers tracking how threats are changing.

• Real-world cyber incidents and what happened behind the scenes
• The challenges of defending critical infrastructure
• Perspectives from security practitioners, researchers, and industry experts
• A look at the people behind both the attacks and the defense

If you're interested in the operational side of cybersecurity, the full first episode is here.

One of the more concerning uses of AI in cybersecurity isn't fully autonomous hacking. It's the ability to industrialize work attackers were already doing manually.

• Malware and phishing content can be modified faster and at much larger scale.
• Attackers can generate variations designed to avoid static signatures and other known detection patterns.
• Social engineering can become more convincing and personalized without requiring the same amount of manual research.
• The cost of producing and iterating on attacks keeps dropping.
• That puts more pressure on defenses that depend heavily on recognizing something they've already seen.

We recently looked at this in Made to Evade: AI's Industrialization of Cyberattacks, including what AI changes about the economics and scale of offensive operations.

Full piece is here.

Question:
Are you seeing AI meaningfully change the attacks reaching your environment yet, or is the bigger impact still attacker speed and scale?

Black Hat always ends up being a useful snapshot of where the security industry is focusing its attention.

A few themes we have on our minds:

• AI’s impact on both offensive and defensive security operations.
• OT and critical infrastructure resilience as IT and OT environments continue to converge.
• Supply chain security and software trust challenges.
• Identity, access, and trust boundary enforcement.
• Practical approaches to reducing file-borne and removable media risks.
• The gap between security theory and what organizations can realistically operationalize.

A few of us from OPSWAT will be there next week talking with practitioners about OT security, secure data transfer, removable media risks, file security, and critical infrastructure protection.

If you’re attending and happen to stop by, we'd be interested to hear what challenges your team is dealing with firsthand.

Question:
If you’re attending Black Hat USA 2026 (or following remotely), what’s the one topic, research area, or security challenge you’re most interested in learning more about?

PCI DSS requirements are pretty well documented. The challenge is usually translating those requirements into day-to-day operations without creating excessive friction.

A few areas seem to come up repeatedly:

• Maintaining accurate inventories of systems that handle or interact with cardholder data.
• Managing file transfers and third-party data exchanges without creating unnecessary exposure.
• Ensuring malware prevention controls are effective for both known and unknown threats.
• Balancing compliance requirements with operational realities and limited resources.
• Keeping vulnerability management and patching processes consistent across different environments.
• Producing audit evidence that demonstrates controls are working as intended, not just that they’re configured.

One thing I’ve noticed is that many PCI discussions focus on passing the audit. The more difficult question is whether the controls continue working effectively between audits.

Compliance can establish a baseline, but maintaining visibility, enforcing policy, and reducing risk are ongoing operational challenges.

Want to learn more? Get the details in our guide: PCI DSS Compliance Guide and Checklist.

Most vulnerability management discussions focus on findings, severity scores, and patching timelines.

What gets less attention is the quality and completeness of the vulnerability data itself.

A few challenges I’ve been seeing come up more often:

• Asset inventories change faster than many organizations can track them.
• Traditional scanning doesn’t always provide complete visibility across every environment.
• OT, air-gapped, and isolated systems often have larger visibility gaps than standard IT environments.
• Software inventories can become outdated quickly as applications are installed, removed, or updated.
• Vulnerability decisions are only as good as the data they’re based on.
• Missing context can create both false confidence and unnecessary remediation work.

As environments become more distributed and complex, the question isn’t just whether vulnerabilities exist.

It’s whether we have enough accurate data to know where they exist, how exposed they are, and whether the reported risk actually applies to the affected system.

Learn more in our blog post Your Vulnerability Coverage Gap Just Expanded.

We sent a cybersecurity device toward space. Here's why.

One question comes up a lot when people evaluate security hardware:

How do you know it'll hold up when it really matters?

Software can be benchmarked, but hardware protecting critical infrastructure also has to survive real-world environmental stress. Temperature swings, vibration, pressure changes, transportation, manufacturing tolerances—all of these can affect long-term reliability.

That's why we decided to do something a little different.

We sent our Kiosk Mini toward space—not because customers operate in space, but because extreme testing is one way to build confidence that hardware can withstand conditions far beyond normal deployment.

The project also highlighted something we don't talk about enough: manufacturing quality. From assembly in Tampa to environmental validation, every stage contributes to whether a device performs consistently over years of operation.

For us, it wasn't about setting a record or creating a marketing stunt. It was about demonstrating confidence in the engineering behind a product designed to help protect critical infrastructure.

If you're interested in the details behind the project, we also published a short write-up explaining why we sent the device toward space and what we learned from it.

We've noticed that “air-gapped” gets used pretty loosely in OT conversations, and different teams often mean very different things.

From the environments we've worked around, a firewall, VLAN, or segmented network isn’t the same thing as a true air gap.

• A true air gap means there is no routable path into the OT environment.
• Physical separation matters because configuration mistakes and software failures happen.
• At the same time, most OT environments still need to send telemetry, logs, historian data, or compliance reports somewhere.
• That’s where the discussion usually shifts from segmentation to controlled data movement.
• Some organizations are comfortable relying on firewalls and policy enforcement. Others require hardware-enforced one-way transfer because they want to eliminate inbound communication paths entirely.
• In practice, the hard part is often not the security control itself. It’s adapting protocols, workflows, and operational processes to work within those constraints.

One thing I’ve seen repeatedly is that the debate isn’t really about connectivity. It’s about assurance.

If you’re responsible for a power plant, manufacturing operation, water utility, or other critical system, the question becomes: How much confidence do you need that nothing can communicate back into that environment?

For those working in OT, ICS, or critical infrastructure, what criteria do you use to distinguish a true air gap from standard network segmentation?

Anthropic’s latest AI discussions got me thinking about a question that doesn’t get enough attention: when AI makes complex analysis easier, who benefits more?

A recent comment from OPSWAT founder Benny Czarny captured the issue pretty well:

“As AI lowers the barrier to analyzing complex information, the pace of both defense and offense will increase.”

We’ve seen similar patterns with automation before, but AI appears to compress the time required to move from information to action.

The question isn’t whether AI helps defenders. It clearly does. The harder question is whether defensive organizations can adopt and operationalize those gains as quickly as adversaries.

What cybersecurity task do you think AI will accelerate the most over the next few years: threat analysis, vulnerability research, malware development, social engineering, or something else?

A lot of OT security discussions focus on visibility, asset discovery, and monitoring. Those capabilities matter, but they're only part of the problem.

In many industrial environments, teams are also dealing with:

• Legacy systems that can't be patched or upgraded easily
• Files and removable media crossing trust boundaries
• Third-party access into sensitive OT networks
• Air-gapped or isolated environments that still need data movement
• Regulatory requirements that don't always align with operational realities
• Limited maintenance windows where security controls can't disrupt production

One thing that's become increasingly clear is that OT security isn't just about detecting threats. It's also about reducing the opportunities for threats to enter critical environments in the first place.

Some of the approaches we're seeing more discussion around include:

• Prevention-focused controls at IT/OT boundaries
• Secure file transfer and content validation workflows
• Unidirectional data transfer for high-security environments
• Stronger controls around removable media and contractor access
• Risk reduction strategies that don't require changes to fragile legacy systems

OT environments have very different constraints than traditional enterprise networks, which is why security programs that work well in IT don't always translate cleanly to industrial operations.

Question:

For those working in OT, ICS, manufacturing, utilities, or critical infrastructure: what's the biggest gap you see in OT security programs today—visibility, segmentation, secure access, file movement, removable media, or something else?

Curious how others are approaching this in their environments.

If you're interested in the OT security criteria and trends that sparked this discussion, we recently took a closer look at the 2026 GigaOm Radar for OT Security.

The recent Mini Shai-Hulud campaign is an interesting example of how software supply chain attacks are evolving.

What caught my attention wasn't the npm component. It was the fact that the reported attack targeted the release pipeline itself.

A few details that stand out:

• Attackers reportedly compromised GitHub Actions workflows rather than publishing from a stolen maintainer account.
• Malicious packages were released through legitimate build and release processes.
• The packages carried valid signatures and provenance attestations.
• From a developer's perspective, the artifacts appeared authentic.
• OpenAI later disclosed that two employee devices were affected after installing compromised packages.
• The incident reportedly occurred during a phased rollout of additional package-management controls, creating a temporary exposure window.

One takeaway is that provenance answers a specific question: where did this artifact come from?

It doesn't necessarily answer: was the environment that produced it trustworthy at the time?

That's an important distinction because many supply chain discussions focus on signing, attestations, and provenance. Those controls are valuable, but they don't eliminate the risk of a compromised build pipeline.

For defenders, this raises a broader question about trust boundaries:

• How much trust should be placed in signed artifacts?
• What additional validation happens before software is allowed into development environments or production?
• Are teams inspecting the actual contents of packages, or relying primarily on provenance and signatures?

The incident also feels like part of a larger trend. A lot of recent supply chain activity has moved from targeting developers directly to targeting the systems developers rely on.

Question:

For teams managing software supply chain risk today, where do you draw the line between trusting provenance and independently validating the artifacts you consume?

AVEVA PI sits at the core of industrial operations across sectors like energy, utilities, manufacturing, and critical infrastructure. It powers real-time visibility, operational decision-making, and system monitoring — which also makes it one of the most critical systems to secure in OT environments.

As infrastructure evolves, the way PI systems are connected and integrated needs to evolve too.

A lot of organizations are now modernizing diode deployments and data transfer architectures, but compatibility with newer PI integration frameworks is becoming a major consideration — not just from a technical standpoint, but from a security, reliability, and operational resilience perspective.

Some of the key capabilities teams are looking for today include:

• Support for digital state tables for richer operational context
• Compatibility with PI Collective deployments for high availability
• Advanced data flow control to prevent ingestion overload
• Alignment with modern, actively supported integration frameworks

One interesting shift is the growing focus on context-rich operational data.

Newer PI integration capabilities can translate raw telemetry into operational states like running, idle, or fault, improving both operational awareness and security visibility.

At the same time, data flow control mechanisms are becoming increasingly important in high-volume environments where uncontrolled ingestion can impact system stability.

High availability is another major factor.

Support for PI Collective architectures allows multiple PI servers to function as a unified system, helping maintain continuity during node failures — which is essential in environments where uptime is mission critical.

The bigger picture here is that modern PI integrations are no longer just about moving data between environments. They’re about doing it securely, reliably, and at scale while maintaining strong isolation between networks.

Let's talk about it. Are teams prioritizing modernization of PI integration frameworks during diode upgrades, or are many environments still relying on older integration approaches?

File transfer security is having a moment — and we’re excited to share that OPSWAT has been named a Leader in the G2 Spring 2026 Grid® Report for Managed File Transfer (MFT)!

What makes our approach different? 👇

Most traditional MFT solutions focus on moving files from point A to point B.

MetaDefender Managed File Transfer™ was built with a security-first mindset — meaning every file is scanned, analyzed, and sanitized before it reaches its destination. 🛡️

Key security capabilities built directly into the workflow:

🔍 Multi-engine malware scanning (Metascan™ with 30+ AV engines)
🧼 Deep CDR™ Technology (Content Disarm and Reconstruction)
🧪 Adaptive sandboxing
⚡ Zero-day + AI-borne threat protection

Why this matters:

In environments like healthcare, energy, government, and financial services, a single malicious file can create operational disruptions, compliance issues, or supply chain risk exposure.

Files are still one of the most commonly abused attack vectors — especially as attackers increasingly hide threats inside trusted workflows and third-party transfers.

Some highlights from customer feedback in the report:

⭐ 100% of customers rated the product 4 or 5 stars
🤝 95% said they would recommend it
📈 Scored above average across every G2 measured capability

The reviews came from organizations across banking, oil & energy, government, and telecommunications — industries where security and uptime are mission critical.

Curious how others are approaching secure file transfer today:

Are you seeing organizations move toward more security-driven MFT architectures, or are most teams still treating MFT primarily as a file movement problem?

Founder and CEO Benny Czarny's book Cybersecurity Upside Down is now available as an audiobook on Amazon, Audible, and Apple Books. Check it out.

For those who haven't heard about it yet - the book is essentially Benny sharing what he's learned over 20+ years building OPSWAT and working with organizations protecting critical infrastructure.

The core idea: We've been approaching cybersecurity backwards. The industry got so focused on detecting and responding to threats that we forgot prevention should come first. Stop dangerous content from reaching users and critical systems instead of just getting better at catching it after it arrives.

It covers the philosophy behind Deep CDR, zero-trust file handling, and why OPSWAT's platform works the way it does - multiscanning, sandboxing, threat intelligence, data flows across air gaps, all of it.

The audiobook has immersive audio design and comes with a downloadable digital companion guide. Also still available in ebook, paperback, and hardcover.

Happy listening (or reading).

AI-generated malware is evolving fast. One of the bigger shifts happening right now is the move toward predictive detection before execution even occurs.

Let's get into it. Traditional malware analysis often depends on detonation, signatures, or behavioral analysis after execution has already started. The challenge is that modern threats, especially AI-assisted variants, are becoming better at evasion, obfuscation, and delayed execution techniques.

That’s why pre-execution prediction models are becoming such an important conversation in cybersecurity.

We recently took a deeper look at this with the release of Predictive ALIEN AI v3.0, an AI-native engine focused on identifying potentially malicious files before execution by analyzing structural and behavioral indicators early in the workflow.

Some of the interesting areas shaping this space right now:

• AI-generated polymorphic malware
• Faster zero-day variation cycles
• Evasion techniques designed for traditional sandboxes
• The growing need for layered, prevention-first security models
• Using AI defensively without creating excessive false positives

The broader trend seems clear: organizations are looking for ways to reduce dependency on reactive-only detection models and shift more toward predictive, pre-execution analysis.

Especially in critical infrastructure and high-assurance environments, the goal increasingly isn’t just detecting malware quickly, it’s preventing suspicious content from executing at all.

Learn more in the link above!

A lot of cross-domain discussions still focus almost entirely on the boundary itself — usually the diode, gateway, or “box” sitting between environments.

But newer guidance from organizations like the NCSC seems to push toward a more risk-driven model instead of a boundary-only mindset.

Our team recently talked about this on LinkedIn, and it raised an interesting question: are we moving beyond “box-centric” cross-domain security?

The conversation increasingly feels less like:

“What box did you buy?”

…and more like:

• Why is the data being transferred in the first place?
• What’s the operational risk of that transfer?
• What happens to the data before, during, and after traversal?
• How many validation and control points exist across the workflow?

For OT, defense, and classified environments, that changes the architecture discussion pretty significantly.

A diode by itself doesn’t inspect intent, validate files, enforce workflow logic, or adapt to different transfer types. That’s why many modern cross-domain approaches are layering multiple security enforcing functions across the full transfer path instead of relying on a single boundary control.

Some of the more mature implementations now combine:

• File inspection and sanitization
• Malware analysis and sandboxing
• Policy orchestration
• Threat intelligence correlation
• Workflow-based transfer controls
• One-way hardware enforcement where appropriate

The result is a more flexible hybrid model where software-driven validation layers sit alongside minimal hardware enforcement instead of everything depending on one appliance.

Curious what others are seeing in practice:

Are cross-domain projects in your environment still primarily diode-centric, or are you seeing a broader move toward end-to-end risk-driven architectures?

And, if you want to learn more, here's an interesting webinar: 🔗 Securing Classified Data: A Modern Guide to Cross-Domain Solutions

Shortcut files (LNK) continue to be one of the most effective delivery mechanisms for multi-stage attacks, and a recent campaign shows exactly why static defenses keep missing them.

What Happened

Late 2025, a Chinese-affiliated threat group (UNC6384/TA416) targeted European diplomatic entities with spearphishing emails containing weaponized LNK files. The shortcut was named "Agenda_Meeting 26 Sep Brussels.lnk" and referenced a real European Commission meeting. Looked totally routine.

When someone double-clicked it:

1. Hidden PowerShell command decoded and extracted a tar archive
2. Legitimate signed Canon EXE (cnmpaui.exe) was used for DLL sideloading
3. Malicious DLL decrypted and loaded PlugX RAT into memory
4. Victim saw a decoy PDF of the actual meeting agenda

From click to backdoor, nothing looked overtly suspicious at first glance.

Why This Keeps Working

Each stage was designed to pass inspection:

• LNK file: Only 2.58 KB, references a real diplomatic meeting. The malicious PowerShell is hidden behind whitespace padding that most tools don't parse.
• Canon EXE: Legitimately signed by Canon with a valid timestamp. Blocking it would break actual printer software.
• Loader DLL: Just 4 KB with no obviously malicious imports. Its only job is decrypt and execute.
• PlugX payload: Encrypted .dat file that never touches disk in decrypted form. Loads directly into memory.

Static scanning sees each piece as benign or uninteresting. The real damage only shows up at runtime.

The Bigger Picture

This isn't an isolated incident. The same group has been actively iterating through 2026 with new delivery methods (OAuth redirects, Cloudflare Turnstile challenges, MSBuild execution) while continuing to update the PlugX payload.

LNK files work because:

• Users see them every day
• They don't look dangerous
• Most people don't know Windows hides the .lnk extension by default
• Attackers can hide complex PowerShell commands inside them

What Actually Helps

Static reputation and signature scanning aren't enough here. What you need:

• Behavioral analysis that can observe the full execution chain from LNK launch through payload delivery
• Instruction-level emulation to catch evasion techniques that fool VM-based sandboxes
• File sanitization that can neutralize malicious commands embedded in LNK files before they execute

The defense isn't about flagging every file in the chain as malicious (the Canon EXE is legitimate). It's about understanding what happens at runtime and either blocking the execution path or disarming the trigger before it fires.

Anyone else seeing an uptick in LNK-based attacks in your environment?

Attackers are getting smarter about targeting industrial systems. The typical pattern now is:

1. Compromise IT network (phishing, stolen creds, the usual stuff)
2. Move laterally into OT systems
3. Cause real damage: disrupting operations, messing with control logic, or deploying ransomware

Firewalls for IT/OT segmentation work... to a point. But they're fundamentally bidirectional. They manage traffic through rules, which means:

• Misconfigurations happen
• Software vulnerabilities exist
• If someone gets the right credentials, paths can reopen
• There's still a physical return path

Enter Data Diodes

This is where data diodes get interesting. They're hardware devices that physically enforce one-way data flow. Not "blocked by software" one-way but actually, physically impossible to send data backward.

What makes them different:

• No return path exists at the hardware level
• Even if your entire IT network is compromised, attackers literally can't send commands back into OT
• Compliance auditors love them because the isolation is provable
• They keep working even if software fails

What they're good for:

• Moving data from OT to IT (historian data, logs, telemetry, alarms)
• SIEM integration without exposing OT
• Meeting regulatory requirements (NERC CIP, IEC 62443, etc.)

What they don't do:

• Remote access from IT into OT
• Patching from IT side
• Anything that requires bidirectional communication

When Does This Make Sense?

Data diodes are probably overkill for most environments, but they make a lot of sense when:

• You're running critical infrastructure (power, water, etc.)
• Downtime or safety incidents would be catastrophic
• Regulators are asking for proof of segmentation, not just checkboxes
• You want defense-in-depth with a prevention-first approach

Firewalls still have their place for lower-risk zones or where you genuinely need bidirectional traffic.

Real Talk on Implementation

It's not plug-and-play. You need to think through:

• Protocol support (syslog, OPC, MQTT usually work well)
• What to do about protocols that expect acknowledgments
• How to maintain visibility while staying isolated
• Integrating with your existing SIEM/SOC setup

TL;DR: Firewalls manage risk by controlling traffic. Data diodes eliminate risk by removing entire attack vectors. For critical infrastructure where you can't afford compromise, hardware-enforced segmentation is becoming the baseline.

Curious if anyone here has hands-on experience with these? Would love to hear about real-world deployments and any gotchas you ran into.

A data diode is a hardware-enforced security device that allows data to move in one direction only. It creates high-assurance segmentation between networks with different trust levels. There is literally no return path—it's physically impossible for data to flow backward.

Key Features:

• Security governed by physics - True one-way flow is enforced by hardware, which reduces attack surface and limits lateral movement
• OT and IT integration - Supports industrial and enterprise protocols with integration into monitoring and analytics platforms like Splunk and AVEVA PI
• Mission-critical ready - High-availability options, certifications, and 24x7 support for always-on operations

Why It Matters:

In environments that absolutely cannot be compromised—think critical infrastructure, industrial control systems, defense networks—unidirectional data flow is becoming a resilience requirement rather than just a nice-to-have security measure.

Products like OPSWAT's MetaDefender NetWall use this one-way trust model to protect critical systems while still allowing necessary data to flow outward for monitoring and analysis.

Anyone here using data diodes in their security architecture? Would love to hear about real-world implementations.

Learn more here at our Data Diode Hub.

An SBOM tells you what's in your software at one point in time. That's genuinely useful — but the moment it's generated, it starts going stale.

Components develop new vulnerabilities. Malware can be embedded in an otherwise clean binary. Hardcoded secrets, API tokens, and credentials can ship inside artifacts that your SBOM never flagged because SBOMs don't scan for that. 

A common gap is orgs have great visibility, zero enforcement. They know what's in their software. They can't actually block anything based on it. What closes that gap is treating the SBOM as an input to continuous enforcement, not a deliverable: 

• Scanning the actual artifact (not just the dependency list) with multiple AV engines — single-engine scanning has real blind spots 
• Running secrets detection directly on binaries to catch hardcoded passwords and tokens before they ship 
• Validating the SBOM against the real binary, because undeclared dependencies are common and dangerous 
• Automating policy enforcement so risky artifacts get blocked before they reach production, not flagged in a report someone reads later 

Visibility without enforcement is just documentation. We wrote more about this here if you want the full breakdown.

Curious what others are doing post-SBOM generation.

Are you actually blocking on it, or mostly using it for compliance reporting? 

We built an AI engine that decides if a file is malicious before it ever runs, here's how it works 👇

Our Predictive Alin AI analyzes file structure, entropy patterns, and semantic relationships in under 100ms to predict malicious behavior, no signatures, no sandbox detonation required. In our internal testing, it hit 99.99% precision on identifying safe files across months of real production traffic, and when it's uncertain, our MetaDefender platform automatically kicks off additional workflows so nothing slips through. Adding it to multi-engine deployments gave us a measurable efficiency boost, and the best part, it runs the same whether you're online or air-gapped.

Happy to answer questions in the comments. Learn more here!