If you run a commercial security scan on the Fusion binaries - or on almost any enterprise product from almost any company - the scan will report vulnerabilities. Sometimes, scans can report hundreds of them! Yet, Fusion is a secure piece of software, and any outstanding security vulnerabilities will be categorized in our security bulletins. Why do claimed vulnerabilities on security scans not actually mean Fusion has real security vulnerabilities?
What makes a vulnerability into a security threat?
We have to first talk about security models and what having a secure piece of software means. In a practical sense, you can think about both what a bad actor (attacker) might want to do if they had access to the software, and the universe of possible places a bad actor might use to get access to the software (the attack surface). An attacker can get through the attack surface by exploiting a vulnerability, which allows them access to the system.
The important thing to keep in mind is that not every vulnerability is exploitable! This means that, even in enterprise software where the attack surface is necessarily rather large (every part of the software stack and every 3rd party package included in that stack), many and even most vulnerabilities can't be turned into access. This is because a vulnerability doesn't exist in a vacuum, but requires certain other things to be true to actually exploit.
This means that vulnerabilities in software can be handled in two ways: by fixing the software, or by changing the way the software is used so the vulnerability is not exploitable. Because it takes time for bugs to be fixed, and because Lucidworks often needs to wait for the vendors of 3rd party libraries to fix the bug on their end, changing the way we use the software is a major tool for securing systems. We call this mitigating the vulnerability - the vulnerability still exists, but no attacker can actually exploit it to gain access to the system.
As an analogy, imagine your car has a broken glove box lock. This is the vulnerability. If someone can get to the glove box, they can open it and take whatever is inside. Ideally, you fix the lock. However, you might not be able to do so - maybe a part you need is no longer manufactured, or every mechanic around you is booked solid, or the fix is expensive and you don't have the money. You can instead have a mitigation strategy so you can still use your car.
The obvious mitigation involves a security concept called defense in depth. This means that you can have one part of your system be insecure as long as another, secure part of the system still blocks any attackers. In this case the other layer of defense is locking your car, which keeps attackers away from the glove box entirely. If you are the only person who uses your car and you keep it locked, the broken glove box lock is mitigated even though the vulnerability (broken lock) still exists. If other people use your car, you can also not keep anything valuable in the glove box. This is another method of mitigation: an attacker can get access, but the access is worthless because they can't do anything useful with it.
This is related to the popular Swiss cheese model of security. Imagine a stack of slices of Swiss cheese. The cheese is the attack surface, the holes are vulnerabilities. If you only have one piece of cheese, any hole lets an attacker compromise the system. If you stack the cheese slices, you need the holes to line up on every slice to let an attack pass through. This represents how different pieces of security can cover for each other.
Real world example of mitigation
To bring this back to software, here’s a real world example. The Log4Shell vulnerability, CVE-2021-44228, was a 10.0 critical vulnerability in certain versions of Log4j2 that let attackers execute arbitrary code. It's the worst possible vulnerability you can have in software. It made front page news of the trade publications for weeks and every vendor that uses Log4j, including Lucidworks, had to respond to it as soon as possible (see our security bulletin on this issue). However, even Log4Shell had mitigation steps that rendered it not exploitable! Log4Shell relied on a bug in the JNDI handling code (JNDI is a Java API for a directory service that allows Java software clients to discover and look up data and resources via a name). There's a way to turn off this feature entirely, which makes the bug not exploitable - the equivalent of removing your glove box from your car to stop anyone from stealing what's inside. If you don't use JNDI in log4j (most systems don't), this mitigation has no downside. If you actually need JNDI, this isn't going to work - you either lose functionality or risk a security breach.
In the case of Log4Shell, the issue was so severe that the Log4J project issued a series of emergency patches, and every vendor that could did so as well (including Lucidworks, where we updated even Fusion 4 to have the fixed version of the Log4j library). In many other cases, mitigations are sufficient to not require an emergency patch and allow software vendors to include a fixed library in the next version. A ton of vulnerabilities in software libraries require specific configurations to be exploited, or for the software that uses the library to use a specific feature of the library. Many software libraries have a lot of features that aren't core to the library, so even if a library has a high or critical vulnerability many products that use that library won't actually be exploitable because of that vulnerability.
So, the answer to why there are so many known vulnerabilities in the Fusion stack is simple: because most of them aren’t vulnerabilities at all. They might affect other software, which uses the features or has the configurations necessary to make the vulnerability exploitable. However, as long as the vulnerability is on the list we provide, it is not exploitable (sometimes with a specific configuration change).