The rule fires on the line,
while the pull request is still open.
Datadog Static Code Analysis runs security and quality rules on the code you wrote, in the editor, in CI or in Datadog's hosted scanner, and comments on the pull request with a fix attached. We choose the rules per repository, run them informational until the comments are trusted, and operate the rule set every month so it keeps up with the code.
Quick facts
Related
- Code Security, the group this belongs to
- Runtime Code Analysis, the same vulnerability classes confirmed from real traffic
- Secret Scanning, built on the same analyser, looking for keys
A second reviewer that reads every line, and only comments on what changed
A human reviewer reads the diff for intent. They do not reliably notice a SQL string built by concatenation on line 212, because they are reading for whether the feature works. Static Code Analysis reads the same diff for the pattern, every time, and leaves the comment on the line.
Security findings kept apart from quality. Security rules report to the Code Vulnerabilities tab. Best practice, error prone, performance and code style rules report to Code Quality. The team that owns security does not wade through linting to find the injection.
The comment where the developer already is. The JetBrains plugin and the VS Code and Cursor extension flag the violation while the file is being edited. The pull request gets an inline comment on the line, on GitHub, GitLab or Azure DevOps.
Only the violations the change introduced. Pull request scanning is incremental and diff-aware. A thirty-year-old file with two hundred existing findings does not block a one-line change to it.
A fix to accept, not a ticket to raise. Templated fixes for the simple cases, AI-suggested fixes for the involved ones, applied from the comment or opened as a pull request. Bits AI can assess whether a finding is a false positive before anyone argues about it.
Every ruleset on, code style gated, and a generated directory producing a thousand comments
How it bills. Static Code Analysis is part of Code Security and is billed per committer, per month, on its own or in a Code Security bundle. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. Datadog publishes the meters and rates. The lever is the repository list and the paths inside it. A monorepo with a vendored directory and a generated client library produces findings in code nobody maintains. The exclusions are set before the first scan, not after the first findings page.
The configuration traps. Every rule category enabled on every repository, so the pull request gets eleven code style comments and the one injection finding is the twelfth. The same rule set applied to a Go service and a Ruby monolith, when the applicable rules for each differ and the noise does not. PR Gates made blocking on quality rules, so a release is delayed by a naming convention. Hosted scanning and a CI job both enabled on one repository, so every commit is scanned twice and the two results arrive at different times. Exclusions added as inline comments across the codebase with no central record, so a year later nobody knows which rules are effectively off.
Field noteThe most common gap we see is that a previous static analysis tool is still installed and still ignored. The developers learned to scroll past its comments. The new tool inherits that habit unless its first fortnight of comments is noticeably better, which is why the rule set is narrowed before the developers ever see it.
Field noteThe pattern we keep finding is a generated or vendored directory that the default exclusions do not match. An OpenAPI client checked in under the source tree, a vendored SDK. It accounts for most of the findings in the repository and none of the risk, and it makes the findings count unusable as a measure of anything.
Field noteThe IDE plugin is the part most often left uninstalled. The pull request comment arrives after the developer has moved on to the next task. The same finding in the editor arrives while the line is still being typed, and is fixed without a conversation.
Field noteSecurity findings that survive longest are the ones in code that works. The injection pattern has been in production for four years without incident. The fix pull request is drafted, the risk is accepted verbally, and the finding stays open with no date to revisit it.
Exclusions first. Security rules second. Quality rules reported, never gated by us.
Static Code Analysis is delivered inside the Code Security Accelerator, four weeks, fixed scope. It needs no tracer and no Agent, so it can be the first capability enabled on an estate that has Datadog for observability and nothing yet for code.
- Agree the repository list and its owners. Which repositories, which languages, which team owns each. Generated, vendored and archived code is listed for exclusion before any scan runs.
- Choose hosted or CI scanning per repository. Hosted scanning where the pipeline should not change. A CI job where the scan must run on your runners. One per repository, recorded.
- Select the rules per repository. Security rules for the languages present. Quality rules only where the team asked for them. Organisation-wide defaults set once, then narrowed per repository where the codebase warrants it.
- Run informational for a fortnight. Pull request comments on, gates off. Every dismissed or disputed comment is read. The rules behind them are narrowed, scoped or disabled, and the reason is recorded.
- Install the plugins and set the gates. The JetBrains plugin and the VS Code extension rolled out to the teams in scope. PR Gates made blocking only for the security severities the team agreed, never for quality rules.
- Hand over, in writing. Repository list, scanner choice per repository, rules in force and excluded per repository, gate severities, inline exclusions found in the code, and the open security findings on the day we finished.
Access is admin on the Datadog organisation and the Datadog app on the source host with read access to the repositories and permission to comment on pull requests. We do not need write access to your code. Fix pull requests are opened for your developers to review.
A rule set that is never narrowed becomes a comment that is never read
A new service in a new language arrives with the default rules. A framework upgrade changes which patterns are safe. An exclusion added for a migration stays after the migration. Managed Observability is the monthly service that keeps the rule set matching the code, and the comments worth reading.
Every month, the dismissed comments are read. The rules that produced the most disputed findings are the first ones reviewed. A rule that is right in principle and wrong for this codebase is scoped, not left to train the developers to ignore it.
Coverage follows the repositories. New repositories are enabled with the rule set for their language and mapped to a team. Archived ones are removed from scanning and from the committer count.
Exclusions carry a date. Inline exclusions and disabled rules are listed, with the reason and the date they were accepted. The ones that have passed their date are reopened with the team that asked for them.
The open security finding gets a decision. A critical finding that has been open for a quarter is not left open. It is fixed, accepted in writing with a date, or escalated to the owner with the fix pull request attached.
We operate the stack. You own the product.
We are not a security company, and we do not review your code for you. We are a managed runtime operator. We run the static analysis inside your Datadog, tune it until its comments are trusted, and route what it finds to the team that owns the code with the evidence attached. We operate and evidence the runtime controls that support your compliance obligations. The coding standards, the review process and the merge decision stay yours.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Static Code Analysis, answered plainly
Which languages does Datadog Static Code Analysis support?
Datadog's rules cover Python, JavaScript, TypeScript, Java, C#, Go, Ruby, PHP, Kotlin, Swift, Elixir and Apex, plus Dockerfiles and YAML. Rule coverage differs by language, so a repository in one language can have far more applicable rules than a repository in another. Results from third-party static analysers can also be uploaded, so a language Datadog does not cover natively can still report into the same findings view.
How is Datadog Static Code Analysis billed?
Static Code Analysis is part of Code Security, billed per committer, per month, on its own or in a Code Security bundle. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. Datadog publishes the current meters and rates. We do not publish prices. We do decide, with you, which repositories are enabled and which paths are excluded, because generated code and vendored copies produce findings nobody will fix.
Should we run Datadog Static Code Analysis in CI or use hosted scanning?
One or the other per repository, never both. Hosted scanning needs no pipeline change and scans each commit to a connected repository, which suits teams with many repositories and varied CI setups. A CI job suits teams that want the scan to run inside their existing pipeline with its own secrets and runners. Running both scans every commit twice and produces two sets of results that disagree on timing. We choose per repository and record the choice.
Can Datadog Static Code Analysis fix what it finds?
For many findings, yes. Simple violations carry a deterministic, templated fix. More involved ones carry an AI-suggested fix. Either can be applied in the pull request comment, committed to the branch, or opened as a separate pull request from Datadog. The developer still reviews and merges. We do not apply fixes to your code ourselves, and a suggested fix is a proposal for your review, not a change we have made.
What does Critical Cloud do with Static Code Analysis every month?
Managed Observability reads the new security findings per repository, identifies the rules that produced the most dismissed or disputed comments and narrows them, confirms that new repositories are enabled and mapped to a team, checks that the gates agreed are still in force, expires rule exclusions that were accepted for a period, and reports what was found, fixed and routed. Quality findings are reported to the team but never gated by us.
- Datadog products: every product, and how we implement and run each one
- Code Security: the group, and how findings reach the developer
- Runtime Code Analysis: the same vulnerability classes, confirmed from traffic
- Code Security Accelerator: repositories, scanners, rules and gates, in four weeks
Comments the developers read. Gates the developers agreed to.
Tell us which languages your services are in and where code review is the only control. We will show you which rules would fire on last month's pull requests, and which of them would have been right.