Recheck Policy Reference

Overview

A Recheck Policy defines conditions that trigger re-evaluation of an exception. When conditions are met, the evaluation result recommends flagging the exception for review, requiring re-approval, revoking it, or blocking.

Enforcement status: recheck policies are a model and library service (RecheckEvaluationService in StellaOps.Policy.Exceptions) with no enforcement path in the product today. No route accepts a recheck policy, and no route, worker or gate evaluates one or applies its action; see Enforcement status. The expiry of an exception is enforced independently of recheck policies.

Policy Model

recheckPolicy:
  policyId: "policy-critical-cves"
  name: "Critical CVE Recheck"
  conditions:
    - type: EPSSAbove
      threshold: 0.5
      action: RequireReapproval
    - type: ReachGraphChange
      action: Block
    - type: KEVFlagged
      action: Block
    - type: ExpiryWithin
      threshold: 7  # days
      action: Warn
  defaultAction: Warn
  isActive: true

Condition Types

EPSSAbove

Triggers when EPSS score exceeds threshold.

Example:

- type: EPSSAbove
  threshold: 0.5
  action: RequireReapproval

CVSSAbove

Triggers when CVSS score exceeds threshold.

ReachGraphChange

Triggers when reachability graph changes (new paths discovered).

Use case: Exception was based on “unreachable” status; new analysis shows reachability.

UnknownsAbove

Triggers when unknown budget exceeds threshold.

KEVFlagged

Triggers when CVE is added to CISA KEV catalog.

Best practice: Always use Block action for KEV additions.

VEXStatusChange

Triggers when VEX status changes (e.g., NotAffected → Affected).

NewCVEInPackage

Triggers when new CVE is discovered in the same package.

ExpiryWithin

Triggers when exception nears expiry.

PackageVersionChange

Triggers when package version changes in artifact.

Actions

Each action below is the RecommendedAction that an evaluation result carries. No route applies it today (Enforcement status); the effects listed describe the intended contract.

Warn

Log warning but allow exception to remain active.

• Appears in audit log
• Visible in exception details
• Does not block deployment

RequireReapproval

Move exception back to “pending” status requiring re-approval.

• Notifies original approvers
• Exception inactive until re-approved
• Evidence may need updating

Revoke

Automatically revoke the exception.

• Exception becomes inactive immediately
• Audit log entry created
• Notification sent

Block

Recommend failing the build or deployment pipeline. No product gate applies this action; see Enforcement status.

• Requires manual intervention
• Most severe action

Environment Scoping

Conditions can be scoped to specific environments:

- type: EPSSAbove
  threshold: 0.3
  environmentScope:
    - prod
    - staging
  action: Block
- type: EPSSAbove
  threshold: 0.7
  environmentScope:
    - dev
  action: Warn

Evaluation Flow

The library service evaluates in this order when a caller invokes it. No host path invokes it today.

1. Scan triggered
2. Get active exceptions for artifact
3. For each exception with recheck policy:
   a. Evaluate each condition
   b. Check environment scope
   c. Record triggered conditions
4. Determine highest-priority action
5. Apply action (warn/reapproval/revoke/block)
6. Update exception with recheck result

Persistence

• Recheck policy definitions are stored in policy.recheck_policies with conditions as JSONB.
• Exceptions reference a policy through policy.exceptions.recheck_policy_id.
• The latest evaluation snapshot is stored in policy.exceptions.last_recheck_result and policy.exceptions.last_recheck_at.

Enforcement status

• No input route. The exception create and update requests (/api/policy/exceptions) carry no recheck policy. A recheck policy is stored only by code that sets ExceptionObject.RecheckPolicy directly.
• No evaluation. No route, worker, gate or CLI command evaluates a recheck policy. The exception recheck build gate (ExceptionRecheckGate), which the Policy Engine host never registered, was withdrawn on 2026-10-11 (SPRINT_20261007_028 CCP-073; frozen source in src/__Obsoleted/Policy/StellaOps.Policy.Engine/CCP-073/). There is no stellaops/exception-gate CI action.
• No stored result is read. last_recheck_result and last_recheck_at are written only when a caller supplies them, and no evaluation or release path reads them.

The protected operations of a release, approve and deployment dispatch, re-check Release Orchestrator’s signed, time-limited gate exception at each operation instead; a Policy exception object does not affect the release gate. Expiry of a Policy exception object is enforced by the exception lifecycle: see Exception Approval Workflow.

Best Practices

1. Start with Warn: Begin with warning actions, escalate based on data
2. KEV = Block: Always block on KEV additions
3. Environment Tiers: Stricter policies for production
4. Regular Review: Review triggered conditions monthly
5. Document Rationale: Explain threshold choices

Example Policies

High-Security Policy

recheckPolicy:
  policyId: "high-security"
  name: "High Security Recheck"
  conditions:
    - type: EPSSAbove
      threshold: 0.3
      action: Block
    - type: CVSSAbove
      threshold: 7.0
      action: RequireReapproval
    - type: KEVFlagged
      action: Block
    - type: ReachGraphChange
      action: Block
    - type: VEXStatusChange
      action: RequireReapproval
  defaultAction: Warn

Standard Policy

recheckPolicy:
  policyId: "standard"
  name: "Standard Recheck"
  conditions:
    - type: EPSSAbove
      threshold: 0.7
      action: RequireReapproval
    - type: KEVFlagged
      action: Block
    - type: ExpiryWithin
      threshold: 14
      action: Warn
  defaultAction: Warn

Related Documentation

• Evidence Hooks
• Exception API