## Problem to Solve As part of program reviews, finding the low hanging fruit that can address the most problems is important. For example, many customers are interested in developing training programs in cases where there is a common CWE across their suite of projects. For example, if XSS vulnerabilities are common across many projects, appSec may schedule a workshop or kick off a focused training session for development to help avoid these in the future. While this is out of scope for now, there may also be a use case of showing top CVEs can help appSec reduce the most risk quickly, since in some cases (there is some nuance to how easy a 'library upgrade' is) they will be able to ask developers to upgrade one library or a couple libraries across manifest files. This chart tells them 'whats the most efficient way to make meaningful change' #### What is required? 1. The scope will be group, as all these graphs, since the 'Organization Object' is not available (and neither are Business Context filters) 2. Calculation: Show the number of open instances of a vulnerability of a given identifier. within a given project or group. An instance of a CWE is the number of times a unique and open vulnerability is detected by SAST or advanced SAST. The x axis should be sorted by most common occurences, with the left-most bar being the most frequent and descending to the right. 3. The group should support the ability to group by CWE identifier or Compliance Standard (OWASP 2017, 2021 identifiers). 4. Dynamic X axis - the default view is a histogram of CWE identifier (IE CWE-89: SQL Injections) if grouped by CWE, but if grouped by a selected compliance standard, then the x axis should be those elements of the compliance standard (for example, top 10 most occurences of vulns by OWASP Top 10 rule, or DISA STIG rule, etc.) 5. This is a view of the current state of the customer, not a trendline over time. 6. Only project / business unit / severity filters should be available for this graph. Time and scanner are not relevant. 1. Note _panel_ level filter for severity should be implemented here. 7. Click throughs: User should be able to click into the vulnerability report with a filter on identifier (plus any filters set on the page/panel level) by clicking on the popover for a given CWE. This means they can only click into a single CWE at a time. 8. Use cases addressed 1. What are the biggest bang-for-my-buck focus areas? 2. What are my biggest compliance gaps **Out of Scope for First Release** 1. Once available, Security context key/value pair (fka business context/unit) groupings should be available for this graph once the feature is available. It is not expected to be available when this feature is first developed. 2. In the future, this chart could group the x-axis by CWEs that fit an OWASP standard OR by CVEs (from dependency/container scanning) - if we can make the query dynamic and capture this requirement as part of the first MVC that would be ideal. this can be discussed with engineering. 1. We could also consider just representing which CWEs meet a compliance standard in the UI. Otherwise, they could use the grouping on the vulnerability report. ### Unknowns * We have a field `identifier_names` on ES for a vulnerabilities. It's simply a text field with all identifiers concatenated, but indexed in a couple ways: by keyword, ngram, and original. Is this enough to be able to query for the top 10 CWEs and then get the counts per severity? My intuition would be that we need some work at least on the ES index. Or perhaps we need to sync the actual identifiers with their type. I think we need to consult Security Infrastructure on this. I'll add this last one to the description as an unknown. ### Feature flag usage Use new feature flag for this chart and to guard the GraphQL query: `new_security_dashboard_top_cwes`