HAPは脆弱性としては最悪の部類に入る。同氏はこれを、「企業を破滅に追いやる可能性があるイベント」と表現している。では、システムのHAPはどのようにして測定できるのだろうか？同氏は以下のように説明している。
HAPを測定するための定量的アプローチでは、Linuxカーネルにおけるコードのバグ密度を、システムが定常状態に至るまで（つまり、カーネル中の新たなパスを処理していないように見受けられる状態に至るまで）のパス上にあるユニークなコードの量と、掛け算する。この手法を採用するにあたってわれわれは、バグの密度が均一だと仮定した。これによりHAPは定常状態に至るまでのパス上にあるコードの量で近似できるようになる。ただ、こういった値を稼働中のシステムで測定するのは、まったく別の話となる。しかし幸いなことに、カーネルには指定したユーザー空間のプロセスから呼び出されるすべての関数のトレースを取得するftraceと呼ばれるメカニズムがあるため、パス上にあるコードの行数を近似値で見積もれる（なお、この値は呼び出された関数全体を構成するコードの行数を使用し、関数内におけるパスを考慮していないため、概算値だという点に注意されたい。というのも、ftraceではそれ以上の情報が得られないためだ）。なお、コンテナの場合、すべての制御フローはシステムコール情報を介して既知のプロセスから処理が渡っていくため、この手法はとてもうまく適用できる。ただ、ハイパーバイザの場合、直接ハイパーコールを呼び出すインターフェースだけでなく、バックエンドのデーモン（kvmのvhostにおけるカーネルスレッドや、Xenにおけるdom0など）のトレースを取得する必要があるため、それほどうまく適用することはできない。
詰まるところ、ベアメタルであるか、VMであるか、コンテナであるかにかかわらず、指定したアプリケーションを実行することで、システムにおけるコードの行数を測定するというわけだ。実行するコードが多ければ多いほど、HAPレベルの脆弱性を抱えている可能性が高まる。
HAPとその測定方法を定義したことで、Bottomley氏はredis-bench-setとredis-bench-get、python-tornado、node-expressという複数の標準的なベンチマークを実行した。最後の2つは、外部クライアントから簡単なトランザクションを発行するウェブサーバも実行している。同氏は、Dockerと、Googleのコンテナ実行サンドボックスであるgVisor、Linuxの組み込みVMハイパーバイザであるKVMを用いたバージョンのgVisorであるgVisor-kvm、オープンソースの軽量VMであるKata Containers、強力なサーバ隔離を実現するためにIBMが設計した新たなコンテナ型であるNablaを用いてこれらのテストを実行した。
