Skip to content

Scan Result Descriptions

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

SectionDescription
scan_id, status, start_time, end_time, version, $schema_versionScan identity, lifecycle status (pending, running, done, failed, canceled), timing, and schema/scanner versions.
inventoryModel identity and scan request context (name, version, source, requested location, origin, provider details when available).
intelligenceOptional model intelligence such as country of origin, licenses, and usage policies.
summaryAggregate counts and highest severity across the scan. Prefer these fields over deprecated top-level duplicates such as detection_count or severity.
complianceOptional compliance evaluation status (COMPLIANT / NONCOMPLIANT) and related rule set metadata.
file_resultsPer-file scan details, hashes, file type metadata, detections, advisories, and scan errors.

Summary fields

FieldDescription
summary.highest_severityHighest severity among detections: critical, high, medium, low, none, or unknown.
summary.detection_countTotal number of detections.
summary.advisory_countTotal number of advisories.
summary.file_countTotal number of files scanned.
summary.files_with_detections_countNumber of files that contain detections.
summary.detection_categoriesUnique detection categories found in the scan.
summary.advisory_categoriesUnique advisory categories found in the scan.
summary.files_failed_to_scanNumber of files that failed during scanning.
summary.unknown_filesNumber of files with an unknown file type.
summary.mitre_atlasDeduplicated MITRE ATLAS tactic/technique pairs across all detections.
summary.referenced_modelsDeduplicated 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.

FieldDescription
file_instance_idUnique ID for the file instance in this scan.
file_locationFull path or location of the file.
statusFile scan status: skipped, pending, running, done, failed, or canceled.
start_time / end_time / seenTiming for when the file scan started, ended, and was observed.
details.md5 / details.sha256 / details.tlshFile hashes when available.
details.file_size / details.file_size_bytesFile size in human-readable form and bytes.
details.file_typeDetected file type (for example, pickle, safetensors, keras).
details.file_type_detailsFormat-specific metadata. Contents vary by file type; see Type-specific evidence.
detectionsArray of detections for this file.
advisoriesArray of informational advisories for this file.
file_errorError messages returned by the scanner for this file, if any.

Detections

Present when a file triggers a detection rule.

FieldDescription
detection_idUnique identifier for the detection.
rule_idIdentifier of the rule that produced the detection (for example, PICKLE_0055_202408).
riskDetection risk: MALICIOUS or SUSPICIOUS.
categoryVulnerability category (for example, Arbitrary Code Execution).
descriptionWhy the detection was raised.
likelihood / impact / severityLikelihood, impact, and severity (critical, high, medium, low) for the finding.
mitre_atlasRelated MITRE ATLAS tactics and techniques.
owaspRelated OWASP labels.
cve / cwe / cwe_hrefRelated CVE and CWE identifiers, plus a CWE URL when available.
technical_blog_href / technical_blog_hrefsLinks to HiddenLayer technical blog posts related to the finding.
rule_detailsOptional 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).

FieldDescription
advisory_idUnique identifier for the advisory.
rule_idIdentifier of the rule that produced the advisory.
categoryAdvisory category (for example, TokenBreak).
descriptionWhy 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 typeEvidence fieldsWhat they tell you
GGUFsubtypeFormat subtype metadata for the GGUF file.
Kerassubtype, keras_version, pickle_modules, keras_class_name, keras_date_saved_at, keras_moduleKeras version and module/class metadata. pickle_modules lists embedded pickle modules that can relate to arbitrary code execution findings.
NumPysubtype, numpy_arrays, numpy_shapeNumber of arrays and their shapes in the NumPy file.
RDSsubtype, rds_encoding, rds_min_reader_version, rds_version, rds_writer_versionR serialization version and encoding metadata for the RDS file.
Picklesubtype, 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.