Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      WHY

      In this LTS we want to show that we understand the need for Auditors to be able to manage auditing the large volume of hotspot issues produced by analysis. As a first step, we'd like to better equip auditors to talk to developers about security and their code.

      We've added reports for OWASP Top 10 and SANS Top 25, which are an affirmative way to understand what was not found in the code, as well as to see what was. After living with these reports for a few months we better understand the context and usage of these reports, and need to make a few changes.

      Additionally, while developers don't necessarily know "OWASP", "SANS", or "CWE", that doesn't mean they're entirely ignorant of security concepts. In fact, it's quite likely that they've heard terms such as "cross-site scripting", "SQL injection", and so on. Yet those terms aren't used in SonarQube, which should reflect the developer's world.

      WHAT

      Only Auditors need reports

      Security reports are targeting users who needs to report compliance vs well known standards at a high level, which we expect to be present starting only in the large companies that are typically EE customers. So we will remove Security Reports (the menu item and the reports themselves) from CE and DE.

      Developer-friendly security language

      Let's expose the security terms developers are familiar with in the issues page in a new "SonarSource" subgroup in the standards facet, which we'll rename to Security Category, since that's all it holds.

      Auditors talk to developers

      As a security auditor, I need the reports I'm already familiar with in SonarQube translated into the SonarQube Security categories my developers understand, so that I can see what was found, what was not found, and be equipped to discuss the findings with the folks who might need to take action on them. So I need a new report showing reports in the categories the developers are used to. The entry for this new report should be first in the list.

      Rules search

      While we're at it, we'll also add a Security Category facet to the rules page. Currently the security reports alert you that there are additional rules you could enable, but we make it quite difficult to find them since you can't search rules by the categories in the Security Reports and on the Issues page.

      How

      The mapping between the categories and CWEs will be hardcoded in SonarQube. This cannot be modified by analysers.

      New categories will be added to issues' & rules' 'standards' facets and will automatically opened for security hotpsots & vulnerabilities. This facet will also go up higher in the list. The name of the 'standards' facets will change.

      The category will be added to the issues' tags.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ann.campbell.2 Ann Campbell
                Reporter:
                alexandre.gigleux Alexandre Gigleux
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: