# Exposure Observatory by Datadog

> Exposure Observatory: a simple guide to the exposure loop (assess, prioritize, fix, verify), how it applies to CVEs, misconfigurations and identity, live sightings, and a short maturity self-assessment.

Exposure Observatory · concept prototype. Based on the exposure-loop maturity model and research notes (Nov 2026). No sign-in. We measure anonymous usage with Datadog RUM (session replay masks anything you type); see the Privacy Policy.

## What attackers can reach, and how fast it gets fixed. undefined

Exposure sightings from Datadog data across 80,000+ real-world environments, a simple loop for fixing what matters, and a three-minute maturity check.

**undefined**

## Four steps, on repeat

An exposure is any weakness an adversary can reach that matters to the business. CVEs are only part of it; identity and misconfiguration make up most of what attackers actually walk through.

1. **Assess**: Continuously find exposures across identity, misconfiguration and CVEs, with the runtime context that says whether each one is reachable.
2. **Prioritize**: Rank before you spend budget: known exploitation (KEV), exploit likelihood (EPSS), runtime context and attack-path position.
3. **Fix**: Make the change: a PR, a policy diff, a dependency bump. Whoever makes it, whether a person, a pipeline or a tool, works with scoped, short-lived credentials.
4. **Verify**: A check the fixer can't edit proves the gap closed: a rescan, an exploit re-run, a plan diff, or a no-new-access check. Then the loop goes around again.

Merge is not closure.

## CVEs are the part everyone sees

Most programs start with CVEs because scanners make them easy to count. But attackers mostly walk through misconfigurations and identity. Each of these runs through the same four steps; what changes is the signal, the fix, and how you prove it closed.

- Identity & credential issues: ~80% (share of all exposures; source: XM Cyber, 2024)
- CVEs (critical exposures): ~11% (under 1% of all on-prem exposures; source: XM Cyber, 2024)
- Critical CVEs still critical: 18% (after adding runtime context; source: Datadog DevSecOps, 2026)

### Vulnerabilities (CVE)

First-party code, dependencies and base images, vendor patches

- **Assess**: Scanner findings plus runtime context: is it reachable, in production, with a public exploit?
- **Prioritize**: KEV first, then EPSS and internet exposure. CVSS alone over-ranks most of the list.
- **Fix**: Dependency bump, image rebuild, code patch, or vendor update.
- **Verify**: Rescan and re-run the exploit. A passing build is not proof.
- **Watch for**: brand-new "fix" releases: pin by digest or SHA and keep a cooldown. Vendor patches stay human-gated.

DDSQL check, critical cves that are actually reachable (Needs Datadog Cloud Security or Code Security (dd.security_findings).):

```sql
SELECT cve, package, version, service, resource, epss
FROM dd.security_findings(
  columns => ARRAY['@advisory.cve', '@package.name', '@package.version',
                   '@service.name', '@resource_name',
                   '@risk_detail.has_high_exploitability_chance.evidence.epss_score'],
  filter  => '@finding_type:vulnerability AND @status:open AND @severity:critical
              AND @risk.is_production:true AND @risk.is_publicly_accessible:true'
) AS (cve VARCHAR, package VARCHAR, version VARCHAR,
      service VARCHAR, resource VARCHAR, epss DECIMAL)
ORDER BY epss DESC
```

### Misconfiguration (MIS)

IaC-managed resources and live control-plane state

- **Assess**: Posture and IaC scanning, plus one question: is this resource managed in code or only live?
- **Prioritize**: Public exposure and position on an attack path.
- **Fix**: A change to the IaC and the live resource together. Fixing only one side drifts back.
- **Verify**: A plan diff, not just a quiet scanner: 57–71% of scanner-cleared Terraform fixes were deceptive.
- **Watch for**: GitOps reconciliation undoing a live fix, a remediate-and-restore loop that can run all weekend.

DDSQL check, open misconfigurations on internet-exposed resources (Needs Datadog Cloud Security or Code Security (dd.security_findings).):

```sql
SELECT rule, resource_type, resource, account, region
FROM dd.security_findings(
  columns => ARRAY['@rule.name', '@cloud_resource.type', '@resource_name',
                   '@cloud_resource.account', '@cloud_resource.region'],
  filter  => '@finding_type:misconfiguration AND @status:open
              AND @risk.is_publicly_accessible:true'
) AS (rule VARCHAR, resource_type VARCHAR, resource VARCHAR,
      account VARCHAR, region VARCHAR)
```

### Identity (ID)

Over-permissioned roles, stale keys, toxic combinations

- **Assess**: Granted versus used permissions, unused credentials, risky trust relationships.
- **Prioritize**: Privilege level and attack-path choke points; a small share of identities expose most of what matters.
- **Fix**: Narrow in stages: a permissions boundary first, then replace the policy once a person approves.
- **Verify**: A no-new-access check and usage data that covers a full quarter.
- **Watch for**: short usage windows: 14 days of logs misses quarterly jobs and DR paths.

DDSQL check, identity risks with privileged access (Needs Datadog Cloud Security or Code Security (dd.security_findings).):

```sql
SELECT rule, resource, account, severity
FROM dd.security_findings(
  columns => ARRAY['@rule.name', '@resource_name', '@cloud_resource.account', '@severity'],
  filter  => '@finding_type:identity_risk AND @status:open
              AND @risk.has_privileged_access:true'
) AS (rule VARCHAR, resource VARCHAR, account VARCHAR, severity VARCHAR)
```

## What the observatory is seeing

Source: Datadog data from 80,000+ real-world environments.

How often each exposure threat shows up, which way it's trending, and how fast it gets fixed.

Exposure threats tracked, each with a DDSQL query a Datadog customer can run to check for it (Paste into the DDSQL Editor in Datadog. Field values can vary by account, so treat these as starting points.):

### Internet-facing RCE in a web framework (CVE, KEV)

Known exploited; public PoC

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT cve, package, version, service, epss
FROM dd.security_findings(
  columns => ARRAY['@advisory.cve', '@package.name', '@package.version', '@service.name',
                   '@risk_detail.has_high_exploitability_chance.evidence.epss_score'],
  filter  => '@finding_type:vulnerability AND @status:open AND @severity:critical
              AND @risk.is_publicly_accessible:true AND @risk.has_exploit_available:true'
) AS (cve VARCHAR, package VARCHAR, version VARCHAR, service VARCHAR, epss DECIMAL)
ORDER BY epss DESC
```

### Unpatched VPN appliance (CVE, KEV)

Vendor patch; human-gated

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings). Only covers hosts Datadog scans; appliances without an Agent need the vendor's own advisory feed.

```sql
SELECT cve, host, package, version, summary
FROM dd.security_findings(
  columns => ARRAY['@advisory.cve', '@host.name', '@package.name', '@package.version', '@advisory.summary'],
  filter  => '@finding_type:vulnerability AND @status:open
              AND @risk.has_exploit_available:true AND @advisory.summary:*VPN*'
) AS (cve VARCHAR, host VARCHAR, package VARCHAR, version VARCHAR, summary VARCHAR)
```

### Vulnerable OpenSSL in base images (CVE)

Fixed by image rebuild

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT image, version, count(*) AS findings
FROM dd.security_findings(
  columns => ARRAY['@container_image.name', '@package.version'],
  filter  => '@finding_type:vulnerability AND @status:open AND @package.name:openssl'
) AS (image VARCHAR, version VARCHAR)
GROUP BY image, version
ORDER BY findings DESC
```

### Prototype pollution in an npm dependency (CVE)

Reachable in 1 of 5 services

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT package, version, service, reachable
FROM dd.security_findings(
  columns => ARRAY['@package.name', '@package.version', '@service.name', '@risk.is_function_reachable'],
  filter  => '@finding_type:vulnerability AND @status:open
              AND @package.ecosystem:npm AND @vulnerability.cwes:"CWE-1321"'
) AS (package VARCHAR, version VARCHAR, service VARCHAR, reachable BOOLEAN)
ORDER BY reachable DESC
```

### Publicly readable storage bucket (Misconfiguration)

Often outside IaC

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT bucket, account, region, rule
FROM dd.security_findings(
  columns => ARRAY['@resource_name', '@cloud_resource.account', '@cloud_resource.region', '@rule.name'],
  filter  => '@finding_type:misconfiguration AND @status:open
              AND @cloud_resource.type:aws_s3_bucket AND @risk.is_publicly_accessible:true'
) AS (bucket VARCHAR, account VARCHAR, region VARCHAR, rule VARCHAR)
```

### SSH open to 0.0.0.0/0 (Misconfiguration)

Security group drift

Requires: Needs the AWS integration with resource collection enabled.

```sql
SELECT account_id, group_id, security_group_rule_id, cidr_ipv4, cidr_ipv6, from_port, to_port
FROM aws.security_group_rule
WHERE is_egress = false
  AND (cidr_ipv4 = '0.0.0.0/0' OR cidr_ipv6 = '::/0')
  AND (ip_protocol = '-1' OR (ip_protocol = 'tcp' AND from_port <= 22 AND to_port >= 22))
```

### IMDSv1 on internet-facing instances (Misconfiguration)

Credential theft path

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT instance, account, region, rule
FROM dd.security_findings(
  columns => ARRAY['@resource_name', '@cloud_resource.account', '@cloud_resource.region', '@rule.name'],
  filter  => '@finding_type:misconfiguration AND @status:open AND @cloud_resource.type:aws_ec2_instance
              AND @rule.name:*IMDSv2* AND @risk.is_publicly_accessible:true'
) AS (instance VARCHAR, account VARCHAR, region VARCHAR, rule VARCHAR)
```

### Database snapshot shared publicly (Misconfiguration)

Rare but severe

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings).

```sql
SELECT snapshot, account, region, rule
FROM dd.security_findings(
  columns => ARRAY['@resource_name', '@cloud_resource.account', '@cloud_resource.region', '@rule.name'],
  filter  => '@finding_type:misconfiguration AND @status:open
              AND @cloud_resource.type:aws_rds_db_snapshot AND @risk.is_publicly_accessible:true'
) AS (snapshot VARCHAR, account VARCHAR, region VARCHAR, rule VARCHAR)
```

### Access key unused for 90+ days (Identity)

Long-lived credential

Requires: Needs the AWS integration with resource collection enabled.

```sql
SELECT account_id, "user",
       access_key_1_last_used_date, access_key_2_last_used_date
FROM aws.iam_credential_report
WHERE (access_key_1_active AND COALESCE(access_key_1_last_used_date, access_key_1_last_rotated)
         < now() - INTERVAL '90 days')
   OR (access_key_2_active AND COALESCE(access_key_2_last_used_date, access_key_2_last_rotated)
         < now() - INTERVAL '90 days')
```

### Cross-account role with admin access (Identity)

Attack-path choke point

Requires: Needs the AWS integration with resource collection enabled. A text match on the trust and attached policies; confirm each hit in the IAM console.

```sql
SELECT account_id, role_name, arn
FROM aws.iam_role
WHERE CAST(attached_policies AS VARCHAR) LIKE '%AdministratorAccess%'
  AND CAST(assume_role_policy_document AS VARCHAR) LIKE '%arn:aws:iam::%'
  AND CAST(assume_role_policy_document AS VARCHAR) NOT LIKE '%' || account_id || '%'
```

### CI/CD token with org-wide write (Identity)

Supply-chain blast radius

Requires: Needs Datadog Cloud Security or Code Security (dd.security_findings). Finds valid leaked secrets, including CI/CD tokens; check each token's scope in your CI provider.

```sql
SELECT secret_type, repository, file, line
FROM dd.security_findings(
  columns => ARRAY['@secret.resource_type', '@git.repository_url',
                   '@code_location.filename', '@code_location.start.line'],
  filter  => '@status:open AND @secret.validation_status:valid'
) AS (secret_type VARCHAR, repository VARCHAR, file VARCHAR, line BIGINT)
```

### Console user without MFA (Identity)

Easy first foothold

Requires: Needs the AWS integration with resource collection enabled.

```sql
SELECT account_id, "user", password_last_used
FROM aws.iam_credential_report
WHERE password_enabled = true
  AND mfa_active = false
ORDER BY password_last_used DESC
```

CVE criticality: CVE sightings are on a hockey stick. But CVSS alone overstates the problem: once runtime context is applied (is it reachable, in production, with a known exploit?) most "critical" findings drop out. The dashed line is what's left to fix first.

## Six phases of trust

Agents can run the whole loop one day; teams get there one phase at a time. Each phase hands automation more of the loop and has an exit gate you pass with evidence. Phase 5 is on the map, but nobody has evidence for it yet.

### Phase 0: Foundations

*Lay the stones before anything runs on its own.*

- **Automation**: Nothing automated yet. People run the loop by hand.
- **People**: Build the basics: a proof check for every finding type, a dedicated identity for any automation, a permission ceiling, and risk-based ranking.

Exit gate → Observe:

- Every finding type has a check that proves a fix worked
- Any automation has its own identity, an owner, and credentials that expire within an hour
- A permission ceiling the automation can't raise itself
- Findings ranked by KEV, EPSS, runtime context and attack path

### Phase 1: Observe

*Shadow mode: watch, don't touch.*

- **Automation**: Writes proposed fixes to a log. Nothing gets applied.
- **People**: Compare those proposals with the fixes people actually shipped.

Exit gate → Suggest:

- Two weeks or more in shadow, with agreement measured per class
- A do-nothing run scores zero on every live check
- The automation can't edit tests, harnesses, scanner config or suppressions
- The policy engine's log-only week shows no would-be denials

### Phase 2: Suggest

*Automation drafts, a person signs.*

- **Automation**: Opens PRs that record how they were produced and line-level provenance.
- **People**: A named person merges every change and owns it.

Exit gate → Bounded apply:

- Closure is confirmed by rescan, not by merge
- Rework and reverts are tracked separately from merge rate
- The kill switch and circuit breaker have been tripped on purpose
- Approval rate stays under 90%, so review is still doing work

### Phase 3: Bounded apply

*One fenced garden at a time.*

- **Automation**: Applies one additive, reversible control class on its own, with the policy engine enforcing.
- **People**: Keep subtractive changes, and re-authorize after every breaker trip.

Exit gate → Governed:

- Eight weeks of automated reverts at or below the human baseline
- No fix later undone by IaC or GitOps reconciliation
- Zero supply-chain events through the auto-merge path
- Live resources that also live in Terraform get two-sided fixes, or none

### Phase 4: Governed

*Flagged, observed, self-correcting.*

- **Automation**: Agents ship every fix behind a feature flag, ramp it by environment and cohort, watch SLOs and security signals in real time, and roll back on their own the moment something regresses.
- **People**: Set the guardrails as code (flag policies, blast-radius budgets, rollback thresholds) and review the agent's evals and traces, not every diff.

Exit gate → Autonomous:

- Every automated fix ships behind a feature flag, with automatic rollback that has fired in production
- Progressive rollouts gated on SLO burn and security signals, with a blast-radius budget per class
- Continuous evals against a held-out set of real fixes, with a measured false-accept rate
- Every agent action traced end to end; any model, prompt or tool change re-runs the evals and resets the phase

### Phase 5: Autonomous (not evidenced)

*Not evidenced. Yet.*

- **Automation**: Would close the loop unattended.
- **People**: No organization or vendor has shown evidence for this phase.

What would have to exist first:

- A published false-accept rate for unattended security merges
- A semantic check for IaC with a measured deceptive-fix rate
- An over-permission metric and rate for identity fixes
- An independent certification issued against a written autonomy case

## Three rules that keep the phases honest

- **Phases are per class**: Dependency bumps can sit at Phase 3 while identity fixes stay at Phase 1. A single maturity number for the whole org hides that.
- **Change anything, drop to Phase 2**: A new model, prompt, tool set or environment sends the affected class back to Suggest. The evidence you collected belonged to the old setup.
- **Some work never goes hands-off**: Vendor patches for appliances and Tier 2 code stay human-gated. Tier 2 covers auth, billing, IaC, identity policy, multi-file changes, and anything that touches tests or CI.

### Litmus questions (a confident answer is the signal)

- “What percent of automated PRs merge?” That's a vanity metric. Ask for rework and revert rates instead.
- “Does an AI reviewer approve your patches?” It should only reject or rank. LLM judges run 17–22% false positives.
- “What's your mean time to remediate?” Ask whether closure is measured at merge or at rescan.
- “How many controls auto-remediate?” More than one per residency window means a phase was skipped.

## Where does your loop sit? (assessment)

Twelve questions across the four gates that lead from Foundations to Governed. Answer for one exposure class at a time, using evidence. "We plan to" counts as a no. No sign-in; we only record anonymous usage, such as which phase you reached.

How to score:

- Score one exposure class at a time.
- Answer every question with evidence, not intent: "we plan to" counts as no.
- Answers: Yes = 1, Partly = 0.5, No = 0.
- A gate passes only when every question in it is answered Yes (1).
- The phase reached is the number of consecutive gates passed, starting from gate 1 (0 to 4).
- Some classes have a cap (see classes[].cap): the phase never goes above it.
- Phase 5 (Autonomous) is not reachable through this assessment; nobody has evidence for it yet.
- Changing the model, prompt, tools or environment sends the affected class back to Phase 2.

Exposure classes: Identity risk; Misconfig · IaC; Misconfig · live; CVE · first-party; CVE · dependencies; CVE · vendor patches (cap: Phase 3).

### Gate 1: Foundations → Observe

1.1. Does every finding type you act on have a check that proves the fix worked?
   - Why: A finding type with no proof check can't leave Phase 0.
   - Evidence: A table mapping each finding type to its check: exploit re-run, plan diff, no-new-access check, or rescan.
   - If not yes: Map every finding type to a proof check. Any type left without one stays manual.
1.2. Does any automation in the loop have its own identity, a named owner, and credentials that expire within an hour?
   - Why: Automation on shared human or service credentials can't be scoped, audited or revoked.
   - Evidence: The role or app registration, its session policy, and the owner.
   - If not yes: Give each bot, pipeline or tool its own role, name an owner, and cap sessions at one hour.
1.3. Is there a permission ceiling (a boundary or SCP) the automation can't raise by editing its own policy?
   - Why: Granting permissions reactively is the named anti-pattern.
   - Evidence: The boundary or SCP document.
   - If not yes: Attach a permissions boundary or SCP that sits above anything the automation can edit.

### Gate 2: Observe → Suggest

2.1. Have proposed fixes run in shadow for at least two weeks, and have you measured how often they matched the fix a person shipped?
   - Why: Merge rate is a vanity metric. Agreement with the fix a person shipped is not.
   - Evidence: The shadow queue with its date range, plus a per-class agreement rate.
   - If not yes: Run proposals in shadow for two weeks or more and score them against the fixes people shipped.
2.2. Did a do-nothing run score zero on every live check?
   - Why: A check that passes a no-op is broken.
   - Evidence: The no-op diagnostic run.
   - If not yes: Run a no-op against every live check and fix any check that scores it above zero.
2.3. Is the automation blocked from editing tests, harnesses, scanner config and suppression comments, and does a tamper scan show zero events?
   - Why: Every documented case of gaming the checks starts here.
   - Evidence: The protected-paths list and the tamper-scan output.
   - If not yes: Lock tests, harnesses, scanner config and suppressions away from the automation, and tamper-scan every change.

### Gate 3: Suggest → Bounded apply

3.1. Does every automated PR record how it was produced, and does a named person merge it and own it?
   - Why: A co-author tag is not provenance, and automation doesn't sign off.
   - Evidence: A sample PR with its provenance (tool, version, checks run) and the branch protection rule.
   - If not yes: Attach provenance to every automated PR and require a named person to merge it.
3.2. Is closure confirmed by rescan, and do you track rework and reverts separately from merge rate?
   - Why: Merge is not closure. In one study, 15% of merged automated PRs needed human correction.
   - Evidence: The closure rule and the rework and revert dashboard.
   - If not yes: Close findings at rescan, not at merge, and track rework and reverts on their own.
3.3. Have you tripped the kill switch and the circuit breaker on purpose?
   - Why: A switch nobody has tested is decoration.
   - Evidence: The drill date and the person who re-authorized.
   - If not yes: Run a kill-switch and circuit-breaker drill, and record who re-authorized afterwards.

### Gate 4: Bounded apply → Governed

4.1. Does exactly one control class apply automatically, limited to additive and reversible changes, under a deny-by-default policy engine in enforce mode?
   - Why: "Several" means a phase was skipped. Subtractive changes are where outages come from.
   - Evidence: The enablement list, the action catalog, and a sample of denied calls.
   - If not yes: Pick one additive, reversible control class to apply automatically, and switch the policy engine to enforce.
4.2. Over the last eight weeks, are automation-caused reverts at or below the human baseline, with no fix undone by IaC or GitOps drift?
   - Why: The documented failure is a weekend-long remediate-and-restore loop.
   - Evidence: The two revert numbers and the drift reports.
   - If not yes: Compare automated reverts with the human baseline, and send resources that are both live and in IaC through two-sided fixes.
4.3. Does every automated change ship behind a feature flag, ramp progressively, and roll back automatically when SLOs or security signals regress?
   - Why: A flag turns a bad fix into a toggle, not an incident. Bots merged a compromised axios release within an hour of publication.
   - Evidence: The flag for a recent automated fix, its rollout steps, and an automatic rollback that fired.
   - If not yes: Put every automated fix behind a feature flag with a staged rollout and an automatic, SLO-driven rollback.

### Guidance by phase reached

- Phase 0: Keep the loop manual for now. Build the proof checks, identities and permission ceiling first.
- Phase 1: Run automation in shadow: log its proposals, apply nothing, and measure how often they agree with people.
- Phase 2: Let automation open PRs. People merge them, and a finding closes only at rescan.
- Phase 3: Apply one additive control class automatically, with rollback ready and the breaker armed.
- Phase 4: Scale out: flags on every fix, progressive rollouts, continuous evals, and rollbacks the agents trigger themselves.

## Built for agents, too

The same content as plain files an AI agent can read: the maturity model, the twelve questions with scoring rules, the DDSQL checks and the glossary.

Bits AI is Datadog's AI assistant. The Bits AI prompts assume your Datadog account collects security findings and cloud resources.

- **Find my real exposures** (Bits AI): List critical vulnerabilities in our production services that are publicly accessible and have a known exploit or an EPSS score above 0.1. Group them by service and tell me which sit on an attack path to sensitive data.
- **Check my identity loop** (Bits AI): Which IAM users and roles have access keys or permissions unused for 90 days? Rank them by privilege and flag any role that can be assumed from another account.
- **Measure mitigation speed** (Bits AI): What's our average time from first detection to resolution for critical security findings over the last 26 weeks, split by team? Which findings were closed without a follow-up scan?
- **Spot drift** (Bits AI): Show cloud misconfigurations from the last 30 days on resources that are also managed in Terraform, and tell me which fixes were later reverted.
- **Run the assessment with me** (Any agent): Read https://www.exposureobservatory.com/agent/assessment.json. Ask me the questions for the dependency CVE class one at a time, ask for evidence whenever I say yes, then score me using the rules in the file and tell me my phase and next moves.
- **Plan the next phase** (Any agent): Using the Exposure Observatory model at https://www.exposureobservatory.com/llms-full.txt: I'm at Phase 2 (Suggest) for identity risk. Draft a 90-day plan to pass the gate to Bounded apply, with owners, the evidence to collect, and the first control class to automate behind a feature flag.
- **Check my environment** (Any agent): From https://www.exposureobservatory.com/agent/ddsql.json, pick the DDSQL checks for CVEs and identity. Explain what each one finds, then help me run them in the Datadog DDSQL Editor and turn the results into a prioritized fix list.

## Glossary

- **Additive vs. subtractive** (also: additive, subtractive): An additive change turns something on (enable encryption); a subtractive one takes something away (remove a permission or a rule). Subtractive changes cause most outages.
- **Agent** (also: agents, agent, Agents): Software, usually built on a large language model, that takes actions toward a goal (here, finding and fixing exposures) instead of only answering questions.
- **Attack path** (also: attack-path, attack path, attack paths): A chain of steps an attacker could take from an entry point to something valuable. Fixing a choke point on a path can cut off many routes at once.
- **Base image** (also: base images, base image): The starting container image your application image is built on. Its vulnerabilities ship with every service built from it.
- **Blast radius** (also: blast-radius, blast radius): How much can break if a change goes wrong. Budgets cap how much an automation may touch at once.
- **Branch protection** (also: branch protection): Repository rules that block merging until required reviews and checks pass.
- **Choke point** (also: choke points, choke point): A single spot many attack paths pass through. A small share of exposures sit on choke points, which makes them high-value fixes.
- **Circuit breaker** (also: circuit breaker, circuit-breaker, breaker): An automatic stop that halts the automation when error or revert rates cross a threshold, and stays off until a person re-authorizes it.
- **Control plane** (also: control-plane, control plane): The cloud provider's management layer (consoles and APIs) where resources are created and configured.
- **Cooldown** (also: cooldown, cooldowns): A waiting period before adopting a brand-new package release, so a malicious "fix" release has time to be caught.
- **CVE** (also: CVEs): Common Vulnerabilities and Exposures: the public catalog of known software vulnerabilities, each with an ID like CVE-2021-44228.
- **CVSS**: Common Vulnerability Scoring System: a 0–10 severity score for a vulnerability. On its own it ignores your environment, so it over-ranks many findings.
- **DDSQL**: Datadog's SQL dialect (PostgreSQL-compatible) for querying infrastructure resources, security findings and telemetry in the DDSQL Editor.
- **DR**: Disaster recovery: the jobs and paths that only run during failover or recovery tests, often quarterly.
- **Drift** (also: drift): When live infrastructure no longer matches its code definition. A fix applied only to the live resource drifts back on the next deploy.
- **EPSS**: Exploit Prediction Scoring System: the estimated probability a CVE will be exploited in the next 30 days.
- **Evals** (also: evals): Repeatable tests that score an agent's behavior, for example against a held-out set of real fixes, re-run whenever the model, prompt or tools change.
- **Exploit re-run** (also: exploit re-run, exploit re-runs): Running the proof-of-vulnerability again after a fix. If the exploit no longer works, the gap is closed.
- **Exposure** (also: exposure, exposures, Exposures): A weakness an attacker can actually reach that matters to the business. CVEs, misconfigurations and identity problems are all exposures.
- **Exposure loop** (also: exposure loop, the loop): The continuous practice of assessing exposures, prioritizing them, fixing them, and verifying the fix closed the gap, then going around again.
- **False-accept rate** (also: false-accept rate, false-accept rates): How often a bad fix gets accepted as good. The number that matters most before letting anything merge unattended.
- **Feature flag** (also: feature flags, feature flag, flags, flag): A runtime switch that turns a change on or off without a redeploy. Shipping fixes behind flags makes a bad fix a toggle instead of an incident.
- **GitOps**: Running infrastructure from a Git repository, where a controller continuously makes the live environment match the repo. It will undo changes made outside Git.
- **IaC**: Infrastructure as code: defining cloud resources in files (Terraform, CloudFormation) so changes are reviewed and versioned like software.
- **IMDSv1**: The original AWS instance metadata service, which can leak credentials through server-side request forgery. IMDSv2 fixes this.
- **KEV**: CISA's Known Exploited Vulnerabilities catalog: CVEs with reliable evidence of exploitation in the wild. If it's on the KEV list, attackers are already using it.
- **Kill switch** (also: kill switch, kill-switch): A control that stops all automated changes immediately. It only counts if you've actually tripped it.
- **LLM judge** (also: LLM judges, AI reviewer): A language model asked to grade a patch. Useful for rejecting or ranking, but judges accept 17–22% of bad patches, so they shouldn't approve on their own.
- **MFA**: Multi-factor authentication: requiring a second proof of identity beyond a password.
- **Misconfiguration** (also: misconfigurations, misconfiguration, Misconfig): A resource set up insecurely, such as a public storage bucket or SSH open to the whole internet, rather than a bug in code.
- **No-new-access check** (also: no-new-access check): An automated comparison proving a changed identity policy grants no permissions the old one didn't, such as AWS IAM Access Analyzer's CheckNoNewAccess.
- **Permissions boundary** (also: permissions boundary, permission ceiling): A hard cap on what an identity can ever be allowed to do. An automation can't grant itself more than its boundary, even by editing its own policy.
- **Pinning** (also: pin by digest or SHA): Referencing a dependency or CI action by its exact content hash instead of a moving tag, so it can't change underneath you.
- **Plan diff** (also: plan diff): The list of changes Terraform (or similar) would make. Reading it confirms the fix changes what you think, rather than just silencing a scanner.
- **Progressive rollout** (also: progressive rollouts, progressive rollout, staged rollout, ramp): Releasing a change to a small slice first (an environment, a cohort, a percentage) and widening it only while health signals stay good.
- **Proof check** (also: proof check, proof checks): The test that proves a fix worked, such as a rescan, an exploit re-run, a plan diff or a no-new-access check. Research calls it an oracle. The thing doing the fixing must not be able to edit it.
- **Provenance** (also: provenance): A signed record of how a change was produced: which tool, model and version, what it was asked to do, and which checks it ran.
- **Rescan** (also: rescan): Scanning again after a fix lands. Closing a finding at rescan, not at merge, is what proves it's gone.
- **Residency** (also: residency): How long a phase has to run, with evidence, before you move on. One new control per residency window.
- **Runtime context** (also: runtime context): What's true about a finding in your running environment: is it reachable from the internet, in production, holding privileged access, with a public exploit? Context is what turns a long CVE list into a short one.
- **SCP**: Service control policy: an AWS Organizations guardrail that limits what any identity in an account can do.
- **Shadow mode** (also: shadow mode, in shadow): Running automation so it proposes fixes and logs them but applies nothing, so you can measure how often it would have been right.
- **SLO** (also: SLOs): Service level objective: a target for reliability, such as 99.9% of requests succeeding. Burning through it fast is a signal to roll back.
- **Tamper scan** (also: tamper scan, tamper-scan): A check that flags changes to tests, scanner settings or suppression comments, which are the usual ways automation games its own checks.
- **Tier 2 code** (also: Tier 2): High-risk code that always stays human-gated: auth, billing, IaC, identity policy, multi-file changes, and anything touching tests or CI.
- **Two-sided fix** (also: two-sided fixes, two-sided fix): Changing both the IaC definition and the live resource together, so the fix doesn't drift back.