Security Scanning

Jozu Hub scans every AI artifact - models, agents, MCP servers, and datasets - and generates a consolidated security report on the AI artifacts. The report covers vulnerabilities in model weights, training data, prompts, and other AI-specific artifacts. These vulnerabilities are missed by container, code, and package scanners because those tools have no understanding of model weight formats, training data, prompts, or inference behavior.

On SaaS, scanning runs automatically on push and uses Jozu's default scanner configuration. On self-hosted deployments, scanning can also run on a configurable schedule, and the scanner configuration is customizable to match your organization's risk tolerances and compliance requirements.

Threat categories

Jozu Hub scans for vulnerabilities across nine threat categories. Results are shown in the UI, attached as attestations to the ModelKit itself (so the results are inseparable from the package and can be interrogated anywhere the package is sent), and are written to the audit log. Because attestations are part of the artifact itself, verification works in disconnected and air-gapped environments without callbacks to a central control plane.

Category	What Jozu Hub detects	Example
Malicious code execution	Code that executes when an artifact is loaded or deserialized, including unsafe pickle, joblib, and other formats that permit arbitrary code on load	A HuggingFace model containing a pickle payload that runs os.system calls during model.load()
Backdoored model behavior	Trojaned weights and trigger-activated misbehavior introduced during training or fine-tuning	An image classifier that labels any image containing a specific pixel pattern as "authorized," regardless of actual content
Data poisoning	Indicators of training data tampering, distribution anomalies, and signatures consistent with poisoning attacks	A sentiment model trained on reviews seeded with adversarial examples to misclassify a specific brand as negative
Adversarial robustness gaps	Susceptibility to evasion attacks, gradient-based perturbations, transfer attacks, and crafted inputs that cause misclassification	A vision model that misclassifies a stop sign as a speed limit sign when imperceptible noise is added to the image
Prompt injection	Vulnerability to direct and indirect prompt injection, jailbreaks, and system prompt extraction across user input, retrieved content, tool descriptions, and MCP server responses	An MCP tool whose description contains hidden instructions that override the agent's system prompt when the tool is registered
Sensitive data leakage	PII exposure, training data extraction vulnerabilities, and secret leakage in model outputs	A fine-tuned model that reproduces social security numbers from its training data when prompted with specific patterns
Content safety failures	Toxicity, bias, harassment, and harmful content generation under adversarial and standard prompts	A customer-facing chatbot that produces targeted harassment when prompted with specific role-play scenarios
License and compliance violations	Restrictive licenses, missing attribution, and license terms that conflict with intended use	An unrecognized license (Jozu SaaS or On-Prem), or a license that is disallowed by the organization (Jozu On-Prem only)
Dependency vulnerabilities	Known CVEs and outdated versions in code, libraries, and runtime dependencies bundled with the artifact	A model packaged with a vulnerable version of transformers that exposes a known remote code execution path

Severity and scoring

While the Jozu Hub UI includes severity indicators for each vulnerability scan finding, the attestations that are signed and tied to the artifact itself report the raw findings - their own scoring values, scanner-defined labels, category tags, and pass/fail/skip/error status. This is deliberate. Different scanners measure different things on different scales, so a normalized number across scanners would be misleading. And what counts as "high severity" varies by deployment context - a finding that blocks a regulated workload may be acceptable in a research sandbox.

Scan results and attestations

After scanning completes, Jozu Hub signs the results and attaches them to the registry as an attestation bound to the ModelKit's SHA-256 digest. The attestation is stored in the same registry as the ModelKit, as a sibling tag derived from the digest, so any environment that has mirrored both the ModelKit and its sibling attestation tag can verify scan results locally with no callback to Hub.

Because the attestation is bound to the artifact's SHA-256 digest, it cannot be reused for a different artifact or detached and reattached without invalidating the signature. If the artifact or scan attestation is modified after scanning, the digest changes and verification fails.

Interrogating attestations outside Jozu Hub

Scan attestations are standard Cosign-signed artifacts stored in the registry alongside the ModelKit, and can be inspected with any compatible tooling, with no connection to Hub required at verify time. Refer to the Cosign documentation for details on listing and verifying attestations in your environment.

The verified payload is a JSON document containing the scan result summary, the artifact digest it applies to, the timestamp, and the signing key reference. For the wire-format details, see the ModelKit Attestation Format reference.