Technical Concepts
Determinism and pinning
Why every input that can change a score is pinned and recorded, so a result is reproducible and a methodology change is never silent.
What is pinned
| Input | Why |
|---|---|
| The scanner version | Changes which checks exist, and therefore the denominator |
| The severity scope | Changes which checks are collected at all |
| The dependency set | Installed from a hash-verified lock, so a compromised index cannot substitute a package into a job that will hold a session in your account |
| The scoring constants | Fingerprinted, so a change is detectable in the next comparison |
| The mapping version | Recorded, so a pack traces to the wording that produced it |
Why pinning is a governance property, not a build preference
An unpinned scanner changes every customer's score on a day nobody chose, with nothing failing and no record of what changed.
Ordering that matters
Dependencies are installed before any credential for your account exists in the environment. Installation executes upstream code, and running it while a live session is present would put that session within reach of any compromised package.
What is recorded with every result
Engine version, scanner version, severity scope, regions, confidence and generation time, stored independently of both the pack and the workflow platform.
What it does not mean
Determinism means the same evidence yields the same score. It does not mean two assessments of the same account must agree: the environment changes, and so may the methodology, which is what the fingerprint exists to detect.