Product security is of paramount importance at Datadog. Datadog uses a software development lifecycle in line with general Agile principles. When security effort is applied throughout the Agile release cycle, security oriented software defects are able to be discovered and addressed more rapidly than in longer release cycle development methodologies. Software patches are released as part of our continuous integration process. Patches that can impact end users will be applied as soon as possible but may necessitate end user notification and scheduling a service window.
Datadog performs continuous integration. In this way we are able to respond rapidly to both functional and security issues. Well defined change management policies and procedures determine when and how changes occur. This philosophy is central to DevOps security and the development methodologies that have driven Datadog adoption. In this way, Datadog is able to achieve extremely short mean time to resolution for security vulnerabilities and functional issues alike. Datadog is continuously improving our DevOps practice in an iterative fashion.
The Datadog production infrastructure is hosted in Cloud Service Provider (CSP) environments. Physical and environmental security related controls for Datadog production servers, which includes buildings, locks or keys used on doors, are managed by these CSP’s. “Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors.”
Datadog leverages internal services that require transport level security for network access and individually authenticate users by way of a central identity provider and leveraging two factor authentication wherever possible.
All Datadog personnel undergo regular security and privacy awareness training that weaves security into technical and non-technical roles; all employees are encouraged to participate in helping secure our customer data and company assets. Security training materials are developed for individual roles to ensure employees are equipped to handle the specific security oriented challenges of their roles.
Authentication and Access Management
End users may log in to Datadog using an Identity Provider, leveraging Datadog’s support for the Security Assertion Markup Language (SAML) or via the “Sign-in with Google” OpenID service. These services will authenticate an individual’s identity and may provide the option to share certain personally identifying information with Datadog, such as your name and email address to pre-populate our sign up form. Datadog’s SAML support allows organizations to control authentication to Datadog and enforce specific password policies, account recovery strategies and multi-factor authentication technologies.
All requests to the Datadog API must be authenticated. Requests that write data require at least reporting access as well as an API key. Requests that read data require full user access as well as an application key. These keys act as bearer tokens allowing access to Datadog service functionality.
Protection of Customer Data
Data submitted to the Datadog service by authorized users is considered confidential. This data is protected in transit across public networks and encrypted at rest. Customer Data is not authorized to exit the Datadog production service environment, except in limited circumstances such as in support of a customer request.
All data transmitted between Datadog and Datadog users is protected using Transport Layer Security (TLS) and HTTP Strict Transport Security (HSTS). If encrypted communication is interrupted the Datadog application is inaccessible.
Datadog maintains distinct data centers in the United States and the EU. Customer submitted service data is not transferred or shared between distinct data centers. Datadog utilizes encryption at various points to protect Customer Data and Datadog secrets, including encryption at rest (e.g. AES-256), asymmetric encryption (e.g. PGP) for system backups, KMS-based protections for the protection of secrets (passwords, access tokens, API keys, etc.), and GPG encryption.
Access to Customer Data is limited to functions with a business requirement to do so. Datadog has implemented multiple layers of access controls for administrative roles and privileges. Access to environments that contain Customer Data requires a series of authentication and authorization controls, including Multi-Factor Authentication (MFA). Datadog enforces the principles of least privilege and need-to-know for access to Customer Data, and access to those environments is monitored and logged for security purposes. Datadog has implemented controls to ensure the integrity and confidentiality of administrative credentials and access mechanisms, and enforces full-disk encryption and unique credentials for workstations.
Datadog monitors critical infrastructure for security related events by using a custom implementation of open source and commercial technologies. Activity data such as API calls and operating system level calls are logged to a central point where the information is passed through a series of custom rules designed to identify malicious or unapproved behavior. The results of these rules are fed into an orchestration platform that triggers automated actions, which may include directly alerting the security team or triggering additional authentication requirements.
Certifications, Attestations and Frameworks
Datadog maintains active SOC 2 Type II compliance, provides HIPAA-compliant log management and security monitoring, has achieved certification to the International Organization for Standardization’s information security standard 27001, as well as compliance with standards 27017 and 27018, and documents security controls on the Cloud Security Alliance’s (CSA) Security, Trust & Assurance Registry (STAR).
Datadog also maintains a FedRAMP Moderate Impact for products in the US1-FED site and FedRAMP Low-Impact Authority to Operate (ATO) for the Infrastructure Metrics product in the US1 site.
Laws and Regulations
Datadog’s solution is compliant with various data protection laws and regulations applicable to the services we provide.
Datadog is compliant with the General Data Protection Regulation (GDPR) which went into effect on May 25, 2018. Datadog has worked to enhance its products, processes, and procedures to meet its obligations as a data processor. For more information about our position on the GDPR, please visit https://www.datadoghq.com/gdpr/.
Datadog is a monitoring service for infrastructure and applications and while we do not intend to transfer, process, use, or store personal information, Datadog can provide our CCPA Addendum so that our customers can fulfill their obligations under the CCPA in the event that personal data is in scope. For more information about how the CCPA impacts Datadog and its customers, please visit https://www.datadoghq.com/ccpa/.
Datadog leverages a number of third party applications and services in support of the delivery of our products to our customers. The Datadog Security Team recognizes that the company’s information assets and vendor dependencies are critical to our continuing operations and delivery of services. As such, Datadog’s Security and Privacy teams have established a vendor management program that sets forth the requirements to be established and agreed upon when Datadog engages with third parties or external vendors. These engagements are designed to assess the technical, physical, and administrative controls in place and to ensure they are commensurate with the expectations of Datadog and its customers. For a complete list of Datadog’s subprocessors, please visit https://www.datadoghq.com/subprocessors/.
Safety and Security
To ensure a safe and trustworthy user experience, Datadog builds security into our platform through safe design and proactive monitoring.
Datadog automatically detects if one of your private is accidentally uploaded to a public GitHub repository. If a valid key is detected, you’ll immediately receive an email notification with .
How it works
Datadog proactively monitors your API and application keys as follows:
- We provide GitHub with regex patterns that could potentially match a Datadog API or application key.
- GitHub runs those regex patterns against commits and pushes to public repositories. If a match is found, GitHub automatically sends it to Datadog’s validation endpoint to be verified.
- If our validation endpoint determines that the candidate token is valid and active, we immediately take the following actions:
- Automatically notify you via email
- Display a banner in the Datadog UI on the API Keys and Application Keys pages within your Organization Settings
What is the impact of a leaked key?
A leaked API or application key can have the following consequences:
- API keys are used to submit data to Datadog. Exposure may result in unintended data being submitted to your organization.
- Application keys have the same permissions and capabilities as the key creator. Exposure results in a high risk of unauthorized access.
How will I be notified?
In the event of a key leak, Datadog immediately sends an email notification to the key creator/owner:
By default, the key creator/owner receives the email notification. If the key creator is no longer part of your organization, then the administrators of your org will be notified.
To notify additional contacts about a key leak, please contact Datadog support. Datadog recommends using a shared mailing list, such as a generic security contact, to receive notifications rather than a specific user.
Additionally, Datadog displays the following warning banner under Organization Settings to alert you to the active leaked key:
What should I do if I receive a leaked key notification?
If you receive a leaked key notification, as soon as possible to ensure the security of your account.
To protect your account from brute force and password-spraying attacks, Datadog restricts the use of unsafe passwords. Passwords that appear in third-party, non-Datadog data breaches are considered unsafe.
What restrictions apply?
If you try to register a new account using an unsafe password or change your current password to one, Datadog will display the following warning:
Existing accounts with unsafe passwords can continue to log in, but Datadog will alert users via a warning banner in the Personal Settings page:
What should I do if I see an unsafe password warning?
If you see an unsafe password warning, immediately to protect your account from being compromised.
How does Datadog determine that a password is unsafe?
Datadog maintains a database of hashed passwords obtained from third-party, non-Datadog data breaches. When you sign in, a hashed version of your password is checked against this list. This check follows guidelines established by the National Institute of Standards and Technology.
Many of Datadog’s products combine live data, rich Markdown text, and collaborative features that enable users to create meaningful content. As a proactive safety measure, Datadog protects you against potentially harmful links that may be found in user-generated content.
How will I know if a link is unsafe?
If you try to access a potentially unsafe link, Datadog displays a warning that shows the full URL and gives you the option of continuing to that site or returning to the previous page:
How does Datadog protect against potentially harmful links?
Datadog protects you from harmful links by following this protocol:
- Datadog monitors for clicks on external, user-defined links found in a dashboard, notebook, monitor, log, etc.
- When a user clicks an external link, the link is rewritten on the fly and checked against our URL Protection Endpoint to determine if it is potentially harmful.
- If the link is determined as potentially harmful, Datadog displays a warning with the option to either proceed to the destination or go back.
Datadog hosts its private Bug Bounty Program with HackerOne. If you’re an independent security expert or researcher and believe you’ve discovered a security-related issue on our platform, we appreciate you disclosing the issue to us responsibly and thank you for your time and expertise.
If you are eligible and want to participate in our private Bug Bounty Program, send us an email at [email protected] with your HackerOne username or the email you want an invitation for.
You will report the vulnerability directly in the HackerOne platform and all communication after submission will be conducted there. Before submitting an issue, please read our guidelines and scope of the program.
Datadog employees or contractors—current or former—are not eligible to participate in this program. Please read the complete eligibility requirements before joining the program.
The scope of the Bug Bounty Program includes Datadog’s products, services, and systems. Vulnerabilities found in vendor systems fall outside of this policy’s scope and should be reported directly to the vendor via their own disclosure programs.
The following describes what systems and types of research are covered under this program. Always be careful to verify whose assets you are testing while performing research.
- Corporate website: https://www.datadoghq.com
- Web Application: https://app.datadoghq.[com,eu]
- API: https://api.datadoghq.[com,eu]
- Datadog Mobile App: iOS, Android
- Agent and integrations code (only the latest versions are in-scope)
Rules of Engagement
The following is intended to give security researchers clear guidelines for conducting vulnerability discovery activities to limit the potential for company and/or customer data to be at risk:
- Do add a prefix
Bugbounty- to your Datadog org name.
- Do report a potential security issue immediately.
- Do NOT attack other users. If you are testing the ability to access another customer’s data, do not iterate randomly. Create another test account or ask for assistance at [email protected].com.
- Do NOT attempt Denial of Service (DoS) attacks. If you notice performance interruption or degradation, immediately suspend all testing.
- Do NOT perform any phishing, spamming, social engineering, or other form of fraud on our employees or customers.
- Do NOT perform any physical attacks against Datadog’s property (including workstations, office spaces, servers, or networks) or otherwise try to discover risk beyond digital means against Datadog.
- Do NOT exploit a security issue you discover for any reason other than to validate your finding.
- Do NOT deface any Datadog-associated publicly available resource for a proof of concept (PoC) which explicitly states the vulnerability. For example, for a subdomain takeover PoC, upload a file with
hello world in it.
Any of the following (or related) activities will be automatically considered out of scope for the Bug Bounty Program:
- Clickjacking or UI redressing (on pages with no sensitive actions)
- Content injection or “HTML injection” unless you can clearly show risk (other than social engineering)
- Cross-Site Request Forgery (CSRF) on features which are available to anonymous users
- Low-impact CSRF including, but not limited to, login, logout, and unauthenticated
- User session duration
- Username/email enumeration
- Same-site scripting and Self-XSS
- Self-exploitation (i.e., password reset links or cookie reuse)
- Missing flags on non-essential session cookies
- Missing security-related HTTP headers which do not lead directly to a vulnerability
- Open redirects on ad/analytics subdomains
- Presence of autocomplete attribute on web forms
- Reflected File Download (RFD) attacks
- Banner or version disclosure of server or software
- Information disclosure that has no practical use for exploitation
- Descriptive/verbose/unique error pages (without proof of exploitability)
- Default configuration files which do not disclose sensitive information
Denial of Service:
- Denial of Service (DoS) attacks
- Distributed Denial of Service (DDoS) attacks
End of Life (EoL)/ Outdated Software:
- Any Datadog-developed software that is EoL or no longer supported
- Client side bugs which do not affect (and/or are exploitable on) the latest version of modern browsers
- Outdated dependencies without a working PoC
- Man-in-the-middle (MITM) attacks or those requiring physical access to the victim’s device
- Physical or social engineering attacks
Security Best Practices:
- Missing SSL/TLS best practices
- Mixed content warnings
- Missing best practices in Content Security Policy
- Missing email security best practices (such as incomplete or missing SPF/DKIM/ DMARC) without a proof of exploitability
- Issues related to networking protocols or industry standards
- Bugs Datadog is already aware of (or ones previously submitted by another researcher)
- Pivoting, scanning, exploiting, or exfiltrating data from internal Datadog systems
- Pervasive issues or vulnerabilities such as heartbleed, meltdown, spectre, or others without a PoC
- Results of automated tools or scanners without a PoC
- Theoretical subdomain takeover claims with no supporting evidence
- Using unreported vulnerabilities to find other bugs
- Vulnerabilities in community-contributed API and DogStatsD client libraries
- Public zero-day vulnerabilities that have had an official patch for less than one month will be awarded on a case by case basis.
The Disclosure Policy of Datadog’s private Bug Bounty Program follows HackerOne’s private program disclosure policy and Datadog’s HackerOne program policy. This program is subject to strict confidentiality requirements. You will need consent from Datadog for any disclosure outside of the program. Prior to accepting an invitation to Datadog’s private program, you should carefully review the program policies and the non-disclosure agreements required for participation.