DeepSource allows teams to configure how the analysis behaves primarily based on the issue's category. Admins can define which category of issues are reported and the presence of which category of issues marks an analysis run as failed. This categorization is too broad at times and doesn't give the user a middle path — "What if I want to block on all security issues except a few?". To understand this problem deeper, take the example of security issues raised by DeepSource — although this is valid for all issue categories. Security issues fall under one of these two categories: Universally valid issues. For instance, look at GSC-G301 (Poor file permissions used when creating a directory). In most cases, unless you are deliberately doing this, it is recommended that you follow the Principle of least privilege . Most developers would agree with this finding and either fix it or manually suppress it with skipcq . Contextually valid issues. Take GO-S0904 (Audit the possible insecure usage of logger). This broad issue optimizes for low false negatives rather than low false positives. In cases like these, it's better to show developers low-confidence issues lest they miss something vulnerable. Most teams configure DeepSource to fail analysis when a security issue is found, which works for universally valid issues. Contextually valid issues, however, can be too noisy. This can be extended to other categories as well. There's a need for a user-defined dimension to control how issues impact the analysis result, one that allows the users to easily program their coding conventions or preference in DeepSource's analysis.
