diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml index 29e8782cab1..5fb4a579ef6 100644 --- a/config/_default/menus/main.en.yaml +++ b/config/_default/menus/main.en.yaml @@ -2092,7 +2092,7 @@ menu: parent: platform_heading identifier: internal_developer_portal weight: 110000 - - name: Catalog + - name: Catalog url: internal_developer_portal/catalog/ parent: internal_developer_portal identifier: catalog @@ -4540,7 +4540,7 @@ menu: parent: tracing identifier: tracing_services weight: 9 - - name: Catalog + - name: Catalog url: /internal_developer_portal/catalog/ parent: tracing_services identifier: tracing_software_catalog @@ -8103,11 +8103,36 @@ menu: parent: application_security identifier: aws_waf_int weight: 8 - - name: API Security Inventory - url: security/application_security/api-inventory/ + - name: API Posture + url: security/application_security/api_posture/ parent: application_security - identifier: asm_api_security + identifier: application_security_api_security weight: 9 + - name: API Inventory + url: security/application_security/api_posture/api_inventory/ + parent: application_security_api_security + identifier: asm_api_security + weight: 1 + - name: API Endpoints + url: security/application_security/api_posture/api_inventory/api_endpoints/ + parent: asm_api_security + identifier: asm_api_security_api_endpoints + weight: 10000 + - name: Services + url: security/application_security/api_posture/api_inventory/services/ + parent: asm_api_security + identifier: asm_api_security_services + weight: 10001 + - name: API Findings + url: security/application_security/api_posture/api_findings/ + parent: application_security_api_security + identifier: application_security_api_findings + weight: 2 + - name: Endpoint Scanning + url: security/application_security/api_posture/endpoint_scanning/ + parent: application_security_api_security + identifier: application_security_endpoint_scanning + weight: 3 - name: Guides url: security/application_security/guide/ parent: application_security diff --git a/content/en/security/application_security/_index.md b/content/en/security/application_security/_index.md index 37da44bf845..20388984477 100644 --- a/content/en/security/application_security/_index.md +++ b/content/en/security/application_security/_index.md @@ -65,6 +65,7 @@ Whether you're defending public-facing APIs, internal services, or user-facing a * Identify unprotected, undocumented, or overly permissive endpoints. * Get detailed, contextual findings tied to specific endpoints, misconfigurations, and observed behavior. * Evaluate API configurations against posture rules based on security best practices and compliance frameworks (e.g., OWASP API Top 10). +* Actively verify endpoint reachability and authentication with [Endpoint Scanning][17]. ### Runtime threat detection and protection @@ -137,4 +138,4 @@ For information on disabling AAP or its features, see the following: [14]: /security/application_security/exploit-prevention/ [15]: /security/application_security/waf-integration/ [16]: /security/application_security/setup/ - +[17]: /security/application_security/api_posture/endpoint_scanning/ diff --git a/content/en/security/application_security/api_posture/_index.md b/content/en/security/application_security/api_posture/_index.md new file mode 100644 index 00000000000..dffb26c6d56 --- /dev/null +++ b/content/en/security/application_security/api_posture/_index.md @@ -0,0 +1,19 @@ +--- +title: API Posture +description: Discover API endpoints, assess endpoint risk, and verify endpoint behavior with API Posture in App and API Protection. +--- + +API Posture in Datadog [App and API Protection][1] (AAP) helps you discover API endpoints, understand the risk they expose, and verify how they behave. + +API Posture includes: + +- **API Inventory**: A catalog of the API endpoints and services in your environment. +- **API Findings**: Security findings, weaknesses, and misconfigurations tied to your API endpoints. +- **Endpoint Scanning**: Active scanning that verifies whether discovered endpoints are publicly accessible and require authentication. + +{{< whatsnext desc="Explore API Posture capabilities:" >}} + {{< nextlink href="/security/application_security/api_posture/api_inventory/" >}}API Inventory: View and triage API endpoints and services.{{< /nextlink >}} + {{< nextlink href="/security/application_security/api_posture/endpoint_scanning/" >}}Endpoint Scanning: Actively scan discovered endpoints to verify public accessibility and authentication status.{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: /security/application_security/ diff --git a/content/en/security/application_security/api_posture/api_findings.md b/content/en/security/application_security/api_posture/api_findings.md new file mode 100644 index 00000000000..5a4513b5b40 --- /dev/null +++ b/content/en/security/application_security/api_posture/api_findings.md @@ -0,0 +1,33 @@ +--- +title: API Findings +description: Triage detected API risks across definitions, gateways, and live traffic. +--- + +**API Findings** provides a central triage view of all detected API risks across definitions, gateways, and live traffic. It provides a set of default rules to detect common vulnerabilities and misconfigurations. You can also set up [custom rules][1] to adapt to specific use cases. + +**API Findings** columns: + +- **Severity:** Each issue is ranked by risk. +- **Endpoints:** Shows how many endpoints are affected and their services. +- **Status and Ticketing:** `Open` or `In Progress` tracks remediation progress and workflow integration. + +Use the **Service** facet to see each service's endpoints to identify ownership and prioritize by business impact. + +## Common operations + +Click a finding to view its details and perform a workflow such as Validate > Investigate > Fix > Track: + +1. Validate: + - Review **What Happened** and **Detected In** to ensure the detection is accurate (service, endpoint, method). + - In **Next Steps**, choose whether to **Mute**, **Create Ticket**, or **Run Workflow** depending on ownership and impact. +2. Investigate: + - Use the **Context** tab to examine the endpoint snapshot and attributes (method, path, authentication flags, tags). + - **Detected In** provides information for routing ownership and remediation. + - In **Detection Rule Query**, you can edit an API finding rule by clicking **See Detection Rule**. +3. Fix: + - Follow the guidance under **Remediation**. +4. Track: + - Use **Create Ticket** to link the issue to your tracking system. + - Use **Reference Links** for developer education or code review. + +[1]: /security/application_security/policies/custom_rules/ diff --git a/content/en/security/application_security/api_posture/api_inventory/_index.md b/content/en/security/application_security/api_posture/api_inventory/_index.md new file mode 100644 index 00000000000..c7f2508f967 --- /dev/null +++ b/content/en/security/application_security/api_posture/api_inventory/_index.md @@ -0,0 +1,38 @@ +--- +title: API Inventory +description: Catalog API endpoints and services, and assess API security risk across your environment. +aliases: + - /security/application_security/api-inventory/ +further_reading: +- link: "https://www.datadoghq.com/blog/primary-risks-to-api-security/" + tag: "Blog" + text: "Mitigate the primary risks to API security" +--- + +API security relies on visibility. The biggest failure mode in most applications isn't missed vulnerabilities, it's missed APIs. + +[API Inventory][1] provides a comprehensive, up-to-date catalog and risk assessment of all API endpoints and services in your environment. + +**Inventory** is comprised of explorers that correspond to distinct layers in the API security lifecycle: + +1. **API Endpoints:** *What APIs exist, and what risk do they expose?* + + Each API endpoint is a unique entry point where data or functionality can be accessed. The API Endpoints explorer enables shadow API (undocumented endpoints with no API definition and not detected from Amazon API Gateway) and orphan API (documented endpoints without traffic) detection, asset management, and risk prioritization at the granularity attackers exploit. + +2. **Services:** *Where do risky APIs live, who owns them, and how severe is their collective risk?* + + A service groups multiple endpoints into a logical or deployed component (typically aligned with a microservice, app, or backend system). + +The Inventory explorers cover the discovery and context steps of the API security operational flow: + +1. **Discover:** Identify what endpoints exist using **API Endpoints**. +2. **Contextualize:** Identify ownership and dependencies using **Services**. + +To detect and respond to specific weaknesses, attacks, or misconfigurations, use **[API Findings][2]**. Each endpoint row in the API Endpoints explorer displays a findings chip; selecting it opens the finding in API Findings. + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/security/appsec/inventory/apis +[2]: /security/application_security/api_posture/api_findings/ diff --git a/content/en/security/application_security/api-inventory/_index.md b/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md similarity index 52% rename from content/en/security/application_security/api-inventory/_index.md rename to content/en/security/application_security/api_posture/api_inventory/api_endpoints.md index e066782d0ae..72dce5d7643 100644 --- a/content/en/security/application_security/api-inventory/_index.md +++ b/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md @@ -1,37 +1,9 @@ --- -title: API Security Inventory -further_reading: -- link: "https://www.datadoghq.com/blog/primary-risks-to-api-security/" - tag: "Blog" - text: "Mitigate the primary risks to API security" +title: API Endpoints +description: Monitor API traffic to assess endpoint risk, authentication, sensitive data flows, and exposure. --- -API security relies on visibility. The biggest failure mode in most applications isn't missed vulnerabilities, it's missed APIs. - -[API Security Inventory][7] provides a comprehensive, up-to-date catalog and risk assessment of all API endpoints and services in your environment. - -**Inventory** is comprised of explorers that correspond to distinct layers in the API security lifecycle: - -1. **API Endpoints:** *What APIs exist, and what risk do they expose?* - - Each API endpoint is a unique entry point where data or functionality can be accessed. The API Endpoints explorer enables shadow API (undocumented endpoints with no API definition and not detected from Amazon API Gateway) and orphan API (documented endpoints without traffic) detection, asset management, and risk prioritization at the granularity attackers exploit. - -2. **Services:** *Where do risky APIs live, who owns them, and how severe is their collective risk?* - - A service groups multiple endpoints into a logical or deployed component (typically aligned with a microservice, app, or backend system). -3. **API Findings:** *Which API weaknesses, attacks, or misconfigurations require investigation or remediation?* - - API Findings are security detections and policy evaluation results tied to endpoints. These represent known or inferred weaknesses or threats in API behavior or configuration. - -These explorers correspond to the common API security operational flow: - -1. **Discover:** Identify what endpoints exist using **API Endpoints**. -2. **Contextualize:** Identify ownership and dependencies using **Services**. -3. **Detect and respond:** See where misconfigurations are, and where attacks could occur, using **API Findings**. - -## API Endpoints - -[API Endpoints][7] monitors your API traffic to provide visibility into the security posture of your APIs, including: +[API Endpoints][1] monitors your API traffic to provide visibility into the security posture of your APIs, including: - **Authentication**: Whether the API enforces authentication. - **Authentication Method**: Type of authentication used, such as Basic Auth and API key. @@ -39,28 +11,28 @@ These explorers correspond to the common API security operational flow: - **Sensitive data flows**: Sensitive data handled by the API and flows between APIs. - **Attack Exposure**: If the endpoint is targeted by attacks. - **Business Logic**: Business logic and associated business logic suggestions for this API. -- **Vulnerabilities**: If the endpoint contains a vulnerability (powered by [Code Security][8] and [Software Composition Analysis][3]). +- **Vulnerabilities**: If the endpoint contains a vulnerability (powered by [Code Security][2] and [Software Composition Analysis][3]). - **Findings**: Security findings identified on this API. - **Dependencies**: APIs and Databases the API depends on. Using API Endpoints you can: - See which endpoints process sensitive data, are authenticated, have vulnerabilities or findings, or are publicly available. -- See which endpoints are at risk, and pivot directly into the [Threat Monitoring and Protection][2] service for further investigation or response. +- See which endpoints are at risk, and pivot directly into the [Threat Monitoring and Protection][4] service for further investigation or response. - See which endpoints are associated to your business's logic, and find business logic suggestions based on your endpoint's traffic history. -### Configuration +## Configuration To view API Endpoints on your services, **you must have App and API Protection Threats Protection enabled**. For Amazon Web Services (AWS) API Gateway integration, you must set up the following: -- [Amazon Web Services][9] -- [Amazon API Gateway Integration][10] +- [Amazon Web Services][5] +- [Amazon API Gateway Integration][6] -API Endpoints are discovered from the Datadog Catalog and specifically from API definitions [uploaded to Datadog][13]. For instructions on uploading API definitions, see [Create Entities][17]. +API Endpoints are discovered from the Datadog Catalog and specifically from API definitions [uploaded to Datadog][7]. For instructions on uploading API definitions, see [Create Entities][8]. -For information on what library versions are compatible with API Security Inventory, see [Enabling App and API Protection][11]. [Remote Configuration][1] is required. +For information on what library versions are compatible with API Inventory, see [Enabling App and API Protection][9]. [Remote Configuration][10] is required. |Technology|Minimum tracer version| Support for sensitive data scanning | |----------|----------|----------| @@ -75,33 +47,35 @@ For information on what library versions are compatible with API Security Invent **Note**: On .NET Core and .NET Fx tracers, you need to set the environment variable `DD_API_SECURITY_ENABLED=true` for API Security features to work properly. -### How it works +## How it works API Endpoints gathers security metadata about API traffic by leveraging the Datadog SDK with App and API Protection enabled, alongside configurations from Amazon API Gateway and uploaded API Definitions. This data includes the discovered API schema, the types of sensitive data (PII) processed, and the authentication scheme in use. The API information is continuously evaluated, ensuring a comprehensive and up-to-date view of your entire API attack surface. -API Endpoints uses [Remote Configuration][1] to manage and configure scanning rules that detect sensitive data and authentication. +API Endpoints uses [Remote Configuration][10] to manage and configure scanning rules that detect sensitive data and authentication. + +To verify whether discovered endpoints are publicly accessible and require authentication, enable [Endpoint Scanning][11]. Endpoint Scanning actively scans eligible endpoints and enriches API Inventory with verified public accessibility, authentication status, HTTP response status, and last evaluation data. The following risks are calculated for each endpoint. -### Data sources +## Data sources -In the [API Endpoints][7] explorer, the **Data Sources** show where visibility originates. +In the [API Endpoints][1] explorer, the **Data Sources** show where visibility originates. The following data sources are explored. -#### Amazon API Gateway +### Amazon API Gateway The Amazon API Gateway service formally defines your API structure. Datadog AWS integration reads this pre-defined configuration from the Amazon API Gateway, and then Datadog uses this configuration to create API endpoint entries in **Inventory**. Use **AWS API Gateway** in **Data Source** to gain visibility into these exposed endpoints. You can also use the query `datasource:aws_apigateway`. -#### Catalog +### Catalog The **Catalog** data source shows API endpoints that Datadog learned about from the formal specification uploaded to Datadog. The API specification is attached to, or registered as, a dedicated API component within the IDP service entity. This source ensures that your API inventory is complete by including all planned and formally documented endpoints. -#### APM traces +### APM traces The **Spans** data source shows real traffic and data exposure. Remediation should be performed in code, config, or access controls immediately. @@ -112,7 +86,7 @@ What actions you take depend on each of the attack surfaces: - **Processing sensitive data:** Confirm data handling complies with policy, sanitize or encrypt PII, and limit access to necessary services. - **Unauthenticated endpoint:** If the endpoint is not intentionally public, enforce authentication and update service configurations. -#### Static Endpoint Discovery +### Static Endpoint Discovery
Static Endpoint Discovery is in Preview.
@@ -122,7 +96,7 @@ What actions you take depend on each of the attack surfaces: The **Source Code** data source shows API endpoints discovered directly from your source code. This complements runtime-based discovery by surfacing endpoints earlier in the development life cycle, including endpoints that may not receive live traffic. -To use this data source, configure the [Source Code Integration][16] with GitHub, GitLab, or Azure DevOps. The following languages and frameworks are supported: +To use this data source, configure the [Source Code Integration][12] with GitHub, GitLab, or Azure DevOps. The following languages and frameworks are supported: | Language | Framework | |----------|-----------| @@ -134,9 +108,9 @@ To use this data source, configure the [Source Code Integration][16] with GitHub To filter for source code endpoints, use **Source Code** in the **Data Source** facet or the query `datasource:source_code`. Scans run when code is pushed to the default branch and on an 8-hour recurring schedule. Discovered endpoints are removed after 12 hours if they are not re-discovered by a subsequent scan. -##### Map source code endpoints to services +#### Map source code endpoints to services -Static Endpoint Discovery uses heuristics to infer which service an endpoint belongs to. For more accurate mapping, explicitly define service-to-code relationships using the `codeLocations` field in your [Catalog service definition (v3 schema)][18]: +Static Endpoint Discovery uses heuristics to infer which service an endpoint belongs to. For more accurate mapping, explicitly define service-to-code relationships using the `codeLocations` field in your [Catalog service definition (v3 schema)][13]: ```yaml apiVersion: v3 @@ -153,42 +127,42 @@ datadog: Without explicit `codeLocations`, endpoints may not merge correctly with data from other sources. -### Processing sensitive data +## Processing sensitive data -[App and API Protection][2] matches known patterns for sensitive data in API requests and responses. If it finds a match, the endpoint is tagged with the category and type of sensitive data processed. +[App and API Protection][4] matches known patterns for sensitive data in API requests and responses. If it finds a match, the endpoint is tagged with the category and type of sensitive data processed. The matching occurs within your application, and none of the sensitive data is sent to Datadog. -#### Supported data types +### Supported data types To see the supported data types (for example, `payment:card`), use the **Schema Sensitive Data** facet. You can also see the data type used in the **Sensitive Data** column. -#### Create API data scanners +### Create API data scanners -By default, Datadog App and API Protection scans for PII, credentials, and payment types. Sensitive Data Detection provides API data scanners to define custom scanner data patterns beyond the defaults and improve visibilty into the sensitive data of your API traffic. +By default, Datadog App and API Protection scans for PII, credentials, and payment types. Sensitive Data Detection provides API data scanners to define custom scanner data patterns beyond the defaults and improve visibility into the sensitive data of your API traffic. In an API data scanner, you define a scanner category and type to classify API endpoints processing sensitive data (for example, `health_info:patient_id`). Next, you define the JSON key or value conditions that trigger the scanner. -When the scanner detects sensitive data, it tags the API endpoint with the category and type and displays it in [API Endpoints][7]. +When the scanner detects sensitive data, it tags the API endpoint with the category and type and displays it in [API Endpoints][1]. To create an API data scanner and view its results, do the following: 1. In App and API Protection **Policies**, go to [Sensitive Data Detection][14]. 2. Click **New Scanner**. -3. In **Select your scanner tags**, define the category and type to classify the senstive data. The scanner tags API endpoints with the format `category:type`. +3. In **Select your scanner tags**, define the category and type to classify the sensitive data. The scanner tags API endpoints with the format `category:type`. 4. In **Define conditions on JSON keys and values**, define the JSON key or value conditions to trigger the scanner. 5. Click **Save Scanner**. The scanner is enabled by default. -6. To view the results of the scanner, go to App and API Protection [API Endpoints][7]. -7. In the **Schema Sensitive Data** facet, the category and type of your custom scanner is listed in the format `category:type`. Customer scanner `category:type` tags are also visible in the **Sensitive Data** column of the explorer. +6. To view the results of the scanner, go to App and API Protection [API Endpoints][1]. +7. In the **Schema Sensitive Data** facet, the category and type of your custom scanner is listed in the format `category:type`. Custom scanner `category:type` tags are also visible in the **Sensitive Data** column of the explorer. -### Business logic +## Business logic These tags (`(users.login.success`, `users.login.failure`, etc.) are determined by the presence of business logic traces associated with the endpoint.
Datadog can suggest a business logic tag for your endpoint based on its HTTP method, response status codes, and URL.
-### Publicly accessible +## Publicly accessible Datadog marks an endpoint as public if the client IP address is outside these ranges: @@ -197,21 +171,21 @@ Datadog marks an endpoint as public if the client IP address is outside these ra - 192.168.0.0/16 - 169.254.1.0/16 -See [Configuring a client IP header][6] for more information on the required library configuration. +See [Configuring a client IP header][15] for more information on the required library configuration. -### Endpoint authentication +## Endpoint authentication Authentication is determined by: - The presence of `Authorization`, `Token` or `X-Api-Key` headers. - The presence of a user ID within the trace (for example, the `@usr.id` APM attribute). - The request has responded with a 401 or 403 status code. -- Custom [Endpoint Tagging][15] rules that you configured +- Custom [Endpoint Tagging][16] rules that you configured When the type of authentication is available, Datadog reports it in a header through the **Authentication Method** facet. -#### Supported authentication methods +### Supported authentication methods | Category | Category facet | |---------------------------------------------------|------------------| @@ -220,9 +194,9 @@ When the type of authentication is available, Datadog reports it in a header thr | Basic Authentication | `basic_auth` | | Digest access authentication | `digest_auth` | -#### Custom Authentication support +### Custom Authentication support -Custom authentication detection is possible by configuring [Endpoint Tagging Rules][15]. These rules require the following minimum tracer versions: +Custom authentication detection is possible by configuring [Endpoint Tagging Rules][16]. These rules require the following minimum tracer versions: |Technology| Minimum tracer version | |----------|------------------------| @@ -234,83 +208,19 @@ Custom authentication detection is possible by configuring [Endpoint Tagging Rul |PHP | v1.15.0 | |Golang | v2.4.0 | -## Services - -The **Services** explorer shows where findings from API Endpoints, vulnerabilities, and runtime signals converge by service. Consider it the operational risk view of your applications. - -Review your services for the following: - -- **Vulnerability risk:** The **Vulnerability Risk** column shows aggregated SCA and IAST results for each service. Vulnerable services have components needing patching or upgrading. -- **Signals and attacks:** Click a service to see charts showing ongoing detections for active exploit attempts or recurring attack patterns. -- **Sensitive data exposure:** Services processing PII (such as SSNs or emails) demand stricter controls and monitoring. -- **Coverage and mode:** Use the **App & API Protection In Monitoring Mode**, **App & API Protection In Blocking Mode**, and the **Inactive** facet to identify where App and API Protection is enabled and enforcing runtime protection. -- **Trend graphs:** The **Trend** column indicates activity and attack frequency over time. - -### Coverage - -The **Coverage** column shows the active protection and analysis capabilities for each service. Use **Coverage** to measure the completeness of your protection stack. - -For example, here are some use cases for **Coverage**: - -- **Runtime protection coverage with App and API Protection**: - - Identify the services in **Monitoring** or **Blocking** mode. - - Move ready-to-block services into blocking mode to actively stop attacks. - - Investigate inactive services to see if instrumentation or configuration gaps are leaving APIs exposed. -- **Software Composition Analysis (SCA) coverage**: - - Track the services with analyzed open source dependencies. - - Enable SCA for unscanned services to detect vulnerable libraries early. - - Prioritize patching inactive services with high dependency risk. -- **Runtime Code Analysis (IAST) coverage**: - - Pinpoint where code-level vulnerability detection is missing. - - Enable IAST for production or high-risk apps to uncover exploitable issues in live traffic. - - Use results to confirm whether library vulnerabilities are actually reachable in code. - -## API Findings - -**API Findings** provides a central triage view of all detected API risks across definitions, gateways, and live traffic. It provides a set of default rules to detect common vulnerabilities and misconfigurations. You can also set up [custom rules][12] to adapt to specific use cases. - -**API Findings** columns: - -- **Severity:** Each issue is ranked by risk. -- **Endpoints:** Shows how many endpoints are affected and their services. -- **Status and Ticketing:** `Open` or `In Progress` tracks remediation progress and workflow integration. - -Use the **Service** facet to see each service's endpoints to identify ownership and prioritize by business impact. - -### Common operations - -Click a finding to view its details and perform a workflow such as Validate > Investigate > Fix > Track: - -1. Validate: - - Review **What Happened** and **Detected In** to ensure the detection is accurate (service, endpoint, method). - - In **Next Steps**, choose whether to **Mute**, **Create Ticket**, or **Run Workflow** depending on ownership and impact. -2. Investigate: - - Use the **Context** tab to examine the endpoint snapshot and attributes (method, path, authentication flags, tags). - - **Dectected In** provides information for routing ownership and remediation. - - In **Detection Rule Query**, you can edit an API finding rule by clicking **See Detection Rule**. -3. Fix: - - Follow the guidance under **Remediation**. -4. Track: - - Use **Create Ticket** to link the issue to your tracking system. - - Use **Reference Links** for developer education or code review. - -## Further reading - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: /tracing/guide/remote_config/ -[2]: /security/application_security/ +[1]: https://app.datadoghq.com/security/appsec/inventory/apis +[2]: /security/code_security/iast/ [3]: /security/code_security/software_composition_analysis/ -[6]: /security/application_security/policies/library_configuration/#configuring-a-client-ip-header -[7]: https://app.datadoghq.com/security/appsec/inventory/apis -[8]: /security/code_security/iast/ -[9]: /integrations/amazon-web-services -[10]: /integrations/amazon-api-gateway -[11]: /security/application_security/setup/ -[12]: /security/application_security/policies/custom_rules/ -[13]: /internal_developer_portal/catalog/entity_model/native_entities/?tab=api#native-entity-types +[4]: /security/application_security/ +[5]: /integrations/amazon-web-services +[6]: /integrations/amazon-api-gateway +[7]: /internal_developer_portal/catalog/entity_model/native_entities/?tab=api#native-entity-types +[8]: /internal_developer_portal/catalog/set_up/create_entities/#through-the-datadog-ui +[9]: /security/application_security/setup/ +[10]: /tracing/guide/remote_config/ +[11]: /security/application_security/api_posture/endpoint_scanning/ +[12]: /integrations/guide/source-code-integration/ +[13]: /internal_developer_portal/catalog/entity_model/ [14]: https://app.datadoghq.com/security/appsec/policies/scanners -[15]: https://app.datadoghq.com/security/configuration/asm/trace-tagging -[16]: /integrations/guide/source-code-integration/ -[17]: /internal_developer_portal/catalog/set_up/create_entities/#through-the-datadog-ui -[18]: /internal_developer_portal/catalog/entity_model/ +[15]: /security/application_security/policies/library_configuration/#configuring-a-client-ip-header +[16]: https://app.datadoghq.com/security/configuration/asm/trace-tagging diff --git a/content/en/security/application_security/api_posture/api_inventory/services.md b/content/en/security/application_security/api_posture/api_inventory/services.md new file mode 100644 index 00000000000..4394e5414aa --- /dev/null +++ b/content/en/security/application_security/api_posture/api_inventory/services.md @@ -0,0 +1,33 @@ +--- +title: Services +description: View where API findings, vulnerabilities, and runtime signals converge by service. +--- + +The **Services** explorer shows where findings from API Endpoints, vulnerabilities, and runtime signals converge by service. Consider it the operational risk view of your applications. + +Review your services for the following: + +- **Vulnerability risk:** The **Vulnerability Risk** column shows aggregated SCA and IAST results for each service. Vulnerable services have components needing patching or upgrading. +- **Signals and attacks:** Click a service to see charts showing ongoing detections for active exploit attempts or recurring attack patterns. +- **Sensitive data exposure:** Services processing PII (such as SSNs or emails) demand stricter controls and monitoring. +- **Coverage and mode:** Use the **App & API Protection In Monitoring Mode**, **App & API Protection In Blocking Mode**, and the **Inactive** facet to identify where App and API Protection is enabled and enforcing runtime protection. +- **Trend graphs:** The **Trend** column indicates activity and attack frequency over time. + +## Coverage + +The **Coverage** column shows the active protection and analysis capabilities for each service. Use **Coverage** to measure the completeness of your protection stack. + +For example, here are some use cases for **Coverage**: + +- **Runtime protection coverage with App and API Protection**: + - Identify the services in **Monitoring** or **Blocking** mode. + - Move ready-to-block services into blocking mode to actively stop attacks. + - Investigate inactive services to see if instrumentation or configuration gaps are leaving APIs exposed. +- **Software Composition Analysis (SCA) coverage**: + - Track the services with analyzed open source dependencies. + - Enable SCA for unscanned services to detect vulnerable libraries early. + - Prioritize patching inactive services with high dependency risk. +- **Runtime Code Analysis (IAST) coverage**: + - Pinpoint where code-level vulnerability detection is missing. + - Enable IAST for production or high-risk apps to uncover exploitable issues in live traffic. + - Use results to confirm whether library vulnerabilities are actually reachable in code. diff --git a/content/en/security/application_security/api_posture/endpoint_scanning.md b/content/en/security/application_security/api_posture/endpoint_scanning.md new file mode 100644 index 00000000000..48a9565fc20 --- /dev/null +++ b/content/en/security/application_security/api_posture/endpoint_scanning.md @@ -0,0 +1,36 @@ +--- +title: Endpoint Scanning +description: Verify whether discovered API endpoints are publicly accessible and require authentication. +--- + +
Endpoint Scanning is in Preview and is subject to change.
+ +Endpoint Scanning probes your API endpoints from outside your environment and records their HTTP responses, rather than inferring behavior from observed traffic. The results enrich the [API Inventory][2] with verified authentication and visibility data. + +Endpoint Scanning sends only `GET` requests. It does not call `POST`, `PUT`, `PATCH`, or `DELETE` endpoints, and never modifies data on your endpoints. + +
At this time, Endpoint Scanning only scans endpoints that AAP discovers from APM traces.
+ +## What Endpoint Scanning verifies + +For each scanned endpoint, Datadog records: + +- **Authentication status**: Whether the endpoint requires authentication. +- **Public visibility**: Whether the endpoint is reachable without credentials. +- **HTTP response status**: The status code returned by the endpoint. +- **Last evaluation timestamp**: When the endpoint was last scanned. + +Use this information to prioritize exposed endpoints, confirm whether important APIs enforce authentication, and investigate API findings with stronger evidence about how the endpoint behaves. + +## Enable Endpoint Scanning + +Endpoint Scanning is off by default. To enable it: + +1. In App and API Protection settings, go to [API Security Testing][3]. +2. Toggle **Enable Endpoint Scanning** on. + +After you enable it, Datadog scans eligible endpoints in the background in batches. Endpoints are retested approximately every seven days. + +[1]: /security/application_security/ +[2]: /security/application_security/api_posture/api_inventory/ +[3]: https://app.datadoghq.com/security/configuration/asm/api-security-testing diff --git a/content/en/security/guide/security-findings-migration.md b/content/en/security/guide/security-findings-migration.md index 9f2fbfff896..8b628af3369 100644 --- a/content/en/security/guide/security-findings-migration.md +++ b/content/en/security/guide/security-findings-migration.md @@ -150,7 +150,7 @@ Security findings encompass misconfigurations, vulnerabilities, and security ris [10]: /security/cloud_security_management/identity_risks/ [11]: /security/security_inbox/?s=attack%20path#types-of-findings-in-security-inbox [12]: /security/code_security/iac_security/ -[13]: /security/application_security/api-inventory/#api-findings +[13]: /security/application_security/api_posture/api_findings/ [14]: /help [15]: /api/latest/security-monitoring/#list-findings [16]: /api/latest/security-monitoring/#get-a-finding diff --git a/layouts/partials/app_and_api_protection/python/capabilities.html b/layouts/partials/app_and_api_protection/python/capabilities.html index 1ebb859107b..ff4180126b6 100644 --- a/layouts/partials/app_and_api_protection/python/capabilities.html +++ b/layouts/partials/app_and_api_protection/python/capabilities.html @@ -19,11 +19,11 @@ 1.19.0 - Automatic user activity event tracking + Automatic user activity event tracking 1.17.0 - API Security Inventory + API Inventory 2.6.0 diff --git a/layouts/partials/nav/left-nav.html b/layouts/partials/nav/left-nav.html index a8b8208f373..1b3cac90664 100644 --- a/layouts/partials/nav/left-nav.html +++ b/layouts/partials/nav/left-nav.html @@ -69,7 +69,7 @@