Most security products ask you to trust a number. ESIP asks you to check one. Every signal traces to public evidence you can verify, reproduces the same way every time, and carries the authority of the person who formalized how this field measures maturity. This page is why the signal layer can be relied on.
Every signal traces to a public source: a government exploitation catalog, an exploit repository, a prediction score, a patch record. ESIP does not ask you to take its word. The evidence under each verdict is named, dated, and linkable, so you can go and look.
Run the same evidence under the same rules and ESIP produces the same verdict, every time. It is reproducible and replayable, not a score that drifts between runs. A verdict you cannot reproduce is one you cannot defend, so determinism is the foundation here, not a feature.
Anyone querying the same published snapshot can reproduce the same verdict. A decision you made on a Tuesday can be re-derived by someone else, months later, from the same public evidence. The verdict is not locked inside ESIP; it is checkable from outside.
Integrity here is a set of refusals. ESIP fires a signal only when the exploitation state materially moves, so a signal means something when it appears. It publishes no number it cannot evidence, no coverage figure it has not measured, and no black-box score. And it never treats quiet as safe: the absence of a signal means ESIP has not seen enough public evidence to produce one, not that an exposure is harmless. Accurate and modest beats impressive and false, every time.
ESIP draws only on globally observable evidence: public sources anyone can check, never your environment. Sources are grouped by the job they do: those that fire a signal, those that add context, and those that establish identity. A signal describes an exposure class, not your assets, so you apply your own context to it. How the mechanism turns that evidence into a verdict is its own page.
How it works →ESIP was built by Jonathan Risto, a SANS Principal Instructor and the creator of the Vulnerability Management Maturity Model and the CTEM Maturity Model, the frameworks many teams use to measure how mature their vulnerability and exposure programs are. That experience, helping shape how organizations measure vulnerability and exposure management, informs ESIP's thresholds, its restraint, and its refusal to over-signal. It is also why an exposure signal is published as a reference rather than a product claim: the definition is authored by someone who has spent years formalizing how the discipline should work, and ESIP is its implementation.
The definition →Put together, this is what ESIP is for: not only to tell you what changed, but to let you defend acting on it. Provenance, determinism, and reproducibility mean you can explain a prioritization decision to an auditor, an executive, or a board, months after you made it, and trace every part of it back to public evidence.
The full picture for a formal review: the published reference defines the term and the model, the data license sets out how the data may be used, and the deployment and security model covers how ESIP runs.