Static Analysis

Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

Code Analysis is not available for the site.

Try the Beta!

Code Analysis is in public beta.

Overview

Static Analysis is a clear-box software testing technique that analyzes a program’s pre-production code without the need to execute the program, meaning that the program is static because it isn’t running. Static Analysis helps you identify maintainability issues and security vulnerabilities early in the Software Development Life Cycle (SDLC) to ensure only the highest quality, most secure code makes it to production. Static Analysis tools that scan for security vulnerabilities are also commonly referred to as Static Application Security Testing (SAST) tools.

Using Static Analysis provides organizations with the following benefits:

  • Static Analysis takes the guesswork out of adhering to an organization’s code standards, enabling your development team to ship compliant code without significant impacts to developer velocity.
  • An organization’s applications are less vulnerable to security breaches over time, due to new vulnerabilities being caught through SAST scans before code reaches production.
  • New developers to an organization are able to onboard faster because Static Analysis enables an organization to maintain a more readable codebase over time.
  • An organization’s software becomes reliable over time by virtue of the code being more maintainable because the risk of a developer introducing new defects to the code is minimized.

Languages

Static Analysis currently supports scanning the following languages and technologies for poor coding practices and security vulnerabilities:

  • C#
  • Dockerfiles
  • Go
  • Java
  • JavaScript
  • Python
  • Ruby
  • TypeScript

Integrations

CI providers

With Static Analysis, you can integrate feedback on code reviews for various languages in any CI platform provider of your choice. See the documentation for information about the following integrations:


Source code management

During code reviews, source code management (SCM) integrations check for Static Analysis violations in pull requests for repos that have at least one ruleset applied. Violations are flagged with a comment on the relevant line of code. Certain violations also include suggested changes that can be applied directly in the UI of the SCM tool.


IDEs

With Static Analysis, you can identify code vulnerabilities as you edit a file in your Integrated Development Environment (IDE). See the documentation for information about the following integrations:


Search and filter results

After you configure your CI pipelines to run the Datadog Static Analyzer, violations are summarized per repository on the Code Analysis Repositories page. Click on a repository to analyze Code Vulnerabilities and Code Quality results from Static Analysis.

To filter your results, use the facets to the left of the list, or search.

Every row represents a violation. Each violation is associated with the specific commit and branch that is selected in the filters at the top of the page (by default the latest commit on the default branch of the repository you are viewing).

Click on a violation to open a side panel that contains information about the scope of the violation and where it originated.

Side panel for a static analysis violation

The content of the violation is shown in tabs:

  • Details: A description of the violation and the lines of code that caused it. To see the offending code snippet, configure the Datadog GitHub App.
  • Fixes: One or more code fixes that can resolve the violation, which you can copy and paste.
  • Event: JSON metadata regarding the Static Analysis violation event.

Using suggested fixes

AI Suggested Fixes are in private beta. To request access, contact Support.
Fixes tab of a static analysis violation

In Datadog Static Analysis, there are two types of suggested fixes:

  1. Default Suggested Fix: For simple violations like linting issues, the rule analyzer automatically provides templated fixes.
  2. AI Suggested Fix: For complex violations, fixes are typically not available beforehand. Instead, you can use AI Suggested Fixes, which use OpenAI’s GPT-4 to generate a suggested fix. You can choose between “Text” and “Unified Diff” fixes, which outputs plain text instructions or a code change for resolving the violation, respectively.

The two types of fixes are distinguished visually in the UI with different labels.

Default Suggested Fixes:

Visual indicator of a default static analysis suggested fix

AI Suggested Fixes:

Visual indicator of an AI static analysis suggested fix

Ignoring violations

Ignore for a repository

Add an ignore rule in your static-analysis.datadog.yml file. The example below ignores the rule javascript-express/reduce-server-fingerprinting for all directories.

rulesets:
  - javascript-express:
    rules:
      reduce-server-fingerprinting:
        ignore: "**"

Ignore for a file or directory

Add an ignore rule in your static-analysis.datadog.yml file. The example below ignores the rule javascript-express/reduce-server-fingerprinting for this file. For more information on how to ignore by path, see Static Analysis Setup.

rulesets:
  - javascript-express:
    rules:
      reduce-server-fingerprinting:
        ignore: "ad-server/src/app.js"

Ignore for a specific instance

To ignore a specific instance of a violation, comment no-dd-sa above the line of code to ignore. This prevents that line from ever producing a violation. For example, in the following Python code snippet, the line foo = 1 would be ignored by Static Analysis scans.

#no-dd-sa
foo = 1
bar = 2

You can also use no-dd-sa to only ignore a particular rule rather than ignoring all rules. To do so, specify the name of the rule you wish to ignore in place of <rule-name> using this template:

no-dd-sa:<rule-name>

For example, in the following JavaScript code snippet, the line my_foo = 1 is analyzed by all rules except for the javascript-code-style/assignment-name rule, which tells the developer to use camelCase instead of snake_case.

// no-dd-sa:javascript-code-style/assignment-name
my_foo = 1
myBar = 2

Reporting false positives

If you believe a specific violation is a false positive, you can indicate false positives and tell us why you flagged it. Datadog reviews submissions to improve our rules over time.

Button for reporting a Static Analysis violation as a false positive

Further Reading