Scoped policy, risk acceptance, and download decisions

Policy scope

Severity rules are applied through priority and scope resolution; results and later reevaluations remain in history.

Risk acceptance

Exceptions are recorded with scope, reason, reference, and expiry; task and audit history remain durable.

Decision outcomes

Policy evaluation can produce PASS, WARN, BLOCK, or NOT_EVALUATED when required context is absent. Whether consumed during scanning, proxy resolution, or CI/CD, the result must remain traceable to policy revision, scope, and evaluation identity.

• Organization, project, and repository scope plus rule priority selecting the expected policy
• Separate testing of severity threshold boundaries for PASS, WARN, and BLOCK results
• Policy changes producing reevaluation without deleting historical results
• Firewall or CLI results reconciling with the durable policy-evaluation record

Firewall format scope

The nine source-verified formats for proxy download decisions are Maven, npm, PyPI, NuGet, Go, Cargo, RubyGems, APT, and YUM/DNF. Other Artifact Management formats do not automatically imply firewall support; the matcher marks unsupported formats as NOT_EVALUATED.

Risk-acceptance lifecycle

Risk acceptance is not an unbounded bypass. Target finding or scope, rationale, reference, expiry, and creating actor are recorded, and creation starts reevaluation. After expiry or revocation, applicable policy must apply again while history remains preserved.

Analysis boundary

Within verified scope, decision inputs are OSV vulnerability data and severity or policy rules. Do not interpret results as malware, license, namespace-confusion, or quarantine decisions. The organization must separately define approval, duration, and review policy for WARN and risk acceptance.