Scan Result Descriptions - HiddenLayer Docs

Scan results use the v3 report schema. The sections below describe the fields you typically use when reading CLI or API output. For the full schema, see the Get scan results API in the HiddenLayer Developer Portal (Console login required).

Detections — Known exploits in model files. Ranked from Critical to Low severity and usable in Supply Chain policy.
Advisories — Files or patterns of concern that are not exploits by themselves. Review before model usage.

Report structure

Section	Description
`scan_id`, `status`, `start_time`, `end_time`, `version`, `$schema_version`	Scan identity, lifecycle status (`pending`, `running`, `done`, `failed`, `canceled`), timing, and schema/scanner versions.
`inventory`	Model identity and scan request context (name, version, source, requested location, origin, provider details when available).
`intelligence`	Optional model intelligence such as country of origin, licenses, and usage policies.
`summary`	Aggregate counts and highest severity across the scan. Prefer these fields over deprecated top-level duplicates such as `detection_count` or `severity`.
`compliance`	Optional compliance evaluation status (`COMPLIANT` / `NONCOMPLIANT`) and related rule set metadata.
`file_results`	Per-file scan details, hashes, file type metadata, detections, advisories, and scan errors.

Summary fields

Field	Description
`summary.highest_severity`	Highest severity among detections: `critical`, `high`, `medium`, `low`, `none`, or `unknown`.
`summary.detection_count`	Total number of detections.
`summary.advisory_count`	Total number of advisories.
`summary.file_count`	Total number of files scanned.
`summary.files_with_detections_count`	Number of files that contain detections.
`summary.detection_categories`	Unique detection categories found in the scan.
`summary.advisory_categories`	Unique advisory categories found in the scan.
`summary.files_failed_to_scan`	Number of files that failed during scanning.
`summary.unknown_files`	Number of files with an unknown file type.
`summary.mitre_atlas`	Deduplicated MITRE ATLAS tactic/technique pairs across all detections.
`summary.referenced_models`	Deduplicated list of external artifact URIs (typically `ngc://...?file=...`) parsed from a NIM container’s `model_manifest.yaml`. These URIs are informational; the referenced files are not scanned automatically. Download artifacts with the NGC CLI and scan them separately. See NIM Container Scanning.

File results

Each entry in file_results describes one scanned file.

Field	Description
`file_instance_id`	Unique ID for the file instance in this scan.
`file_location`	Full path or location of the file.
`status`	File scan status: `skipped`, `pending`, `running`, `done`, `failed`, or `canceled`.
`start_time` / `end_time` / `seen`	Timing for when the file scan started, ended, and was observed.
`details.md5` / `details.sha256` / `details.tlsh`	File hashes when available.
`details.file_size` / `details.file_size_bytes`	File size in human-readable form and bytes.
`details.file_type`	Detected file type (for example, `pickle`, `safetensors`, `keras`).
`details.file_type_details`	Format-specific metadata. Contents vary by file type; see Type-specific evidence.
`detections`	Array of detections for this file.
`advisories`	Array of informational advisories for this file.
`file_error`	Error messages returned by the scanner for this file, if any.

Detections

Present when a file triggers a detection rule.

Field	Description
`detection_id`	Unique identifier for the detection.
`rule_id`	Identifier of the rule that produced the detection (for example, `PICKLE_0055_202408`).
`risk`	Detection risk: `MALICIOUS` or `SUSPICIOUS`.
`category`	Vulnerability category (for example, Arbitrary Code Execution).
`description`	Why the detection was raised.
`likelihood` / `impact` / `severity`	Likelihood, impact, and severity (`critical`, `high`, `medium`, `low`) for the finding.
`mitre_atlas`	Related MITRE ATLAS tactics and techniques.
`owasp`	Related OWASP labels.
`cve` / `cwe` / `cwe_href`	Related CVE and CWE identifiers, plus a CWE URL when available.
`technical_blog_href` / `technical_blog_hrefs`	Links to HiddenLayer technical blog posts related to the finding.
`rule_details`	Optional rule lifecycle notes (for example, deprecated or superseded).

Advisories

Informational findings that are not exploits by themselves (for example, tokenizer family or container manifest notes).

Field	Description
`advisory_id`	Unique identifier for the advisory.
`rule_id`	Identifier of the rule that produced the advisory.
`category`	Advisory category (for example, TokenBreak).
`description`	Why the advisory was raised.

Type-specific evidence

file_results[].details.file_type_details includes extra fields for some model formats. Use these fields to understand format metadata that often contextualizes detections.

File type	Evidence fields	What they tell you
GGUF	`subtype`	Format subtype metadata for the GGUF file.
Keras	`subtype`, `keras_version`, `pickle_modules`, `keras_class_name`, `keras_date_saved_at`, `keras_module`	Keras version and module/class metadata. `pickle_modules` lists embedded pickle modules that can relate to arbitrary code execution findings.
NumPy	`subtype`, `numpy_arrays`, `numpy_shape`	Number of arrays and their shapes in the NumPy file.
RDS	`subtype`, `rds_encoding`, `rds_min_reader_version`, `rds_version`, `rds_writer_version`	R serialization version and encoding metadata for the RDS file.
Pickle	`subtype`, `pickle_modules`, `pickle_header` (when present)	Libraries/modules referenced by the pickle and header metadata such as pickle version. Useful when reviewing code-execution related detections.

Not every file type populates file_type_details. Empty objects are normal for formats that do not expose additional metadata.

​Report structure

​Summary fields

​File results

​Detections

​Advisories

​Type-specific evidence

Report structure

Summary fields

File results

Detections

Advisories

Type-specific evidence