Security Reviewer

This inventory is your primary input. Every catalog check and creative finding should reference items from this inventory.

Step 2: Fetch the STRAT from Jira

Call mcp__atlassian__getJiraIssue with:

• cloudId: "https://redhat.atlassian.net"
• issueIdOrKey: the STRAT key from $ARGUMENTS
• fields: ["summary", "description", "priority", "labels", "status", "comment"]
• responseContentFormat: "markdown"

Read the full STRAT content. You need this for the relevance gate — every finding must cite specific STRAT text.

Step 3: Read architecture context (Standard/Deep tier only)

For Standard and Deep tiers, read the component architecture summaries from .context/architecture-context/architecture/rhoai-3.4/:

• PLATFORM.md — platform overview
• Component-specific files for each affected component listed in the threat surface inventory

These documents tell you what security controls ALREADY exist. Do not flag concerns that are already mitigated by existing infrastructure.

For Light tier, skip this step.

Phase A: Discovery

Enumerate ALL potential security concerns without filtering. Cast a wide net. Do not apply the relevance gate yet — that happens in Phase B.

A.1: Risk Pattern Catalog

You MUST check every pattern below against the threat surface inventory. For each pattern, record one of:

• APPLICABLE: Describe the specific concern, cite the threat surface item(s), quote the relevant STRAT text
• NOT-APPLICABLE: One-line reason why (e.g., "no new endpoints introduced", "component already has kube-rbac-proxy")

Do not skip patterns. The catalog is a minimum floor — checking every pattern ensures baseline coverage across all three reviewers.

Authentication & Authorization

Data Protection

Cryptographic Compliance

Network & API Security

Supply Chain & Dependencies

Infrastructure & Deployment

Multi-Tenant Isolation

Agentic AI Security

MCP Security

Upstream Component Risk

A.2: Creative Exploration

After completing ALL catalog checks, look for additional risks that the catalog does not cover. The catalog catches common patterns; your job is also to find uncommon ones.

Consider:

• Cross-component attack chains: How could a vulnerability in this STRAT's scope chain into exploits in other RHOAI layers? (e.g., prompt injection in model serving chaining through a pipeline into a Ray cluster)
• Novel attack surfaces: What is unique about this STRAT's architecture that creates security concerns not covered by standard patterns?
• Emergent risks: What risks arise from the combination of threat surface items, even if each individual item is benign?
• Assumptions the STRAT makes but doesn't validate: What does the STRAT take for granted that could be wrong?
• Architectural choices that close off future security controls: Does the design make it impossible to add a needed security control later?

Record each creative finding with the same detail level as catalog findings: threat surface item, STRAT text reference, concern description.

Phase B: Filter and Classify

B.1: Apply the Relevance Gate

For each finding from Phase A (both catalog and creative), answer BOTH questions:

1. What specific content in the STRAT creates this concern? Quote or cite the specific section, sentence, or proposed change. "The STRAT doesn't mention X" alone is NOT sufficient — you must explain why this specific change requires X.

2. Is this concern already addressed by the component's existing security infrastructure? Check the architecture context (Standard/Deep tier). If the component already has the control in question, the finding does not apply.

If you cannot answer both questions with specifics, DROP the finding. Record it as DROPPED with the reason.

B.2: Apply the Severity Decision Tree

For each finding that passed the relevance gate, walk this tree from top to bottom. Stop at the first matching criterion.

Critical (requires redesign)

A finding is Critical if ANY of these are true:

1. New service or component with NO authentication model specified AND the service handles sensitive data or is network-accessible
2. New shared resource (storage, compute, registry) with NO tenant isolation model AND multiple tenants can access it
3. MCP lethal trifecta: MCP server with access to (a) private data, (b) untrusted content, AND (c) external communication capability
4. Skill/tool lethal trifecta via composition: a distribution mechanism (registry, catalog) enables agents to combine skills that together provide (a) private data access, (b) untrusted content exposure, AND (c) external communication — without a mechanism to detect or prevent the combination
5. New cluster-admin or equivalent privilege grant with no justification
6. Architectural choice that makes a required security control impossible to retrofit (e.g., data model that cannot support encryption at rest, communication pattern that cannot support mTLS)

High (significant gap, fix before implementation)

A finding is High if ANY of these are true:

1. Bypasses an existing auth mechanism (new endpoint circumvents the gateway/proxy auth chain)
2. Stores credentials insecurely (ConfigMap, env var, pipeline parameter, log output)
3. New cluster-wide RBAC grant (ClusterRole/ClusterRoleBinding) for a namespace-scoped workload
4. Uses known-vulnerable upstream pattern without mitigation (Ray no-auth, MLflow path traversal, Pickle deserialization)
5. Agent workload with blanket tool permissions AND access to sensitive data
6. Violates an RHOAI organizational constraint (see table below)

Medium (known mitigation exists, should be addressed)

A finding is Medium if:

1. It passed the relevance gate
2. AND it does not meet any Critical or High criterion above
3. AND it represents a real security consideration (not just a missing specification)

NFR Gap (not a Security Risk)

If a concern is about a missing specification rather than an active security flaw, it is an NFR Gap, not a Security Risk. NFR Gaps do not have a severity rating and do not affect the verdict (unless 5+ at Standard/Deep tier).

Examples: "No audit logging mentioned" (NFR Gap) vs "Stores API keys in a ConfigMap" (Security Risk).

B.3: Check RHOAI Organizational Constraints

These are RHOAI/ODH-specific constraints that MUST be checked. Violations are High severity.

Output

Write your output to: artifacts/security-reviews/<STRAT-KEY>-reviewer-<N>.md

where <N> is your reviewer number from --reviewer.

Use this exact format:

---
strat_key: RHAISTRAT-NNN