rfc:security-classification
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
rfc:security-classification [2016/11/11 12:36] – krakjoe | rfc:security-classification [2016/11/11 12:51] – krakjoe | ||
---|---|---|---|
Line 8: | Line 8: | ||
At the end of last month, Stas posted to internals with some ideas to reform security issue [[http:// | At the end of last month, Stas posted to internals with some ideas to reform security issue [[http:// | ||
- | Current any issue that is in theory exploitable with security implications, must be treated as a security issue, even if the exploit requires nonsensical settings for a production environment, | + | Current any issue that is in theory exploitable with security implications must be treated as a security issue, even if the exploit requires nonsensical settings for a production environment, |
In short, all the security issues can be split into three groups with high, medium and low severity. The essential idea of such classification definitions is to allow different handling depending on the issue severity. In practice, the majority of security issues are purely theoretical, | In short, all the security issues can be split into three groups with high, medium and low severity. The essential idea of such classification definitions is to allow different handling depending on the issue severity. In practice, the majority of security issues are purely theoretical, |
rfc/security-classification.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1