Assessment Methodology
The control contract
The scanner version and severity scope are part of the published methodology, because changing either changes every customer score at once.
Security coverage is produced by an external scanner. That makes the scanner's version and scope part of this product's methodology, not an implementation detail.
What is fixed
| Term | Value |
|---|---|
| Scanner | Prowler |
| Version | 5.37.1, pinned |
| Severities collected | critical, high, medium |
| Severities never collected | low, informational |
| Minimum control population for a rating | 25 |
| Typical control population | roughly 150 to 400 |
Why the version is pinned
An upgrade changes which checks exist. That changes the denominator of the weighted pass rate, which changes every customer's score, silently, with nothing failing.
The version is therefore recorded in the contract and pinned in the dependency set, and a test fails if the two drift apart. A scanner upgrade becomes a deliberate two-file change with a reviewer looking at the scoring consequence.
Why low severity is excluded
The scan is invoked at critical, high and medium. Low findings are never collected, so they cannot appear in the pack and cannot affect the score. Widening the scope would change the denominator and is a methodology change, not a configuration tweak.
The typical population, and why it is published
A control population far outside the usual range on a real account is a signal that the scan did not do what it normally does: a permission gap, a region filter, or a scanner change.
The pack reports the count so a reader can notice that for themselves. Below the minimum of 25 the security domain is not rated at all, because a population that small cannot support a governance conclusion.
Traceability
Each pack can be traced to the exact mapping version that produced its customer-facing language, so wording that appeared in an older pack can be identified rather than guessed at.