Skip to main content
  • Semgrep Cloud Platform
  • Community Tier
  • Team & Enterprise Tier

Evaluating your security posture through the Dashboard

Screenshot of dashboard view

The Findings Dashboard is an overview of your organization’s security posture from data aggregated within Semgrep Cloud Platform. With these metrics you can:

  • 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 Cloud Platform.

Assessing security readiness at a glance​

Screenshot of dashboard header

The Header widget displays high-level security analytics across your entire organization. This includes:

Open findings
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.
High severity
High severity findings are findings generated by a rule with the severity value set to ERROR. 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.
Pull request (PR) fix rate
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.

Filtering findings by 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.

Filtering findings by projects​

The Dashboard displays data from scans for all of the organization's projects by default. Select one or a few projects to filter the dashboard widgets to only reflect scans from selected projects. Selecting a few projects gives you a more targeted view of those projects' security posture.

To change the projects filter:

  1. Click the All projects button.
  2. Select the project(s) from the drop-down box. The Dashboard, including all widgets, reloads to reflect data from the selected project(s).

Summarizing a project’s security posture​

Screenshot of dashboard projects

The Projects widget displays open findings, high severities, and PR fix rates per-project. Through this view you can 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, where you can filter, sort, and triage findings.

Screenshot of dashboard categories

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:

Code injection
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 ruleset guarding against SQL injection for a variety of languages.
Cookie flag
Indicates issues with session management, specifically the misuse or underuse of cookie attributes such as secure, HttpOnly, SameSite, to prevent cookie theft and other cookie-related attacks. The Semgrep rule "Session Cookie Missing HttpOnly" is an example written for Go language.
Cross-site request forgery (CSRF)
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, "No CSRF Exempt", Semgrep detects when a Django route does not have a CSRF token, the lack of which could lead to an attack.
Active debug code
A type of vulnerability stemming from debug code such as alert that may unintentionally telegraph sensitive application behavior or secrets. The Semgrep rule "Leftover debugging" is a JavaScript example.
Cryptography
Refers to the use of weak hashing algorithms and the like, such as the use of MD5 in tokens or secrets. This Blowfish detection rule for Python provides a guardrail against easily decipherable ciphers.
Deserialization
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 "Insecure deserialization" for Flask detects the use of insecure libraries and advises the developer to use something more secure.
Path traversal
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 Java example, Semgrep detects potential path traversals through the insertion of ../.
Regex
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 patterns that may result in ReDoS.
Open redirect
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 Flask example, data directly from the request is passed to the redirect function, which could be exploited.
Command injection
Command injection occurs when an attacker uses some type of input to run system commands on the host operating system. This is also known as shell injection. In "Audit dangerous syscall", written for Go programming language, a finding is detected for non-static input to syscall, which if reached by user data, makes it vulnerable to exploitation.

Assessing rule performance​

Screenshot of dashboard rules widget

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.

See also​

Additional references​

Find what you needed in this doc? Join the Semgrep Community Slack group to ask the maintainers and the community if you need help.