What this covers
A plugin can tell you a condition exists. It cannot tell you what it enables.
ThreatCanary keeps broad predefined coverage, then adapts testing to the target and validates the path to impact.
01Where scanners stop
- Traditional scanners execute predefined plugins such as NASL checks against expected products and conditions.
- Many checks rely on versions, banners, configuration signals or a fixed request-and-match sequence.
- The result identifies a possible condition but usually does not establish whether an attacker can use it in this environment.
02How ThreatCanary continues
- Use service, API, identity and graph context to form a target-specific hypothesis.
- Adapt the test sequence when the observed behaviour does not match the expected product path.
- Generate a controlled test when no existing capability answers the security question.
03What gets proven
- Whether the weakness is reachable under the real control state.
- Whether it produces a usable outcome or participates in a wider attack path.
- Which evidence is reproducible and which assumption failed.
04Operational difference
- Scanner output remains useful as an input—not the final verdict.
- Failed validation is retained as evidence rather than discarded.
- Remediation priority follows demonstrated impact instead of plugin severity alone.
