DeepSource allows teams to configure how the analysis behaves primarily based on the issue's category ⎯ viz. security, performance, style, anti-pattern, bug-risk, or security. Team 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?"

Research

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.

From multiple conversations with prospective and existing customers, and from interviews with the internal team, we felt that 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.

Solutions

We proposed the introduction of a new user-defined property ⎯ called Priority, for issues. Users should be able to assign a priority to an issue and define analysis configuration based on the priority in addition to the issue's category.

This gives users more granular control on how they want the analysis to behave based on their contextual definition of what's important for them.

User stories

As a DeepSource user, I should be able to :

• Assign a priority tag to an issue ⎯ In the Repository settings, account settings, and Enterprise Control Panel (under Policies), we would create a new Issue Priority section. In this view, users should select an issue that DeepSource detects (say, PYL-W1401) and assign a priority tag to it. The list of priority tags is system-defined : High, Medium, Low, and No priority (default).

A priority can be added to an issue on any of the three levels defined above and is propagated downward (installation being the highest and repository being the lowest). Let's take the example of the issue BAN-B315 ⎯ “Use of an insecure expatreader method” : - A user of DeepSource Enterprise can add the priority High to the issue from the Enterprise Control Panel, upon which this priority is shown on all issues in all accounts and repositories in the installation. We defined a new section called Issue priority under Policies to enable this.

    ![image.png](<https://prod-files-secure.s3.us-west-2.amazonaws.com/acaef6d6-6235-4014-a5cc-350a1535ee62/91ccb5dc-d0d1-4831-96eb-b4aa779a1b5f/image.png>)
    

- Then, the user can add the priority `Medium` to the issue from the account-level Issue Priority. So the issue in all repositories in the account will now have Medium priority.
- Further, the user can mark `No priority` to the issue in the repository-level Issue
Priority view. By default, none of the issues have a priority, so the No priority
tag is a proxy for no tag. We require an explicit tag to enable users to remove the
priority at a lower level of definition for an issue to prevent conflicts from cascading rules.
    
    <aside>
    🎊
    
    It is worth noting that the priority tag is entirely different from the weight attribute or severity tag of an issue, which are system-defined attributes used for the implicit ordering of issues in the dashboard.
    
    </aside>

• Assign priority from the Issue Details page ⎯ In the issue's detail page that's linked to the Issues tab, add an option to assign a priority to the issue on the repository level. This option should only be available to the team admins.