Why It Matters

SEC323 flags server.json auth-carrying header entries that use a value or variables without an explicit isSecret or is_secret marker.

This is not a literal-secret detector. It is a policy-shape rule for server registry entries: when an auth header carries credential material, the manifest should mark that fact explicitly so downstream tooling can treat it as secret-bearing config.

What Triggers

SEC323 applies to server.json remotes header entries and triggers when:

• the header looks auth-like, such as Authorization or x-api-key
• the header carries value or variable-backed material
• and the same header object does not explicitly set isSecret or is_secret to true

Example that triggers:

{
  "headers": [
    {
      "name": "x-api-key",
      "value": "{API_KEY}",
      "variables": {
        "API_KEY": { "description": "API key" }
      }
    }
  ]
}

Example that stays clean:

{
  "headers": [
    {
      "name": "x-api-key",
      "value": "{API_KEY}",
      "variables": {
        "API_KEY": { "description": "API key" }
      },
      "isSecret": true
    }
  ]
}

False Positives

This rule stays Preview because secret-policy expectations can vary across registry producers. The finding is useful as a consistency and secret-handling signal, but it is not equivalent to proving that a literal credential was committed.

Remediation

Mark auth-carrying header entries with isSecret: true or is_secret: true when they carry value or variable-backed credential material.