Dashboard docs (#433)

* draft and images

* fix all broken links update screenshots

* Update docs/semgrep-app/dashboard.md

Co-authored-by: raghavjain3 <32291067+raghavjain3@users.noreply.github.com>

* updated to open findings

Co-authored-by: raghavjain3 <32291067+raghavjain3@users.noreply.github.com>

docs/semgrep-app/dashboard.md

@@ -0,0 +1,124 @@
+---
+slug: dashboard 
+append_help_link: true
+title: Dashboard 
+description: "The Dashboard is a summary view within Semgrep App to help security teams evaluate their organization's security posture."
+---
+
+import MoreHelp from "/src/components/MoreHelp"
+
+# Evaluating your security posture through the Dashboard
+
+![Screenshot of dashboard view](../img/dashboard-view.png)
+
+The Findings Dashboard is an overview of your organization’s security posture from data aggregated within Semgrep App. With these metrics you are able to:
+
+* View recurring security issues, consequently taking action on them.
+* Improve communication between developer teams and security teams.
+* Detect vulnerabilities early, thereby preventing these from persisting through to the next stage of product delivery, such as QA.
+
+You can access the Dashboard by [logging into Semgrep App](https://semgrep.dev/login?return_path=/manage/projects).
+
+## Assessing security readiness at a glance
+
+![Screenshot of dashboard header](../img/dashboard-header.png)
+
+The **Header widget** displays high-level security analytics across your entire organization. This includes:
+<dl>
+	<dt>Open findings</dt>
+	<dd>The number of open findings over the **given time period** next to the calendar icon. The badge number indicates whether this number has gone up or down compared to the previous timeframe. The number badge compares the most recent number of open findings against the previous timeframe.</dd>
+	<dt>High severity</dt>
+	<dd><a href='../findings/#understanding-the-findings-data'>High severity findings</a> are findings generated by a rule with the severity value set to <code>ERROR</code>. These include security backdoors, highly vulnerable code, and so on. The number badge compares the number of high severity findings within the given time period against the previous time period.</dd>
+	<dt>Pull request (PR) fix rate</dt>
+	<dd>The percentage of findings that were fixed when findings were surfaced to developers via PR comments in previous scans. The number badge compares PR fix rate in the given time period against the previous time period.</dd>
+</dl>
+
+## Filtering through findings over time
+
+The Dashboard displays data from scans for the **last one month** by default. This time range can be set to a broader or narrower value. By broadening the time range, security teams are able to see total numbers and statistics across an entire time period. Narrow time ranges can give insights into the most recent vulnerabilities creeping into the project.
+
+To change the time range of scan data over time:
+
+1. Click the **Last 1 month** button.
+2. Select a time range from the drop-down box. The Dashboard, including all widgets, reloads to reflect data from the selected time period.
+
+## Summarizing a project’s security posture
+
+![Screenshot of dashboard projects](../img/dashboard-project.png)
+
+The **Projects widget** displays open findings, high severities, and PR fix rates per-project. Through this view you are able to see which projects have the amount number of findings. The columns are arranged in a descending order, from the project with the greatest amount of findings to the least.
+
+To view the project’s findings, click on the project’s name. This takes you to the [Findings page](../findings), where you can filter, sort, and triage findings.
+
+## Discovering trends in vulnerabilities through OWASP categories
+
+![Screenshot of dashboard categories](../img/dashboard-categories.png)
+
+Trends in insecure code can emerge after multiple Semgrep scans over time. By identifying these patterns, security teams are better informed about specific areas for improvement. Semgrep enables security teams to see the breakdown of vulnerabilities detected through the **Categories widget**, which includes:
+
+<dl>
+	<dt>Code injection</dt>
+	<dd>Refers to poor handling of untrusted data (data from user inputs, integrations, and the like) that leads to malicious actors injecting their own code into the application. Semgrep Registry provides <a href="https://semgrep.dev/p/sql-injection">a ruleset guarding against SQL injection</a> for a variety of languages.</dd>
+	<dt>Cookie flag</dt>
+	<dd>Indicates issues with session management, specifically the misuse or underuse of cookie attributes such as <code>secure</code>, <code>HttpOnly</code>, <code>SameSite</code>, to prevent cookie theft and other cookie-related attacks. The Semgrep rule <a href="https://semgrep.dev/playground?registry=go.gorilla.security.audit.session-cookie-missing-httponly.session-cookie-missing-httponly">"Session Cookie Missing HttpOnly"</a> is an example written for Golang.</dd>
+	<dt>Cross-site request forgery (CSRF)</dt>
+	<dd>This category tracks patterns in code that may result in CSRF attacks. CSRF attacks occur when an attacker induces users to perform unintentional actions. These issues can be detected based on a codebase’s framework, such as Django. In the rule, <a href="https://semgrep.dev/playground?registry=python.django.security.audit.csrf-exempt.no-csrf-exempt">"No CSRF Exempt"</a>, Semgrep detects when a Django route does not have a CSRF token, the lack of which could lead to an attack.</dd>
+	<dt>Active debug code</dt>
+	<dd>A type of vulnerability stemming from debug code such as <code>alert</code> that may unintentionally telegraph sensitive application behavior or secrets. The Semgrep rule <a href="https://semgrep.dev/playground?registry=javascript.lang.best-practice.leftover_debugging.javascript-alert">"Leftover debugging"</a> is an example in Javascript.</dd>
+	<dt>Cryptography</dt>
+	<dd>Refers to the use of weak hashing algorithms and the like, such as the use of MD5 in tokens or secrets. This <a href="https://semgrep.dev/playground?registry=python.cryptography.security.insecure-cipher-algorithms.insecure-cipher-algorithm-blowfish">Blowfish detection rule for Python</a> provides a guardrail against easily decipherable ciphers.</dd>
+	<dt>Deserialization</dt>
+	<dd>Insecure deserialization occurs when an attacker is able to insert their own code, typically their own objects, as a website or app deserializes from flatter formats such as JSON. The rule <a href="https://semgrep.dev/playground?registry=python.flask.security.insecure-deserialization.insecure-deserialization">"Insecure deserialization"</a> for Flask detects the use of insecure libraries and advises the developer to use something more secure.</dd>
+	<dt>Path traversal</dt>
+	<dd>Path traversal occurs when malicious actors attempt to access files and directories outside of the web root folder. This is also known as directory traversal. In this <a href="https://semgrep.dev/playground?registry=java.jax-rs.security.jax-rs-path-traversal.jax-rs-path-traversal">Java example</a>, Semgrep detects potential path traversals through the insertion of <code>../</code>.</dd>
+	<dt>Regex</dt>
+	<dd>Various issues with regex patterns fall under this category. This includes overly permissive regex, custom regex patterns for common use-cases (which can be refactored as validated patterns from authorities such as OWASP), and <a href="https://semgrep.dev/playground?registry=javascript.lang.security.audit.detect-non-literal-regexp.detect-non-literal-regexp">patterns that may result in ReDoS</a>.</dd>
+	<dt>Open redirect</dt>
+	<dd>Open redirects happen when user input is incorporated into a redirection target. Malicious actors can then construct a lengthy URL pointing away from the expected domain, though it appears authentic in the beginning of the URL string. This exploit is used in phishing by sending a user an email with a link that appears genuine but steers them away from the trusted domain. In this <a href="https://semgrep.dev/playground?registry=python.flask.security.open-redirect.open-redirect">Flask example</a>, data directly from the request is passed to the redirect function, which could be exploited.</dd>
+	<dt>Command injection</dt>
+	<dd>Command injection occurs when an attacker uses some type of input to run <strong>system commands</strong> on the host operating system. This is also known as shell injection. In <a href="https://semgrep.dev/playground?registry=go.lang.security.audit.dangerous-syscall-exec.dangerous-syscall-exec">"Audit dangerous syscall"</a>, written for Golang, a finding is detected for non-static input to <code>syscall</code>, which if reached by user data, makes it vulnerable to exploitation.</dd>
+</dl>
+
+The color indicator next to the category name tells you in what state your organization’s projects are for each category.
+
+| Color | Meaning |
+| ------ | --------- |
+| Green | There are less impactful vulnerabilities detected in this category relative to other categories. |
+| Orange | There are some impactful vulnerabilities detected for this category relative to other categories. |
+| Red | There are plenty of impactful vulnerabilities for this category relative to other categories. Take action to reduce them by fixing the issues or identifying false positives. |
+
+## Assessing rule performance
+
+![Screenshot of dashboard rules widget](../img/dashboard-rules.png)
+
+The **Rules widget** provides a summary report for rule metrics, such as what rules are ignored or fired the most.
+
+These data points can serve as a starting point for the following security audits:
+
+- Investigating the relevance or quality of a rule — is it useful, or does it detect too many false positives?
+- Are there underlying issues in the codebase that result in recurring patterns of insecure code?
+- Are there rules that developers don’t resolve? Semgrep helps identify these, which helps to form insights into possible causes.
+
+### Rule performance through Developer Feedback
+
+![Screenshot of developer feedback](../img/dashboard-devfeedback.png)
+
+In Team/Enterprise Dashboards, these additional metrics are visible:
+
+* Most disliked
+* Slowest
+
+The **Most disliked** metric is taken from the **Developer Feedback** feature. Developers are able to provide feedback on findings that are not the most accurate. This feature is available for Team/Enterprise users.
+
+![Screenshot of developer feedback end flow](../img/dashboard-devfeedback2.png)
+
+## See also
+
+* [Semgrep Registry](https://semgrep.dev/r)
+* [Findings](../findings)
+
+## Additional references
+
+* [OWASP Cheat Sheet Series](https://github.com/OWASP/CheatSheetSeries)
+
+<MoreHelp />

sidebars.js

@@ -65,7 +65,7 @@ module.exports = {
     {
       type: 'category',
       label: 'Semgrep App',
-      items: ['semgrep-app/rule-board', 'semgrep-app/managing-policy', 'semgrep-app/findings', 'semgrep-app/integrations', 'semgrep-app/editor', 'semgrep-app/notifications', 'semgrep-app/sso', 'semgrep-app/rbac', 'semgrep-app/pricing-and-billing'],
+      items: ['semgrep-app/dashboard', 'semgrep-app/rule-board', 'semgrep-app/managing-policy', 'semgrep-app/findings', 'semgrep-app/integrations', 'semgrep-app/editor', 'semgrep-app/notifications', 'semgrep-app/sso', 'semgrep-app/rbac', 'semgrep-app/pricing-and-billing'],
     },
     'playground',
     {