Credential exposure, third parties and reach

Some public evidence is worth weighing. Staff credential exposure is the clearest example: it says something about a vendor's own operational hygiene, which is exactly what you are trusting when you install their agent with kernel privileges.

Three things worth weighing

• Staff credential exposure, weighted by recency. Credentials belonging to the vendor's own employees appearing in infostealer sets. Recent matters far more than historic; a 2019 exposure in a company that has since rebuilt its identity estate is a different fact from one from last month.
• Third-party breadth. How many external services the vendor's own estate depends on. Every one is another way in, and a security vendor with a sprawling supply chain has a larger problem than the same sprawl at a company that is not a target.
• Reach. What those exposed staff credentials actually open. An exposed credential to a marketing tool and an exposed credential to a source repository are not the same finding, and treating them the same is how exposure scoring becomes noise.

One thing worth showing and never scoring

Customer-side exposure — credentials belonging to users of the product — measures the customers' endpoint hygiene, not the vendor's. Scoring it penalises the vendor for being popular. DBSE displays that number and deliberately keeps it out of every score, and a test in the codebase enforces that it stays out.

Contradictory sources

Public exposure feeds often contradict themselves: a headline that says "seen five days ago" over strict fields that say the last confirmed credential was 2022. When a source disagrees with itself, take the strict, dated field and ignore the headline. If you cannot tell which field is which, the source is not usable evidence yet.