Known Vulnerability Rules

Detects known vulnerable packages, runtimes, model-serving components, and scanner advisory matches.

Definition

The CVE rule family turns findings on this surface into actionable records with rule ID, severity, CWE, OWASP LLM mapping, owner, release decision, and retest command.

AI stacks depend on fast-moving runtimes, native parsers, inference servers, and supply-chain packages. Known CVEs can become direct compromise paths.

Canonical help URL

Supported inputs

package lockfiles
SBOM
container manifests
Python metadata
Node metadata
model server banners

Typical attack scenarios

A model-serving runtime includes a known RCE CVE.
A notebook image ships an old parser vulnerable to archive traversal.
A dependency is no longer maintained and remains exposed in CI.

Detection logic

Sentinel ties CVE evidence to reproducible signals such as file path, metadata, opcode, AST node, manifest field, dependency, or archive entry. The same signal should disappear when the finding is closed.

Triage

Do not read CVE findings as scanner noise. Verify the evidence first, map the finding to a severity-based release decision, and then produce closure evidence with the same Sentinel command.

Operational checklist

Source: where did the file, manifest, prompt, archive, or dependency come from?
Impact: code execution, data leakage, supply chain, or resource consumption?
Control: allowlist, hash, sandbox, egress policy, or secret rotation?
Evidence: does the same rule category return clean after the fix?

Remediation

Remediation should change the risk boundary, not merely silence the finding: remove executable formats, pin source or hash, narrow tool permissions, rotate secrets, or add runtime sandboxing.

CI policy

sentinel-policy.yml

category: CVE
fail_on:
  - CRITICAL
  - HIGH
ticket_on:
  - MEDIUM
retest: "sentinel scan ./project/"

Rule index

Rule ID	Severity	Title	CWE	Fix Hint
CVE-KNOWN-EXPLOITED	CRITICAL	Known Exploited Vulnerability	CWE-1104	Upgrade to a fixed version before release.
CVE-VULNERABLE-RUNTIME	HIGH	Vulnerable AI Runtime Component	CWE-1104	Patch model-serving and parser dependencies.
CVE-STALE-ADVISORY-DATA	INFO	Stale Advisory Data	CWE-1104	Keep vulnerability intelligence current.

CVE-KNOWN-EXPLOITED — Known Exploited Vulnerability

CRITICAL

Rule ID	CVE-KNOWN-EXPLOITED
Category	CVE
Severity	CRITICAL
CWE	CWE-1104
OWASP LLM	LLM03 — Supply Chain
FP Risk	LOW
Owner	Platform, DevOps, and dependency owner
Release decision	Block release; do not promote the artifact or code path until it is isolated.

Description

Flags dependencies or runtime components matching known exploited CVEs or emergency advisories.

Why it matters

AI stacks depend on fast-moving runtimes, native parsers, inference servers, and supply-chain packages. Known CVEs can become direct compromise paths.

When it fires

Sentinel fires this rule in the CVE category when it sees package name, version, cpe, purl, or container layer matches advisory data marked exploited or urgent.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Package name, version, CPE, PURL, or container layer matches advisory data marked exploited or urgent.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is low. If evidence points directly to a file, opcode, secret pattern, path, or manifest field, treat it as real and require closure evidence.

Triage

Operational checklist

Owner: Platform, DevOps, and dependency owner.
Decision: Block release; do not promote the artifact or code path until it is isolated.
Evidence: Package name, version, CPE, PURL, or container layer matches advisory data marked exploited or urgent.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Patch immediately, isolate exposed workloads, and review logs for exploitation indicators.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  CVE-KNOWN-EXPLOITED:
    owner: "Platform, DevOps, and dependency owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

CVE-KNOWN-EXPLOITED CRITICAL
Known Exploited Vulnerability
Upgrade to a fixed version before release.

Example

Bad

torchserve==0.8.0
vulnerable-parser==1.2.1

Good

torchserve==0.11.1
# SBOM generated and checked during release.

Related rules

CVE-VULNERABLE-RUNTIME: Vulnerable AI Runtime Component
CVE-STALE-ADVISORY-DATA: Stale Advisory Data

CVE-VULNERABLE-RUNTIME — Vulnerable AI Runtime Component

HIGH

Rule ID	CVE-VULNERABLE-RUNTIME
Category	CVE
Severity	HIGH
CWE	CWE-1104
OWASP LLM	LLM03 — Supply Chain
FP Risk	MEDIUM
Owner	Platform, DevOps, and dependency owner
Release decision	Treat as a release gate; remediation or explicit risk acceptance is required.

Description

Detects vulnerable inference runtimes, parsers, notebook servers, or model-serving libraries.

Why it matters

AI stacks depend on fast-moving runtimes, native parsers, inference servers, and supply-chain packages. Known CVEs can become direct compromise paths.

When it fires

Sentinel fires this rule in the CVE category when it sees sbom or lockfile version falls inside a vulnerable range.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

SBOM or lockfile version falls inside a vulnerable range.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is medium. Verify source, expected use, and owner first; add an allowlist if needed, but do not remove evidence from the report.

Triage

Operational checklist

Owner: Platform, DevOps, and dependency owner.
Decision: Treat as a release gate; remediation or explicit risk acceptance is required.
Evidence: SBOM or lockfile version falls inside a vulnerable range.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Upgrade the affected component and rerun the scanner against the rebuilt artifact.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  CVE-VULNERABLE-RUNTIME:
    owner: "Platform, DevOps, and dependency owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

CVE-VULNERABLE-RUNTIME HIGH
Vulnerable AI Runtime Component
Patch model-serving and parser dependencies.

Example

Bad

torchserve==0.8.0
vulnerable-parser==1.2.1

Good

torchserve==0.11.1
# SBOM generated and checked during release.

Related rules

CVE-KNOWN-EXPLOITED: Known Exploited Vulnerability
CVE-STALE-ADVISORY-DATA: Stale Advisory Data

CVE-STALE-ADVISORY-DATA — Stale Advisory Data

INFO

Rule ID	CVE-STALE-ADVISORY-DATA
Category	CVE
Severity	INFO
CWE	CWE-1104
OWASP LLM	LLM03 — Supply Chain
FP Risk	LOW
Owner	Platform, DevOps, and dependency owner
Release decision	Keep for inventory and context; do not treat as a vulnerability by itself.

Description

Reports scans that used advisory data older than the configured freshness threshold.

Why it matters

AI stacks depend on fast-moving runtimes, native parsers, inference servers, and supply-chain packages. Known CVEs can become direct compromise paths.

When it fires

Sentinel fires this rule in the CVE category when it sees advisory database timestamp exceeds the policy age limit.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Advisory database timestamp exceeds the policy age limit.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is low. If evidence points directly to a file, opcode, secret pattern, path, or manifest field, treat it as real and require closure evidence.

Triage

Operational checklist

Owner: Platform, DevOps, and dependency owner.
Decision: Keep for inventory and context; do not treat as a vulnerability by itself.
Evidence: Advisory database timestamp exceeds the policy age limit.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Refresh advisory data in CI and rerun vulnerability checks.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  CVE-STALE-ADVISORY-DATA:
    owner: "Platform, DevOps, and dependency owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

CVE-STALE-ADVISORY-DATA INFO
Stale Advisory Data
Keep vulnerability intelligence current.

Example

Bad

torchserve==0.8.0
vulnerable-parser==1.2.1

Good

torchserve==0.11.1
# SBOM generated and checked during release.

Related rules

CVE-KNOWN-EXPLOITED: Known Exploited Vulnerability
CVE-VULNERABLE-RUNTIME: Vulnerable AI Runtime Component

References

PreviousJIT NextOCI