Skip to main content

Datadog/security Signals

@webframp/datadog/security-signalsv2026.10.21.1· Apache-2.0· 5d agoBEHAVIORS
01README

Datadog Security Signals — signal search, triage, and archiving

02Release Notes

2026.10.21.1

Changed: The README now shows how to store the API key and application key in a datadog vault and wire them with ${{ vault.get("datadog", "API_KEY") }} and ${{ vault.get("datadog", "APP_KEY") }}. The previous example passed DD_API_KEY and DD_APP_KEY as literal global arguments, which swamp rejects for sensitive arguments.

Changed: The apiKey and appKey descriptions now say to supply them with a vault.get expression. Both were already marked sensitive.

Upgrade note: Documentation and argument descriptions only. Methods, arguments, resource schemas and stored data are unchanged.

03Behaviors1
@webframp/datadog/security-signalsv2026.10.21.1datadog/security_signals.ts

Global Arguments

ArgumentTypeDescription
apiKeystringDatadog API key (DD-API-KEY). Wire it with ${{ vault.get("datadog", "API_KEY") }}; never pass the literal value.
appKeystringDatadog application key (DD-APPLICATION-KEY). Wire it with ${{ vault.get("datadog", "APP_KEY") }}; never pass the literal value.
site?enumDatadog site
fn list_security_monitoring_signals(filter_query?: string, filter_from?: string, filter_to?: string, sort?: string)
Get a quick list of security signals
ArgumentTypeDescription
filter_query?stringThe search query for security signals.
filter_from?stringThe minimum timestamp for requested security signals.
filter_to?stringThe maximum timestamp for requested security signals.
sort?stringThe order of the security signals in results.
fn bulk_edit_security_monitoring_signals_assignee(entries: array)
Bulk update triage assignee of security signals
ArgumentTypeDescription
entriesarrayArray of items to submit
fn bulk_edit_security_monitoring_signals_state(entries: array)
Bulk update triage state of security signals
ArgumentTypeDescription
entriesarrayArray of items to submit
fn bulk_edit_security_monitoring_signals(entries: array)
Bulk update security signals
ArgumentTypeDescription
entriesarrayArray of items to submit
fn search_security_monitoring_signals(filter?: unknown, page?: unknown, sort?: unknown)
Get a list of security signals
ArgumentTypeDescription
filter?unknown
page?unknown
sort?unknown
fn get_security_monitoring_signal(signal_id: string)
Get a signal's details
ArgumentTypeDescription
signal_idstringThe ID of the signal.
fn edit_security_monitoring_signal_assignee(signal_id: string, assignee: unknown, version?: unknown)
Modify the triage assignee of a security signal
ArgumentTypeDescription
signal_idstringThe ID of the signal.
assigneeunknown
version?unknown
fn edit_security_monitoring_signal_incidents(signal_id: string, incident_ids: unknown, version?: unknown)
Change the related incidents of a security signal
ArgumentTypeDescription
signal_idstringThe ID of the signal.
incident_idsunknown
version?unknown
fn get_investigation_log_queries_matching_signal(signal_id: string)
Get investigation queries for a signal
ArgumentTypeDescription
signal_idstringThe ID of the signal.
fn edit_security_monitoring_signal_state(signal_id: string, archive_comment?: unknown, archive_reason?: unknown, state: unknown, version?: unknown)
Change the triage state of a security signal
ArgumentTypeDescription
signal_idstringThe ID of the signal.
archive_comment?unknown
archive_reason?unknown
stateunknown
version?unknown
fn get_suggested_actions_matching_signal(signal_id: string)
Get suggested actions for a signal
ArgumentTypeDescription
signal_idstringThe ID of the signal.
fn edit_security_monitoring_signal(signal_id: string, archive_comment?: unknown, archive_reason?: unknown, assignee?: unknown, state?: unknown, version?: unknown)
Update security signal triage state or assignee
ArgumentTypeDescription
signal_idstringThe ID of the signal.
archive_comment?unknown
archive_reason?unknown
assignee?unknown
state?unknown
version?unknown

Resources

security_monitoring_signals(infinite)— Get a quick list of security signals
bulk_edit_security_monitoring_signals_assignee(infinite)— Bulk update triage assignee of security signals
bulk_edit_security_monitoring_signals_state(infinite)— Bulk update triage state of security signals
bulk_edit_security_monitoring_signals(infinite)— Bulk update security signals
search_security_monitoring_signals(infinite)— Get a list of security signals
security_monitoring_signal(infinite)— Get a signal's details
edit_security_monitoring_signal_assignee(infinite)— Modify the triage assignee of a security signal
edit_security_monitoring_signal_incidents(infinite)— Change the related incidents of a security signal
investigation_log_queries_matching_signal(infinite)— Get investigation queries for a signal
edit_security_monitoring_signal_state(infinite)— Change the triage state of a security signal
suggested_actions_matching_signal(infinite)— Get suggested actions for a signal
edit_security_monitoring_signal(infinite)— Update security signal triage state or assignee
04Previous Versions13
2026.10.15.1Apache-2.0

2026.10.15.1

Changed: Generated tests now include one execution test per method, so every method is covered. Nothing behavioral changed in the model code, schemas or resources.

2026.10.14.2Apache-2.0

2026.10.14.2

Fixed: The three bulk signal methods (assignee, state, update) now accept an entries array (up to 199 signals) and send it as the data payload. They previously sent an empty {data: {attributes: {}}} body and could not change any signal.

Upgrade note: Arguments changed from none to a required entries array; no resources or schemas changed.

2026.10.14.1Apache-2.0(was none)

2026.10.14.1

Added: The manifest now declares license: Apache-2.0 (SPDX). The registry quality rubric scores a declared license separately from the bundled LICENSE.md.

Upgrade note: Metadata only. No code, schema, or behavioral changes.

2026.10.07.1

Fixed: The shared API helper no longer throws on a successful response with an empty body (such as 202 Accepted); it returns an empty result. Paginated list requests tolerate an empty page body the same way. A body that is not valid JSON now fails with an error naming the HTTP method, path, and status, with a snippet of the body.

Upgrade note: Only the shared helper changed. No methods, arguments, schemas, or resources changed, so no migration is needed and existing stored resources remain valid.

2026.09.18.1

2026.09.18.1

Upgrade note: Normalized npm:zod dependency version to 4.6.5 across the repo. No behavioral changes in this extension.

2026.09.15.1

2026.09.15.1

Changed: Bump zod 4.4.3 → 4.6.5

2026.08.28.2

Hardened codegen: instance names sanitized against path traversal; string schema patterns emit regex validation; output schemas passthrough unknown fields.

2026.08.28.2

2026.08.28.2

Hardened codegen: instance names sanitized against path traversal; string schema patterns emit regex validation; output schemas passthrough unknown fields.

updated labels

2026.08.28.1

2026.08.28.1

Changed: Normalized the extension license to Apache-2.0 and corrected the copyright holder to "Sean Escriva". Extensions that previously shipped an MIT LICENSE.md are now Apache-2.0, consistent with the repository root and every other extension. No code or behavioral changes.

Upgrade note: License text only. No API, schema, or runtime behavior changed.

2026.08.26.2

Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry quality scorer can resolve dependencies and score the extension. An earlier release used a bare "zod" import-map specifier, which published but scored as unscored.

Changed: Retained explicit compilerOptions.strict in deno.json. No behavioral or schema changes.

2026.08.26.2

2026.08.26.2

Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry quality scorer can resolve dependencies and score the extension. An earlier release used a bare "zod" import-map specifier, which published but scored as unscored.

Changed: Retained explicit compilerOptions.strict in deno.json. No behavioral or schema changes.

2026.08.25.1

2026.08.25.1

Changed: Updated labels for improved extension discoverability. Added cross-cutting category labels (security, observability, finops, infrastructure, networking, compliance, devops, ai, incident-response) where applicable.

updated labels

2026.08.24.1

2026.08.24.1

Added: Output metadata attributes for observability.

  • durationMs: Method execution duration in milliseconds.
  • collectedBy: Extension name that produced the data.
  • fetchedAt: ISO 8601 timestamp when data was fetched (added to resources that previously lacked it).
2026.08.21.2

2026.08.21.2

Changed: Error messages and input validation are more specific.

  • API errors now name the HTTP method and path that was attempted (e.g. Datadog API HTTP 404: GET /api/v2/security_monitoring/signals/abc-123) instead of just the raw status code and response body.
  • A network-level failure (DNS error, connection reset, timeout) reaching the Datadog API now raises Datadog API request failed: <METHOD> <path>: <reason> instead of an unlabeled fetch error.
  • signal_id is now rejected up front if empty on every method that takes it, instead of building a malformed request path.
  • edit_security_monitoring_signal_incidents now requires incident_ids to be a non-empty array of integers (it was previously typed as unknown and accepted anything, including nothing at all).

No changes to request/response shapes or existing successful-path behavior.

2026.08.21.1

Changed: Tightened and clarified Zod schemas as part of a repo-wide schema audit.

  • Added .min(1) to apiKey and appKey in the global arguments schema — both are sent directly as request headers, and an empty value would never be accepted by the Datadog API.
  • Added descriptions to previously undocumented filter, page, sort, assignee, incident_ids, version, archive_comment, archive_reason, and state arguments on the search and triage-edit methods, matching the wording already used for the equivalent resource schema fields.
  • Added a description to the result field on the bulk-edit resource schemas.

No behavioral changes — these are documentation and validation tightenings only.

2026.07.20.11

Added: Initial code-generated release of @webframp/datadog/security-signals with 12 methods covering the Datadog security signals API surface.

2026.08.21.1

2026.08.21.1

Changed: Tightened and clarified Zod schemas as part of a repo-wide schema audit.

  • Added .min(1) to apiKey and appKey in the global arguments schema — both are sent directly as request headers, and an empty value would never be accepted by the Datadog API.
  • Added descriptions to previously undocumented filter, page, sort, assignee, incident_ids, version, archive_comment, archive_reason, and state arguments on the search and triage-edit methods, matching the wording already used for the equivalent resource schema fields.
  • Added a description to the result field on the bulk-edit resource schemas.

No behavioral changes — these are documentation and validation tightenings only.

2026.07.20.11

Added: Initial code-generated release of @webframp/datadog/security-signals with 12 methods covering the Datadog security signals API surface.

2026.07.20.11

2026.07.20.11

Added: Initial code-generated release of @webframp/datadog/security-signals with 12 methods covering the Datadog security signals API surface.

05Stats
A
100 / 100
Downloads
38
Archive size
19.1 KB
  • Has README or module doc2/2earned
  • README has a code example1/1earned
  • README is substantive1/1earned
  • Most symbols documented1/1earned
  • No slow types (deprecated)1/1earned
  • Dependencies pass trust audit2/2earned
  • Has description1/1earned
  • Platform support declared (or universal)2/2earned
  • License2/2earned
  • Verified public repository2/2earned
06Platforms
07Labels