Overview

Static Analysis (SAST) 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.

Set up Static Analysis

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

Integrate Static Analysis in your developer environment

CI providers

Source code management

IDEs

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.

• The Code Vulnerabilities tab contains the violations found by Datadog’s rules in the Security category.
• The Code Quality tab contains the violations found by Datadog’s rules in the Best Practices, Code Style, Error Prone, or Performance categories.

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.

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

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:

AI Suggested Fixes:

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.

Further Reading

Additional helpful documentation, links, and articles:

Monitor all your CI pipelines with DatadogBLOG Learn about the Source Code IntegrationDOCUMENTATION