admin: Clarify securty policy on what is not a vulnerability (#2128)

Signed-off-by: Larry Gritz <lg@larrygritz.com>

SECURITY.md

@@ -30,6 +30,27 @@ address critical security vulnerabilities rapidly and post patches as quickly
 as possible.
 
 
+## What do we consider a vulnerability?
+
+We only consider a situation to be a security vulnerability if an untrusted
+party can plausibly trigger the flaw through normal product inputs (for
+example, a maliciously crafted oso file that might compromise a renderer when
+loaded). We do not support requesting a CVE for API-only or caller-controlled
+failures with no realistic adversarial path.
+
+The OSL project adopts the same security stance as many other language
+compilers: we believe that shaders that will be JITed and executed are by
+definition *trusted inputs*, and should not be accepted from untrusted
+sources.  A shader that causes damage when it faithfully executes is not a
+vulnerability per se.  In rare circumstances, we might consider it a
+vulnerability if a maliciously crafted shader can cause the renderer or OSL
+library to do something damaging that is different from what the shader text
+implies.
+
+Flaws whose root cause lies in a dependency should be reported and fixed
+upstream; the upstream project owns the CVE when one is warranted.
+
+
 ## Other security features
 
 ### Signed tags
@@ -50,3 +71,4 @@ None known
 
 ## History of CVE Fixes
 
+None to date