Setup and Configure
Compatibility
Supported Java versions
The Datadog library supports Java JRE 1.8 and higher of both Oracle JDK and OpenJDK, on the following architectures:
- Linux (GNU) x86, x86-64
- Alpine Linux (musl) x86, x86-64
- macOS (Darwin) x86, x86-64
- Windows (msvc) x86, x86-64
Datadog does not officially support any early-access versions of Java.
You can monitor application security for Java apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
Supported frameworks
Framework Web Server | Minimum Framework Version |
---|
Servlet Compatible | 2.3+, 3.0+ |
Spring | 3.1 |
Note: Many application servers are Servlet compatible and are supported by ASM, such as WebSphere, WebLogic, and JBoss. Also, frameworks like Spring Boot are supported by virtue of using a supported embedded application server (such as Tomcat, Jetty, or Netty).
Supported .NET versions
The following .NET versions are supported:
- .NET Core 6
- .NET Core 5
- .NET Framework 4.8
- .NET Framework 4.7.2
- .NET Framework 4.7
- .NET Framework 4.6.2
- .NET Framework 4.6.1
These are supported on the following architectures:
- Linux (GNU) x86, x86-64
- Alpine Linux (musl) x86, x86-64
- macOS (Darwin) x86, x86-64
- Windows (msvc) x86, x86-64
You can monitor application security for .NET apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
Supported frameworks
The .NET Tracer supports all .NET-based languages (for example, C#, F#, Visual Basic).
Framework Web Server | Minimum Framework Version |
---|
ASP.NET | 4.6 |
ASP.NET Core | 2.1 |
Supported Go versions
The Datadog Go tracing library supports Go version 1.14 and greater, on the following architectures:
- Linux (GNU) x86-64
- Alpine Linux (musl) x86-64
- macOS (Darwin) x86-64
You can monitor application security for Go apps running in Docker, Kubernetes, and AWS ECS.
Supported frameworks
Integrate the Go tracer with the following list of web frameworks using one of the corresponding APM tracer integration. Click to see the integrations documentation, which provides a detailed overview of the supported packages and their APIs, along with usage examples.
Enabling CGO
Compiling your code with ASM enabled involves CGO and therefore requires:
- The
gcc
compiler for the target GOOS
and GOARCH
. - The C library headers.
- The CGO bindings enabled. This is controlled by the
CGO_ENABLED
environment variable which is enabled by default when compiling natively.
To install the above requirements:
Operating system | Console command |
---|
Debian, Ubuntu | $ apt install gcc libc6-dev |
Alpine | $ apk add gcc musl-dev |
RHEL, CentOS, Fedora | $ yum install gcc glibc-devel |
macOS | $ xcode-select --install |
Note: The Go toolchain disables CGO when cross-compiling and so, CGO needs to be explicitly enabled.
Supported Ruby versions
The Datadog Ruby library supports the latest gem for the following Ruby interpreters:
These are supported on the following architectures:
- Linux (GNU) x86-64, aarch64
- Alpine Linux (musl) x86-64, aarch64
- macOS (Darwin) x86-64, arm64
You can monitor application security for Ruby apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
Supported frameworks
Framework Web Server | Minimum Framework Version |
---|
Rack | 1.1 |
Rails | 3.2 (also depends on Ruby version) |
Sinatra | 1.4 |
The Datadog PHP library supports PHP version 7.0 and above on the following architectures:
- Linux (GNU) x86-64
- Alpine Linux (musl) x86-64
You can monitor application security for PHP apps running in Docker, Kubernetes, and AWS ECS.
It supports the use of all PHP frameworks, and also the use no framework.
Supported Node.js versions
The Datadog Node.js library supports the following Node.js versions:
These are supported on the following architectures:
- Linux (GNU) x86-64
- Alpine Linux (musl) x86-64
- macOS (Darwin) x86-64
- Windows (msvc) x86, x86-64
You can monitor application security for Node.js apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
Supported frameworks
Framework Web Server | Minimum Framework Version |
---|
Express | 4.0 |
Supported Python versions
The Datadog Python library supports the following Python versions:
- Python 2.7, 3.5 and higher
These are supported on the following architectures:
- Linux (GNU) x86-64
- Alpine Linux (musl) x86-64
- macOS (Darwin) x86-64
- Windows (msvc) x86, x86-64
You can monitor application security for Python apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
Supported frameworks
Framework Web Server | Minimum Framework Version |
---|
Django | 1.8 |
Flask | 0.10 |
Support for query strings is not available for Flask.
ASM support for AWS Lambda is in beta. Threat detection is done by using the Datadog's lambda extension.
Don’t see your desired technology listed here? Datadog is continually adding additional support. Fill out
this short form to send us details.
Supported cloud environments
Version dependencies
- Lambda Extension version:
39
- Serverless plugin version:
5.20.0
Supported languages and their requirements
- Node
- If you are bundling using webpack or esbuild, mark the Datadog libraries as external.
- Python
- Java
- To fully instrument your serverless application with distributed tracing, your Java Lambda functions must use the Java 8 Corretto (
java8.al2
) or Java 11 (java11
) runtimes with at least 1024MB of memory. - If you use the Datadog Lambda layers
dd-trace-java:4
(or older) and Datadog-Extension:24
(or older), follow the instructions in Upgrade Instrumentation for Java Lambda Functions. - Go
- .NET
ASM capabilities
The following ASM capabilities are not supported for Lambda functions:
- ASM Risk Management
- IP, user, and suspicious request blocking
- 1-Click enabling ASM
ASM automatically attempts to resolve http.client_ip
from several well-known headers, such as X-Forwarded-For
. If you use a custom header for this field, or want to bypass the resolution algorithm, set the DD_TRACE_CLIENT_IP_HEADER
environment variable and the library only checks the specified header for the client IP.
Track authenticated bad actors
Many critical attacks are performed by authenticated users who can access your most sensitive endpoints. To identify bad actors that are generating suspicious security activity, add user information to traces by instrumenting your services with the standardized user tags. You can add custom tags to your root span, or use instrumentation functions. Read Tracking User Activity for more information.
Exclude specific parameters from triggering detections
There may be a time when an ASM signal, or a suspicious request, is a false positive. For example, ASM repeatedly detects
the same suspicious request and a signal is generated, but the signal has been reviewed and is not a threat.
You can add an entry to the passlist, which ignore events from a rule, to eliminate noisy signal patterns and focus on legitimately suspicious requests.
To add a passlist entry, do one of the following:
- Click on a signal in ASM Signals and click the Add Entry link next to the Add to passlist suggested action. This method automatically adds an entry for the targeted service.
- Navigate to Passlist Configuration and manually configure a new passlist entry based on your own criteria.
Note: Requests (traces) that match a passlist entry are not billed.
Data security considerations
The data that you collect with Datadog can contain sensitive information that you want to filter out, obfuscate, scrub, filter, modify, or just not collect. Additionally, it may contain synthetic traffic that might cause your threat detection be inaccurate, or cause Datadog to not accurately indicate the security of your services.
By default, ASM collects information from suspicious requests to help you understand why the request was flagged as suspicious. Before sending the data, ASM scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a <redacted>
flag, so you observe that although the request was suspicious, the request data could not be collected because of data security concerns.
To protect users’ data, sensitive data scanning is activated by default in ASM. You can customize the configuration by using the following environment variables. The scanning is based on the RE2 syntax, so to customize scanning, set the value of these environment variables to a valid RE2 pattern:
DD_APPSEC_OBFUSCATION_PARAMETER_KEY_REGEXP
- Pattern for scanning for keys whose values commonly contain sensitive data. If found, the values and any child nodes associated with the key are redacted.DD_APPSEC_OBFUSCATION_PARAMETER_VALUE_REGEXP
- Pattern for scanning for values that could indicate sensitive data. If found, the value and all its child nodes are redacted.
For Ruby only, starting in ddtrace
version 1.1.0You can also configure scanning patterns in code:
Datadog.configure do |c|
# ...
# Set custom RE2 regexes
c.appsec.obfuscator_key_regex = '...'
c.appsec.obfuscator_value_regex = '...'
end
The following are examples of data that are flagged as sensitive by default:
pwd
, password
, ipassword
, pass_phrase
secret
key
, api_key
, private_key
, public_key
token
consumer_id
, consumer_key
, consumer_secret
sign
, signed
, signature
bearer
authorization
BEGIN PRIVATE KEY
ssh-rsa
See APM Data Security for information about other mechanisms in the Datadog Agent and libraries that can also be used to remove sensitive data.
Disabling Application Security Management
To disable ASM, remove the DD_APPSEC_ENABLED=true
environment variable from your application configuration. Once it’s removed, restart your service.
If you need additional help, contact Datadog support.
Configure a custom blocking page or payload
The blocked requests feature JSON or HTML content. If the Accept
HTTP header is pointing to HTML, like text/html
, the HTML content is used. Otherwise, the JSON one is used.
Both sets of content is embedded in the Datadog Tracer library package and loaded locally. See examples of the templates for HTML and JSON in the Datadog Java tracer source code on GitHub.
The HTML and JSON content can both be changed using the DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML
and DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON
environment variables. Alternatively, you can use the dd.appsec.http.blocked.template.html
or dd.appsec.http.blocked.template.json
configuration entries.
By default, the page shown in response to a blocked action looks like this:
Further Reading
Additional helpful documentation, links, and articles: