By Staff What is really going on in the Comodo threads?

[ForgottenSeer 123960]

The argument made by @cruelsister is a form of security nihilism. It promotes a reactive, rather than proactive, approach to security. A sound security strategy involves patching known vulnerabilities as quickly as possible, regardless of their current exploitation status.

For a user seeking genuine security advice, this type of reasoning should be a significant warning sign. It suggests that she either misunderstands the nature of cybersecurity threats or is engaging in brand apologetics. When evaluating security software, you should always consider the vendor's track record in addressing CVEs. A slow or dismissive attitude towards documented flaws is a far greater risk than the "noise" of a contentious forum thread.

 

[Pico]

Comodo's and some policy, keep BigFoot running in a tredmill...

 

[Trident]

The argument made by @cruelsister is a form of security nihilism. It promotes a reactive, rather than proactive, approach to security. A sound security strategy involves patching known vulnerabilities as quickly as possible, regardless of their current exploitation status.

For a user seeking genuine security advice, this type of reasoning should be a significant warning sign. It suggests that she either misunderstands the nature of cybersecurity threats or is engaging in brand apologetics. When evaluating security software, you should always consider the vendor's track record in addressing CVEs. A slow or dismissive attitude towards documented flaws is a far greater risk than the "noise" of a contentious forum thread.

You should consider more than just the vendor’s track record when it comes to CVEs, in fact, this should be the last consideration, as it is expected that a business of this nature will fix their reported and discovered CVEs in a timely manner.
Just like we don’t need to evaluate and assess whether Starbucks will have a stable supply of coffee beans before we go there—it is expected that a coffee shop will have it.

There is this border between “good” and “good enough”. Vendor dismissing vulnerabilities because pre-requisites are required, even though not putting the users at immediate risk, can only be classified as the latter, with or without SHA256 presented. I personally, would immediately start looking at the vendors in the first group and forget about everyone simply “good enough”.

The assessment should include:
-How hard is the vendor working to maintain all available layers and keep up with trends: antivirus that is a one-trick pony (relying just on containment, strong web filter, HIPS amongst other) is not as good as a layered one.
-Is it even multi-layered or many features are added “just to register the presence of them”.
-Is the vendor responsive, quick to fix reported issues in a timely manner, or is it the sort of vendor that says “Thank you very much for your feedback” and then does little to nothing after.

These are just some of the key points to consider. Fortunately for the top vendors, these assessments don’t even have to be made.
If you’ve come to a point where you would need to make assessments, then you are better off looking elsewhere.

 

[ForgottenSeer 123960]

You should consider more than just the vendor’s track record when it comes to CVEs, in fact, this should be the last consideration, as it is expected that a business of this nature will fix their reported and discovered CVEs in a timely manner.
Just like we don’t need to evaluate and assess whether Starbucks will have a stable supply of coffee beans before we go there—it is expected that a coffee shop will have it.

There is this border between “good” and “good enough”. Vendor dismissing vulnerabilities because pre-requisites are required, even though not putting the users at immediate risk, can only be classified as the latter, with or without SHA256 presented. I personally, would immediately start looking at the vendors in the first group and forget about everyone simply “good enough”.

The assessment should include:
-How hard is the vendor working to maintain all available layers and keep up with trends: antivirus that is a one-trick pony (relying just on containment, strong web filter, HIPS amongst other) is not as good as a layered one.
-Is it even multi-layered or many features are added “just to register the presence of them”.
-Is the vendor responsive, quick to fix reported issues in a timely manner, or is it the sort of vendor that says “Thank you very much for your feedback” and then does little to nothing after.

These are just some of the key points to consider. Fortunately for the top vendors, these assessments don’t even have to be made.
If you’ve come to a point where you would need to make assessments, then you are better off looking elsewhere.

"That's a very insightful and well-reasoned take. I completely agree that we need to move beyond simple metrics and assess a vendor's underlying security culture.

Your distinction between 'good' and 'good enough' is especially sharp, it perfectly captures the difference between a proactive security partner and one that simply meets the minimum requirements. The assessment points you raised, like the depth of security layers and genuine responsiveness, are exactly what mature security teams should be looking for.

The only area where I might offer a slightly different perspective is on the role of the CVE track record. While I agree it shouldn't be the primary consideration, I see it as a valuable source of data on a vendor's operational maturity and transparency. It tells a story about how they behave under pressure.

I would also add a note of caution to the idea that any 'top vendor' is exempt from this level of assessment. The 'trust but verify' principle is crucial for everyone. Some of the biggest security failures have come from assumed leaders, which proves that continuous due diligence is a hallmark of a strong security program, not a sign of a weak vendor.

Overall, a fantastic contribution to the discussion. You've outlined what a truly robust vendor assessment process should look like.

 

[Andy Ful]

@Trident and @Divergent seem to be right in the context of general users who seek recommendations for the AV.
However, @cruelsiter is also right in the context of those who use Comodo for months/years.

For example, people who are happy with a small local grocery store will not check how the shop manager cares about the stable supply and other things, until they do not have problems with shopping. Especially when the fish are delivered directly from the fisherman.

 

[Trident]

Yes, vulnerabilities in AVs are nothing new.

In every piece of software, with every 10-line function that you add, you add at least one vulnerability. When you start fixing them in an attempt to create a more secure application, often the fix closes one loophole and adds 2 new ones. This is just how software development works.
And adding one dependancy adds a whole bunch of vulnerabilities plus the responsibility to quality test and update the dependancy as well. Any third-party code is the same responsibility as the code written inhouse.
AVs depend on third-party code for everything (from building the modules structure to decompressing to running machine learning models on the device).

But here we are discussing 2 different types of vulnerabilities:
-Vulnerability that despite frequent patching and code scanning wasn’t foreseen.
-Vulnerability that was already documented in a 30-page report.

There is very big difference between the two.

 

[ForgottenSeer 123960]

Yes, vulnerabilities in AVs are nothing new.

In every piece of software, with every 10-line function that you add, you add at least one vulnerability. When you start fixing them in an attempt to create a more secure application, often the fix closes one loophole and adds 2 new ones. This is just how software development works.
And adding one dependancy adds a whole bunch of vulnerabilities plus the responsibility to quality test and update the dependancy as well. Any third-party code is the same responsibility as the code written inhouse.
AVs depend on third-party code for everything (from building the modules structure to decompressing to running machine learning models on the device).

But here we are discussing 2 different types of vulnerabilities:
-Vulnerability that despite frequent patching and code scanning wasn’t foreseen.
-Vulnerability that was already documented in a 30-page report.

There is very big difference between the two.

You've perfectly crystallized the issue. The distinction you made between an unforeseen vulnerability and one that was "already documented in a 30-page report" is the entire crux of this matter.

Our primary concern must always be on that second category. While any vendor can be caught off-guard by a novel exploit, ignoring a publicly documented CVE isn't a development flaw, it's a fundamental failure of their security posture and due diligence.

This is precisely the point I was making in my initial post. A vendor's dismissive attitude toward documented flaws is the ultimate red flag. This case with Comodo is a textbook example of why our most non-negotiable principle must be a rigorous, independent assessment of any security product against known, documented vulnerabilities.

 

[Andy Ful]

But here we are discussing 2 different types of vulnerabilities:
-Vulnerability that despite frequent patching and code scanning wasn’t foreseen.
-Vulnerability that was already documented in a 30-page report.

There is very big difference between the two.

Like in other posts, this can be important for general users who seek recommendations for the AV.
Not important for Comodo users, because the alternative solutions (Home AVs) have even more dangerous security flaws.
It looks like Comodo users are practical. They don't have much hope that Comodo follows the standard norms.
They follow the known practical strategy: Do not change something that works well.

 

[stonjean633]

It all boils down to the risks appetite/tolerance of the user and the developer.

There are for certain situations risks that can be mitigated,ones that can be transferred,ones that can be avoided and ones that need to be accepted.

By using a vulnerable software and for this case an AV in Kernel Mode, peeps should start to question where they stand.

 

[ForgottenSeer 123960]

Like in other posts, this can be important for general users who seek recommendations for the AV.
Not important for Comodo users, because the alternative solutions (Home AVs) have even more dangerous security flaws.
It looks like Comodo users are practical. They don't have much hope that Comodo follows the standard norms.
They follow the known practical strategy: Do not change something that works well.

While user habits are one thing, we shouldn't confuse them with a sound security strategy. A product with documented, unpatched vulnerabilities is a known liability. On a forum like this, our standard for "practical" should be based on minimizing risk, not accepting it.

 

[Trident]

Like in other posts, this can be important for general users who seek recommendations for the AV.
Not important for Comodo users, because the alternative solutions (Home AVs) have even more dangerous security flaws.
It looks like Comodo users are practical. They don't have much hope that Comodo follows the standard norms.
They follow the known practical strategy: Do not change something that works well.

Well, this “if it ain’t broke, don’t fix it” strategy is why Comodo can be classified as nothing more than “good enough”. As said in other threads, the cards are on the table and users decide whether they wanna install software from professional businesses or software that is developed on a good will, charity-like basis.

“Other products are worse” is not a valid or proven fact/excuse.

Classifying the Comodo users as “practical” is not really a sound logic. Any practical person, given 2 options — “very good” and “simply ok” goes for the very good one.

Imagine that you are on the beach and you have 2 pavilions. One is selling Capri Sun (for 3 euro) and the other one is selling freshly squeezed juice and smoothies (also for 3 euro). Every “practical user” in their right mind will go for the freshly squeezed juice (even if issues like bees/wasps, dust/sand and so on) exist.

So the statement “Comodo users are practical” is very very questionable.

 

[Pico]

Being practical implies that one has the ability / capacity / knowledge to identify and workaround bugs and the like.
I don't see novice CIS users being that practical at all. Even for expert users things can get too complicated.

 

[Andy Ful]

While user habits are one thing, we shouldn't confuse them with a sound security strategy. A product with documented, unpatched vulnerabilities is a known liability. On a forum like this, our standard for "practical" should be based on minimizing risk, not accepting it.

The reasons are not only from the Comodo users' side. There are probably some objective reasons that there can be many happy Comodo users.
One of them is the fact that attackers are focused on compromising the AV next-gen features and do not bother about Comodo.
For similar reasons, Linux home users are probably more secure without AV than Windows users with standard AV.

 

[Andy Ful]

Being practical implies that one has the ability / capacity / knowledge to identify and workaround bugs and the like.
I don't see novice CIS users being that practical at all. Even for expert users things can get too complicated.

I do not see novice users who would like to use CIS.

 

[Andy Ful]

So the statement “Comodo users are practical” is very very questionable.

Maybe, but it is hardly possible to prove that they are wrong.
From the fact that we cannot prove this, it follows that we should not insist that they are wrong.
If you are right, they will skip Comodo without our help.

Edit.
I think that this proverb can be true in the case of Comodo users: "You can lead a horse to water but you can't make it drink."
A horse can have some good reasons for that, and usually knows better than the do-gooder on its back.

 

[ForgottenSeer 123960]

The reasons are not only from the Comodo users' side. There are probably some objective reasons that there can be many happy Comodo users.
One of them is the fact that attackers are focused on compromising the AV next-gen features and do not bother about Comodo.
For similar reasons, Linux home users are probably more secure without AV than Windows users with standard AV.

The comparison to Linux is interesting, but there's a key difference. Linux's security posture is a combination of its lower market share and its robust underlying architecture. In the argument you presented, the AV's security relies almost entirely on being ignored, which is a much more fragile position. A security product should be the wall protecting the city, not a city that's safe just because it's not on the map.

 

[Andy Ful]

A security product should be the wall protecting the city, not a city that's safe just because it's not on the map.

Yes, my post might be slightly unclear. In my analogy, Linux home users were intended to be an analogy only for the safety caused by "being under the radar". This is not an analogy for other reasons that make Comodo effective in practice.

Your "wall" contains mainly Allowlisting + Script Analysis, and your city is hidden. Furthermore, the unknown newcomers are thrown into the dungeon without a trial. That is why the citizens feel safe.
I doubt that they would feel safer in New York, full of cameras, policy databases, and face recognition AI.

 

[piquiteco]

I do not see novice users who would like to use CIS.

I would use the CIS.

 

[ForgottenSeer 123960]

Yes, my post might be slightly unclear. In my analogy, Linux home users were intended to be an analogy only for the safety caused by "being under the radar". This is not an analogy for other reasons that make Comodo effective in practice.

Your "wall" contains mainly Allowlisting + Script Analysis, and your city is hidden. Furthermore, the unknown newcomers are thrown into the dungeon without a trial. That is why the citizens feel safe.
I doubt that they would feel safer in New York, full of cameras, policy databases, and face recognition AI.

Andy, that's a very effective analogy. The 'walled city' that puts unknown newcomers 'into the dungeon' is a perfect description of a strong default-deny model, and you're right that it can provide a powerful sense of security.

However, this brings us directly back to the core problem with Comodo. The issue we've been discussing isn't about the strength of the dungeon or the height of the walls. It's about the gatekeepers knowingly ignoring a report that the main city gate has a broken lock. That's what an unpatched, documented CVE represents.

Your 'New York' full of cameras might seem chaotic, but at least its security team is actively trying to fix its broken cameras. The 'walled city' only feels safe. That feeling is a false one if the most fundamental entry point is known to be compromised and the guards are ignoring the warnings. A strong dungeon is useless if an attacker can just walk through the unlocked front gate.

 

[Pico]

Not important for Comodo users, because the alternative solutions (Home AVs) have even more dangerous security flaws.
It looks like Comodo users are practical. They don't have much hope that Comodo follows the standard norms.
They follow the known practical strategy: Do not change something that works well.

Using other AV and am very satisfied with it no dangerous security flaws or whatsoever never been infected or compromised because of its high level update standard.
Your statement about other AV having dangerous security flaws is so weak, it sounds like a Comodo commercial.

Comodo users do not need CIS updates nor new releases, never change a running system, if it ain’t broke don’t fix it, so practical.