# Supply Chain Policy

The Supply Chain policy defines how scan results are classified as **Compliant** or **Noncompliant**. That status appears in the Asset Scans table on the Model Scanner page and on the Detection Summary page.

## Important Notes about Supply Chain Policy

- One Supply Chain policy applies to every scan in a HiddenLayer tenant. Runtime policy, by contrast, can differ by project.
- By default, models with any detection are **Noncompliant**.
- In the Console, choose which severity levels, detection categories, and file types count as **Noncompliant**.
- Through the API you can set compliance for combinations of severity, category, and file type.
- A new policy applies to scans that run after you save; existing scan rows are not rescanned or rewritten automatically.


## Update the policy in the Console

In the Console, you can select file attributes that meet your policy criteria.

1. In the Console, click **Supply Chain** in the side navigation.
2. Click **Policy** in the side navigation.
3. Click **Edit**.
4. For each attribute (severity, file types, and categories), select what belongs in the policy. Unselected values are ignored.


- Example: If **Low** is not selected, scans with only Low-severity detections are **Compliant**.


Edit threat levels in a model scan policy
1. Click **Save**.


## Advanced Supply Chain Policy via API

Using the HiddenLayer API, you can create a complex policy with multiple rules that factor file attributes detected from a scan. Policies can be based on Severity, File Type, Categories, License, and Country of Origin.

### How it works

1. **Baseline:** Any file with a detection is **Noncompliant**; files with no detections are **Compliant**.
2. **Rules:** Each rule tests the file against its conditions. If every condition in the rule matches (**AND** only), the rule sets the compliance flag you configured. If any condition fails, that rule leaves the status unchanged.


- Conditions can use severity, detection category, and file type.


Later rules override the outcome of earlier rules, so rule order is the priority order.

**Example:** A **pickle** file scans as **Suspicious Functions** at **Medium** severity. Custom rules are applied in this order:

| Step  | Rule | Resulting file status |
|  --- | --- | --- |
| 0 | Baseline: no custom rules applied. The file is Noncompliant because it has a Suspicious Functions detection. | Noncompliant |
| 1 | All pickle files are Noncompliant. | Noncompliant |
| 2 | All files with severity Medium are marked as Compliant. | Compliant |
| 3 | All files with Suspicious Functions category are Noncompliant. | Noncompliant |


The final status is **Noncompliant** because the last matching rule (step 3) prevails.

### Adding rules through the API

POST a policy with one or more rules. Each rule lists conditions (combined with **AND**) and `is_compliant_when_conditions_met`, which sets compliance when every condition matches.

API vs Console
Creating or updating Supply Chain policy through the API turns off policy editing in the Console. You can still revert to the default policy from the Console.

### `curl` example

This `POST /governance/v1/rule-sets` request creates a policy with one rule: when the file type is **pickle** and the detection category is **not** Repository Sideloading, `is_compliant_when_conditions_met: false` marks the scan **Noncompliant**.

- Replace `<new_policy_rule>` with a display name for your policy.
- Replace `<YOUR_TOKEN_HERE>` with the bearer token you generate using your HiddenLayer API key and secret.
- Use the API host for your environment (for example `https://api.hiddenlayer.ai` or `https://api.eu.hiddenlayer.ai`).
- For `file_type` conditions, `field_value` must match the file type string shown in the scan report for that file.


```
curl -i -X POST \
  'https://api.hiddenlayer.ai/governance/v1/rule-sets' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "display_name": <new_policy_rule>,
    "rules": [
      {
        "is_compliant_when_conditions_met": false,
        "conditions": [
          {
            "field": "file_type",
            "condition_operator": "equals",
            "field_value": "pickle"
          },
          {
            "field": "category",
            "condition_operator": "not_equals",
            "field_value": "Repository Sideloading"
          }
        ]
      }
    ]
  }'
```

## Policy Configurations

| Category  | Description | Available options  |
|  --- | --- | --- |
| Severity | Threat level from the scan.- Selected severities can mark a scan **Noncompliant**; unselected severities are ignored.
- Default: all levels selected.

 | Critical, High, Medium, Low |
| File types | The file types included in the policy.- Selected file types will label a model scan as **Noncompliant** if any selected threat levels are identified for the selected file types.
- All file types are selected by default.

 | NEMO, numpy, onnx, pickle, pytorch, RDS, safetensors, skops, tensorflow, unknown, ZIP, CONFIGURATION, GIT_CONFIGURATION, INITIALIZATION, JAVASCRIPT, MARKDOWN, PLAINTEXT, PNG, PYTHON, SHELL_SCRIPT, YAML, and TAR |
| Categories | Detection categories included in the policy.- Selected detection categories will label a model scan as **Noncompliant** if any selected file types have a selected threat level.
- All detection categories are selected by default.

 | XSS, CSRF, SSRF, Denial / Disruption of Service, Remote Code Execution, Improper Authentication, Unsecured Credential Storage, Arbitrary Code Execution, Arbitrary Read Access, Arbitrary Write Access, Arbitrary Read-Write Access, Out of Bounds Memory Read Access, Out of Bounds Memory Write Access, Network Requests, Suspicious Functions, Directory Traversal, Denial of Service, Decompression Vulnerabilities, Data Leakage Through Serialized Objects, Embedded Payloads, Fault Injection, Prompt Jailbreaking, Prompt Hijacking, Prompt Leaking, Indirect Prompt Injection, Code Injection, Excessive Agency/Permission Manipulation, Sensitive Data Leakage, Data Poisoning in Static ML, Data Poisoning in Online Learning, Data Poisoning in Federated Learning, Label Manipulation, Model Poisoning, Neural Payload, Graph Payload, Model Evasion, Training Data Extraction / PII Leakage, Model Extraction / IP Leakage, Membership Inference Attacks, Denial/Disruption of Service via Input Manipulation, Suspicious File Format, Repository Sideloading, Control Vector, and TokenBreak |


## Audit log

| Countries of Origin | Countries of Origin match against the first detected instance of a published model. | Any two-letter country code from [ISO 3166-1](https://www.iso.org/obp/ui/#search/code/). |
|  --- | --- | --- |
| Licenses | Selected license values are free-form text, which often match against SPDX IDs. | Any identifier from the [SPDX License List](https://spdx.org/licenses/). |