Roadmap

Directions we intend to pursue

Capabilities we see the need for, and plan to add. None of this is work in progress, and none of it carries a date.

Coverage state on every source

An empty panel can mean three different things: the source was asked and found nothing, the source was asked and had never seen the file, or the source was never asked at all. Today those render the same way, and absence reads as an all-clear.

Each enrichment source will record which of those happened, and the panel that is empty will be the thing that says why, rather than a separate summary elsewhere on the page. It is the difference between a clean report and an incomplete one, and it should never take interpretation.

Re-analysis when the artifact changes

Software that updates itself invalidates its own approval. An approval granted against version 4.38 is not a statement about 4.41, and today nothing forces that question to be re-asked.

Re-analysis will trigger on version change rather than on a schedule, and surface what moved between the two readings, so the decision is about the delta rather than the whole file again.

More sources for the same pipeline

The connector is provider-agnostic and the scheduled scanner already runs against it; Google Drive works today. SharePoint and OneDrive are the same shape, and are the two we intend to add.

Capabilities we intend to rebuild

Two capabilities we intend to rebuild rather than extend, because the first implementations produced answers that were confidently wrong. Both are described here in full rather than quietly dropped.

Vulnerability correlation

We do not present this as working today. An earlier implementation ran against 160 real commercial installers and returned zero correct findings, plus a critical-severity advisory matched to entirely the wrong product. We would rather publish that than imply a precision we cannot demonstrate.

The cause is specific. Correlating software to a published advisory requires resolving the publisher and product against the advisory database’s own naming, and constraining the query to the exact version. Do the first without the second and you match every advisory that product ever had. Do the second without the first and you match the wrong product precisely. Both halves have to be right together, or neither is worth having.

What we intend is deliberately narrow. The platform will surface known CVEs associated with identified software. Confirming which of those genuinely apply to a specific binary, the applicability question, is the part we intend to deepen. Naming that limit is the point: an advisory that turns out not to apply is a stated boundary rather than a broken promise.

Two things would have to be true before it appears in a report. Versions extracted reliably from the artifact, and measured rather than assumed. And the whole path verified against a set of files whose correct answers were written down before the pipeline ran, including files whose correct answer is none. That set is specified; it is the gate.

Until then, reports state that advisory data was not consulted, rather than showing an empty section that could be mistaken for a clean result.

Publisher attribution from artifact evidence

Attribution has to come from something bound to the file: a signature chain, a verified repository owner, a registry account. An earlier version would fall back to the package name, which meant a common English word could be looked up and returned as a company, with a confidence grade attached to it.

The rebuild we intend removes the fallback entirely. Where nothing ties a publisher to the artifact, the report says no identity was established and grades nothing. An empty mark is a more precise statement than a confident wrong one.

What we do not intend to do

Exclusions with reasons. A roadmap without them is an infinite promise.

We do not run the file

Analysis is static, and stays static. Nothing uploaded is executed, evaluated or detonated. Detonation buys behaviour at the cost of an evasion arms race and of non-determinism: the same file can produce two different answers on two runs, which is fatal for a record you intend to keep. Structure, signatures, manifests and content are deterministic and reproducible years later.

We do not replace the controls you already run

This is not an endpoint detection product, a privilege manager, or a cloud access broker, and it does not want to be. It answers a question those tools are not designed to answer, and delivers the answer through them. A layer, not a replacement.

We do not present it as a reduction in people

The tool removes an unanswerable question from a queue. It does not remove the person holding the queue, and framing it that way would be both untrue and a poor argument to the person evaluating it.

Integrations, ticketing, notification and SIEM destinations among them, follow demand rather than a schedule: they are connectors onto a pipeline that already produces the record. What decides whether this tool is worth anything is above.