Most teams prioritize patches by a severity score, then argue about the exceptions. CERT/CC’s SSVC takes a different route: it asks four questions about the vulnerability and your own systems, and a fixed lookup table returns a priority. This article explains the deployer version of that model, reproduces its full decision table so you can check it yourself, and shows how much of the answer CISA’s public CVE data can and cannot provide.

Scope and method. We read the CERT/CC SSVC documentation on October 18, 2026: the “Prioritizing Patch Deployment” page (the deployer model), and the reference pages for Human Impact, Safety Impact and Mission Impact. We extracted the 72-row decision table from the page and checked it programmatically (counts, completeness and consistency, described below). We also read the CISA Vulnrichment SSVC values and CISA Known Exploited Vulnerabilities (KEV) entries in six CVE records from the CVE Services API on October 18, 2026. The CERT/CC pages show no publication date, so we cite the read date. We did not test SSVC in a production vulnerability-management program, and this is research-based analysis, not firsthand operating experience. If you only want to read CISA’s own three values, see our Vulnrichment guide; this article covers the other decision a deployer faces.

The short answer

• Who it is for. The “deployer”: an organization that receives a patch or mitigation from a supplier and decides how fast to apply it to systems it runs. CERT/CC recommends the unit of work be the pairing of a remediation or mitigation with one product-version instance.
• Four inputs: Exploitation, System Exposure, Automatable, Human Impact.
• Four outputs: Defer, Scheduled, Out-of-cycle, Immediate.
• How many inputs you supply yourself: two (System Exposure and Human Impact). Exploitation and Automatable can come from public sources such as CISA’s data, if you accept them.

The four inputs

“PoC” means proof of concept. Note the definition of Controlled: CERT/CC says a successful mitigation must reliably interrupt the adversary’s attack, which requires that the attack be detectable both reliably and quickly enough to respond. A firewall rule nobody monitors does not necessarily qualify.

Human Impact: the lookup table

Human Impact combines Safety Impact (v2.0.1: Negligible, Marginal, Critical, Catastrophic, based on IEC 61508 with modifications) with Mission Impact (v2.0.0: Degraded, MEF Support Crippled, MEF Failure, Mission Failure). “MEF” means Mission Essential Function. This is the lookup table published on the Human Impact page:

A documentation inconsistency you should know about. The same page also gives prose definitions of each Human Impact level, and they do not match the table in four cells:

In addition, the prose does not mention Critical combined with MEF Failure at all, while the table gives High. We use the table, because it is the full 16-cell mapping and the prose definitions do not cover every combination. This is our judgment, not a CERT/CC statement. Before adopting the model, check which one your tooling implements, and check the current CERT/CC page, as this may be corrected.

The full decision table

This is the example decision table from the CERT/CC deployer page (identified there as ssvc:DT_DP:1.0.0), reorganized so each row shows the outcome for all four Human Impact levels. The original lists 72 rows (3 Exploitation values × 3 System Exposure values × 2 Automatable values × 4 Human Impact values); we confirmed that each of the 72 combinations appears exactly once.

What the table shows (our counts)

We counted outcomes across the 72 rows and checked the shape of the table:

• Active exploitation never yields Defer. This matches a note on the CERT/CC page.
• Immediate needs Active exploitation and Open exposure. All three Immediate rows are Active, Open and one of: Automatable No with Very High Human Impact, or Automatable Yes with High or Very High Human Impact.
• No exploitation evidence is mostly Defer or Scheduled. The one exception is None, Open, Automatable Yes and Very High Human Impact, which is Out-of-cycle. The CERT/CC page makes the same observation.
• The table is monotonic. We compared every pair of rows: raising any single input, with the others unchanged or also raised, never lowered the priority in the table (zero violations out of all comparable pairs).

What CISA’s public data can feed in

CISA’s Vulnrichment adds an SSVC block to many CVE records, with three decision points: Exploitation, Automatable and Technical Impact. Exploitation and Automatable share names with two deployer inputs. We read six records on October 18, 2026; values were stamped by CISA on the dates shown and could have changed since:

Three cautions apply before you reuse these as deployer inputs:

1. Definitions may differ. CISA labels its blocks with the role “CISA Coordinator” and tree version 2.0.3. We did not compare CISA’s decision-point versions against the deployer model’s versions line by line. The names and the value sets (none/poc/active; no/yes) match, but confirm before automating.
2. A timestamp is a snapshot. CVE-2026-105207 was marked none on October 6; “none” says no evidence at that time. Recheck KEV and the vendor advisory.
3. A missing block is missing data. No CISA block does not mean low risk. See the KEV feed guide for matching KEV to your inventory.

Technical Impact is part of CISA’s own tree but is not one of the deployer model’s four inputs. Do not feed it in as if it were.

Worked examples: same flaw, different answers

Suppose the affected product is running in your environment. We take Exploitation and Automatable from the table above, then show the full range of outcomes across your two inputs. All outcomes are read from the decision table.

More useful are the in-between cases. For CVE-2026-88771 (Active, Automatable Yes):

Read that second table carefully. An internet-facing instance (Open) supporting a function with Human Impact Medium is Out-of-cycle, not Immediate; the model reserves Immediate for High or Very High impact on an Open system. An instance with Controlled exposure is Out-of-cycle at every Human Impact level. This is the model’s output, not an endorsement of those timings for your organization.

For CVE-2026-102489 (Active, Automatable No) an Open system with Medium Human Impact is Out-of-cycle, and a Controlled system with Medium Human Impact is only Scheduled, even though the flaw is listed in KEV. That is the kind of result a severity score alone would not give you, and the kind a risk owner may want to override. SSVC does not stop you from doing so.

Using it in practice

1. Pre-assign Human Impact by asset class. Record, once, the Safety Impact and Mission Impact level for each class of system, then look up Human Impact in the table. Re-deciding it per CVE is where inconsistency creeps in.
2. Define Exposure per instance, not per product. The same product can be Open in one place and Small in another. Apply CERT/CC’s strict wording for Controlled.
3. Treat mitigations as input changes. CERT/CC says a mitigation that successfully changes a decision point can lower the priority; it also warns that mitigations can fail, for example a firewall rule that is later changed. If you rely on one, record who owns it.
4. Keep legal deadlines separate. Binding timelines, such as those in BOD 26-04 for federal agencies, are not the same thing as SSVC priorities.
5. Compare with your current method. Our comparison of CVSS, EPSS and KEV shows what each signal answers; SSVC’s deployer table consumes an exploitation signal and then adds your context.
6. Reassess when inputs change. CERT/CC says remediation is not a final state, because rollbacks or new deployments can reintroduce a vulnerability.

Limits of this article

• We read the CERT/CC example table; we did not read the underlying repository files or test CERT/CC’s calculator tool.
• The CERT/CC pages show no dates, so we cannot say when the table or the Human Impact inconsistency was last changed.
• The CVE examples assume the affected product is present in your environment and are not statements about any real organization.
• Values in live CVE records can change after October 18, 2026.
• The outcome names describe urgency, not a service-level agreement. CERT/CC does not give hour or day limits for them on the pages we read, so we give none.
• We did not evaluate how well SSVC performs compared with other methods.

Sources and verification

CERT/CC pages and CVE records read October 18, 2026.

A mutating admission policy answers a narrow question: when a request to create or update an object reaches the Kubernetes API server, should something in that object be changed before it is stored? Until recently the usual answer was a mutating webhook, which means running and securing a separate HTTPS service in the request path. MutatingAdmissionPolicy (MAP) moves the logic into the API server as declarative CEL expressions. This guide explains how it is built, what the documentation guarantees, and where you should still be careful.

Scope and method. This is research-based analysis of the Kubernetes v1.37 documentation, read on October 18, 2026: the Mutating Admission Policy page (last modified September 28, 2026), the MutatingAdmissionPolicy and MutatingAdmissionPolicyBinding API references (both last modified August 26, 2026), the Admission Controllers reference (last modified September 28, 2026) and the Dynamic Admission Control page. We did not run a Kubernetes cluster and did not test any policy against an API server. The only thing we ran ourselves is a check of generic JSON Patch behavior, described in the JSON Patch section and labelled there.

The short answer

• What it is. A declarative, in-process alternative to mutating admission webhooks. Mutations are written in the Common Expression Language (CEL), the small expression language Kubernetes uses for admission rules.
• Status. The Kubernetes documentation says it is stable since v1.36 and enabled by default, and first became available in v1.30.
• What you create. A MutatingAdmissionPolicy (the logic), a MutatingAdmissionPolicyBinding (the scope), and optionally a parameter resource (the values). At least a policy and a matching binding must exist for anything to happen.
• Where it runs. In the mutating phase of admission, before the validating phase.
• The catch. It is part of the control plane. The documentation says to write and deploy these policies “with great caution”.

The three resources

Two details are easy to miss. If a binding names a policy that does not exist, the API reference says the binding is “considered invalid and will be ignored”. If the policy declares a paramKind and the binding’s paramRef points to a resource that does not exist, the binding is treated as misconfigured and the policy’s failurePolicy applies. Also, per binding, the policy is evaluated once, or once per selected parameter object if parameters are used, and each evaluation has a runtime cost budget.

Which requests a policy sees

Matching is layered, and each layer can only narrow the previous one:

1. matchConstraints on the policy (required) selects resources and operations. The API reference says the operations CREATE, UPDATE and CONNECT are allowed and DELETE may not be matched.
2. matchResources on the binding narrows further. If it is unset, it does not constrain matching.
3. matchConditions on the policy are CEL expressions evaluated last. If any condition is false the policy is skipped; if none is false but one errors, failurePolicy decides. A policy may have at most 64 match conditions.

The documentation notes that namespaceObject is always null in match conditions and that variables cannot be used there, because match conditions are evaluated before the rest of the policy. To select by namespace labels, use a namespaceSelector in matchConstraints or in the binding’s matchResources.

One more limit that affects design: the documentation says that only apiVersion, kind, metadata.name, metadata.generateName and metadata.labels are accessible from the root of the object, and that no other metadata properties are accessible. A rule that depends on an annotation, for example, cannot read it through object. This is the documented behavior; we have not tested workarounds.

Two ways to express a mutation

Each entry in spec.mutations has a patchType, either ApplyConfiguration or JSONPatch.

ApplyConfiguration

The expression must evaluate to a CEL object created with Object{...}, and the result is merged using the server-side apply merge strategy. This is the Kubernetes documentation’s own example, which adds a mesh-proxy init container to new Pods that do not already have one:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: "sidecar-policy.example.com"
spec:
  paramKind:
    kind: Sidecar
    apiVersion: mutations.example.com/v1
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE"]
      resources:   ["pods"]
  matchConditions:
    - name: does-not-already-have-sidecar
      expression: "!object.spec.initContainers.exists(ic, ic.name == \"mesh-proxy\")"
  failurePolicy: Fail
  reinvocationPolicy: IfNeeded
  mutations:
    - patchType: "ApplyConfiguration"
      applyConfiguration:
        expression: >
          Object{
            spec: Object.spec{
              initContainers: [
                Object.spec.initContainers{
                  name: "mesh-proxy",
                  image: "mesh/proxy:v1.0.0",
                  args: ["proxy", "sidecar"],
                  restartPolicy: "Always"
                }
              ]
            }
          }          

The documented restriction to remember: apply configurations may not modify atomic structs, maps or arrays, because of the risk of accidentally deleting values the configuration does not mention.

JSONPatch

The expression must return an array of JSONPatch{op, path, value} values, following the JSON Patch format. The documentation’s examples include a conditional change using a test operation before a replace, and a helper, jsonpatch.escapeKey(), for path keys that contain / or ~. It escapes ~ as ~0 and / as ~1, so a label such as example.com/environment can be addressed.

Read the documentation’s two sidecar examples side by side. The page says the JSON Patch version writes “the same mutation”, but the two examples are not identical: the apply-configuration example uses the image mesh/proxy:v1.0.0 and sets args, while the JSON Patch example uses the image string mesh-proxy/v1.0.0 and no args. Treat them as illustrations of syntax, not as a verified equivalence, and do not copy the image reference from either.

What we tested about JSON Patch

On October 18, 2026 we ran a generic JSON Patch library (Python jsonpatch 1.35, an implementation of the RFC 6902 patch format) on small sample documents. This does not run the Kubernetes API server’s implementation, so it shows how the format behaves, not how your cluster will.

The practical lesson is that a positional JSON Patch needs the parent path to exist and the key to be escaped. The documentation’s sidecar example uses a match condition that reads object.spec.initContainers; whether that expression behaves well when the field is absent is something we did not verify and you should test. The Kubernetes documentation we read does not say what the API server does when a JSON Patch fails to apply, so do not assume it is silently skipped.

Reinvocation: why your mutation must be safe to repeat

reinvocationPolicy is a required field on the policy, with two values:

• Never: the mutations are not called more than once per binding in a single admission evaluation.
• IfNeeded: they may be called more than once per binding for a single admission request, only when other mutations changed the object after this one ran. The API reference states there is no guarantee of order relative to other admission plugins, webhooks, bindings of this policy and other admission policies.

The reason is explained on the Dynamic Admission Control page: no single ordering of mutating plugins works for every case, so mutating plugins can be re-run so that they see changes made by others. That page also states that mutating webhooks must be idempotent, meaning able to process an object they have already modified. Our reading is that the same discipline applies to a policy using IfNeeded, which is why the documentation’s example begins with a match condition that skips Pods that already have the mesh-proxy container. For comparison, the webhook field reinvocationPolicy defaults to Never.

Failure behavior

failurePolicy accepts Fail or Ignore and defaults to Fail. The API reference says failures can come from CEL parse errors, type-check errors, runtime errors, and invalid or misconfigured policy definitions or bindings, such as a paramKind that refers to a non-existent kind. It does not define how validations that evaluate to false are handled; that is a validation concept, not a mutation one.

For a control-plane component, the difference matters. With Fail, an error in your expression can reject writes to every object you matched. With Ignore, the same error means the mutation is silently not applied, and anything that depended on it, such as a validating rule that expects the label to be there, may then reject the object or let a bad one through. The Admission Controllers page says that if any MutatingAdmissionPolicy fails, the request fails.

How it fits with other admission mechanisms

The Admission Controllers reference says admission runs in two phases: mutating controllers first, then validating ones, and a rejection in either phase rejects the whole request.

• With Pod Security Admission. The reference lists the PodSecurity plugin as validating. Pods are therefore checked after mutation. See our guide to Pod Security Admission.
• With ValidatingAdmissionPolicy. A mutating policy can set a value that a validating policy then checks. Our ValidatingAdmissionPolicy guide covers the validating side, which has Deny, Warn and Audit actions that the MAP binding does not.
• With image signature checks. Verifying cosign signatures at admission is done by a webhook such as Sigstore’s policy-controller; see our guide to verifying signed container images in Kubernetes.
• With webhooks. Built-in mutating plugins are re-run if a mutating webhook modifies an object, per the Dynamic Admission Control page.

Exempt kinds

Policies created through the REST API cannot mutate ValidatingAdmissionPolicies, their bindings, MutatingAdmissionPolicies or their bindings. The documentation says a policy loaded through manifest-based admission control can intercept those kinds. Separately, the non-persisted authentication and authorization review kinds (TokenReviews, SelfSubjectReviews, LocalSubjectAccessReviews, SelfSubjectAccessReviews, SelfSubjectRulesReviews and SubjectAccessReviews) are exempt from all admission policies, and the page says that starting with Kubernetes v1.37 admission webhooks also exclude them by default.

MAP, VAP or webhook: a decision guide

This table is our summary of the documented capabilities, not a benchmark. We did not measure latency or reliability differences between policies and webhooks, and we make no claim about them.

A cautious rollout

The MAP binding has no Warn or Audit action, so you cannot trial a policy in a non-enforcing mode the way you can with a validating binding. Our suggestions, all untested by us:

1. Start in a throwaway cluster on the Kubernetes minor version you run, because the feature became stable in v1.36 and your cluster may be older.
2. Scope the binding narrowly with matchResources and a namespaceSelector. The kubernetes.io/metadata.name label that the API server sets on namespaces, as covered in our ValidatingAdmissionPolicy guide, gives you a name-based selector without labelling anything.
3. Make the mutation idempotent and put the “already done” check in matchConditions.
4. Decide on failurePolicy deliberately. Use Ignore while developing so a typo does not block writes, then switch to Fail once you have shown the mutation applies.
5. Re-read the resulting object, and verify that your validating rules and Pod Security levels still accept it.

Limits of this article

• We did not run a Kubernetes cluster, so no policy in this article was tested against an API server.
• The JSON Patch results come from a generic Python library, not from Kubernetes.
• We did not find, in the pages we read, statements about what happens when a JSON Patch fails to apply, or about the ordering of several mutating policies; we have not claimed any.
• The Admission Controllers page still describes the MutatingAdmissionPolicy plugin as needing the mutatingadmissionpolicy feature gate and the admissionregistration.k8s.io/v1alpha1 API group, while its default-plugin list for 1.37 includes it and the MAP page says stable and enabled by default. We follow the latter two and flag the inconsistency.
• Documentation changes. Re-check the pages below for your Kubernetes version.

Sources and verification

Documentation read October 18, 2026 (site version v1.37).

Kubernetes has a built-in way to reject a workload for breaking your rules, not just the generic ones: ValidatingAdmissionPolicy (VAP). You write a rule such as “every container image must start with registry.example.com/” in the Common Expression Language (CEL), and the API server evaluates it whenever a matching object is created or updated. There is no webhook server to run, patch or keep available. This guide explains the three resources involved, shows two worked rules, and gives a rollout order that does not break deployments on day one.

Scope. This is research-based analysis of the Kubernetes documentation pages listed under Sources and verification, read on October 17, 2026 (the site’s latest version is v1.37). We did not run a cluster. We did evaluate the CEL expressions below against sample Pod objects with the open-source cel-go library (version 0.32.0), which confirms the logic but is not the Kubernetes API server’s own CEL environment. Treat the manifests as untested drafts and try them in a non-production cluster first.

What VAP is, and where it sits

The Kubernetes Validating Admission Policy page describes validating admission policies as “a declarative, in-process alternative to validating admission webhooks”, using CEL to declare validation rules. The page marks the feature “Stable since Kubernetes v1.30”. An admission controller is a component that intercepts API requests after authentication and authorization and before the object is stored; the admission controllers reference lists ValidatingAdmissionPolicy among the plugins enabled by default in Kubernetes 1.37.

How it compares with the options you may already know:

PSA’s own documentation points to third-party engines for rules such as registry allowlists; see our Pod Security Admission guide. VAP is the built-in route for many of those rules.

The three resources

Per the docs, a policy generally has three parts:

• ValidatingAdmissionPolicy: the abstract logic and the resource types it applies to (matchConstraints).
• ValidatingAdmissionPolicyBinding: links a policy to a scope and chooses what happens on failure (validationActions). “At least a ValidatingAdmissionPolicy and a corresponding ValidatingAdmissionPolicyBinding must be defined for a policy to have an effect.”
• A parameter resource (optional): a ConfigMap or custom resource that supplies concrete values. The docs’ example is a ReplicaLimit resource with maxReplicas: 3 for test namespaces and another with maxReplicas: 100 for the rest, both used by the same policy through two bindings.

If you use no parameters, leave spec.paramKind unset.

Worked rule 1: image registry allowlist for Pods

Goal. Reject Pods in which any container or init container uses an image outside registry.example.com/. The registry name is a placeholder.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-registry.example.com
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  variables:
  - name: allContainers
    expression: >-
      object.spec.containers +
      (has(object.spec.initContainers) ? object.spec.initContainers : [])      
  validations:
  - expression: "variables.allContainers.all(c, c.image.startsWith('registry.example.com/'))"
    messageExpression: >-
      'images not from registry.example.com: ' +
      variables.allContainers.filter(c, !c.image.startsWith('registry.example.com/'))
        .map(c, c.image).join(', ')      
    reason: Forbidden

How to read it:

• variables are named sub-expressions, evaluated lazily, that later expressions reference as variables.<name>. The docs recommend them when an expression gets complicated or is reused.
• has(object.spec.initContainers) guards the optional field. The docs explain that CEL’s has() checks whether a field is present before the expression reads it.
• The trailing / in the prefix matters. registry.example.com.evil.net/app does not start with registry.example.com/, so a look-alike hostname fails the check. We confirmed this case in our cel-go run.
• messageExpression builds the denial message from the offending images. Per the docs, if the message expression fails to evaluate, the static message is used instead, and a multi-line result is discarded.
• reason: Forbidden is one of the four documented values (Unauthorized, Forbidden, Invalid, RequestEntityTooLarge). It sets the machine-readable reason and HTTP status of the first failing validation.

Our cel-go results (sample Pods, expression result): a Pod with only registry-prefixed images, with and without init containers, evaluated true; a Pod using docker.io/library/nginx:1 evaluated false; a Pod with a bad image only in an init container evaluated false; the look-alike hostname evaluated false.

What this rule does not cover:

• Ephemeral containers. They are added through a different API subresource that resources: ["pods"] does not match. We did not test how the API server handles them.
• Digest pinning and signatures. A prefix does not stop someone pushing a malicious image to your own registry. For that, see verifying signed images with policy-controller and what image scanning misses.
• Existing Pods on UPDATE. Because the policy matches UPDATE as well as CREATE, our reading (untested) is that editing an already-running Pod that violates the rule would also be evaluated. Drop UPDATE if you only want to gate new Pods.

Worked rule 2: every container needs a memory limit

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-memory-limit.example.com
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE"]
      resources:   ["pods"]
  validations:
  - expression: >-
      object.spec.containers.all(c,
        has(c.resources) && has(c.resources.limits) && 'memory' in c.resources.limits)      
    message: "every container must set resources.limits.memory"
    reason: Invalid

The docs’ advice for maps is to use the in operator to test whether a key exists, which is what 'memory' in c.resources.limits does. In our cel-go run, a container with a memory limit evaluated true; one with no resources block and one with only a CPU limit both evaluated false. This rule checks init containers only if you extend it the same way as rule 1. Be aware that a cluster may apply default limits through a LimitRange, in which case Pods may already carry limits by the time admission policies see them. We did not verify the ordering of those two mechanisms, so test this in your own cluster.

Bindings: scope and actions

A binding says where the policy applies and what a failure does. This one excludes the kube-system namespace and starts in observation mode:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-registry-binding.example.com
spec:
  policyName: allowed-registry.example.com
  validationActions: [Warn, Audit]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system"]

The Kubernetes well-known labels page says the API server sets kubernetes.io/metadata.name on all namespaces, with the namespace’s name as the value, and that it cannot be changed. That makes it a dependable selector. Whether kube-system should be excluded at all is your call; system components may use images from other registries.

The three actions, per the docs:

Deny and Warn “may not be used together”. Deny with Audit is therefore the production end state, and Warn with Audit is the observation state.

What happens when several policies or bindings apply

For each request, the API server evaluates every matching (policy, binding, parameter) combination, and the request is admitted only if all of them pass. The docs state that a policy may be evaluated several times if multiple bindings match, and that overlapping bindings are allowed. The practical effect: adding a second, stricter binding never loosens an existing one.

failurePolicy: the setting that can silently disable a rule

failurePolicy is set on the policy and governs errors in the policy itself, such as a misconfiguration or a CEL expression that errors at runtime. Fail (the default) rejects the request; Ignore lets it continue. Two consequences:

• Under Ignore, a broken expression enforces nothing and nobody is told. If you choose Ignore to avoid blocking deployments, watch for errors another way.
• Under Fail, a policy that errors on a field you did not guard with has() can block every matching request. This is why the Warn-first rollout below matters.

The docs also say a validation that simply evaluates to false is always enforced according to the binding’s actions, whatever failurePolicy says.

Catch mistakes before they run

• Type checking. When a policy is created or updated, expressions are parsed and syntax errors cause rejection. Referenced fields are then type-checked against the matched resource types, with results in status.typeChecking. Per the docs, type checking does not affect behavior, does not apply to custom resources, skips wildcard matches, and covers at most 10 matched types. Inspect it with kubectl get validatingadmissionpolicy <name> -o yaml after creation.
• Cost limits. The CEL in Kubernetes page says all expressions run under a runtime cost budget, and that the API server may reject expressions whose worst-case estimated cost is too high when they are written. Deeply nested all/filter loops over large lists are where you would run into this.
• matchConditions filter requests with CEL before the policy runs. Per the docs, namespaceObject is null in match conditions, so use a namespaceSelector to select by namespace labels. If any match condition is false, the policy is skipped; if a match condition errors and none is false, failurePolicy decides.

A rollout order

Our suggested order, built on the documented actions. We have not run it on a cluster.

1. Write the policy and a binding with [Warn, Audit], scoped to one non-production namespace.
2. Check status.typeChecking for the policy and fix any warnings.
3. Apply a known-good and a known-bad manifest in that namespace and confirm the client sees a warning for the bad one only. Look in the API server audit log for the validation-failure annotation (see the docs’ audit annotations section). Audit-log availability depends on your cluster’s audit policy.
4. Widen the namespace selector and let real deployments generate warnings for a period you choose. Fix or exempt what shows up.
5. Switch the binding to [Deny, Audit], one namespace group at a time.
6. Keep the policy in version control. The docs warn that “Validating Admission Policy is part of the cluster control-plane. You should write and deploy them with great caution.”

One more documented limit: policies created through the REST API cannot intercept ValidatingAdmissionPolicy or binding objects themselves, nor TokenReview-style authentication and authorization review kinds, which are exempt to avoid lock-out. So a user who can edit bindings can switch a policy off; guard that with RBAC.

Limits of this article

We did not run a Kubernetes cluster. The cel-go check uses generic dynamic types, not Kubernetes’ typed objects or its CEL environment, so a policy can pass our check and still draw a type-checking warning in a real cluster. We did not test how LimitRange defaults, ephemeral containers or UPDATE operations interact with these rules. Behavior may differ by Kubernetes version and by managed-service provider; the documented feature state is for v1.30 and later.

Sources and verification

Documentation read October 17, 2026. The Validating Admission Policy page shows “Last modified September 28, 2026”; the CEL page shows August 13, 2026.

Broken access control has held the top position in the OWASP Top 10 since the 2021 edition, and it’s the category with the most reported occurrences in OWASP’s own contributed testing data — over 318,000 recorded instances across the applications analyzed. That volume isn’t because it’s one specific bug pattern; it’s because “broken access control” covers several distinct ways authorization checks fail, each common enough on its own to matter.

Insecure direct object references (IDOR)

The most familiar pattern: an application exposes a reference to an internal object — an order ID, a document ID, a user ID — directly in a URL or request parameter, and fails to verify that the requesting user is actually authorized to access that specific object. Changing /invoices/1024 to /invoices/1025 and getting another customer’s invoice back is the canonical example. This happens because authentication (confirming who’s logged in) gets implemented and tested thoroughly, while object-level authorization (confirming that specific logged-in user is allowed to see that specific object) gets assumed rather than explicitly checked on every request.

Missing function-level access control

Distinct from IDOR: this is when an application correctly restricts what’s shown in the UI for a given role, but doesn’t enforce the same restriction on the backend endpoint itself. A standard user who can’t see an admin panel in the interface can often still call the admin API endpoint directly if the endpoint itself doesn’t independently verify the caller’s role — the UI hid the button, but nothing stopped the request. Any access control decision made only in frontend code is not actually an access control decision.

Privilege escalation, vertical and horizontal

Vertical escalation is a standard user gaining admin-level capability — often through the function-level gap above, or through a parameter that controls role or permission level and isn’t validated server-side (a request body that includes "role": "admin" and gets trusted rather than ignored). Horizontal escalation is accessing another user’s data at the same privilege level — which is effectively IDOR viewed through a different lens, since both involve one user reaching resources that belong to another.

CORS misconfiguration as an access control failure

A permissive CORS policy — particularly one that reflects an arbitrary request origin back as trusted, combined with credentialed requests — effectively extends your access control boundary to any site that can get a victim to load it, since the browser will now let that third-party origin make authenticated requests on the victim’s behalf. This is access control failing at the browser trust boundary rather than the server logic, but it belongs in the same category because the end result is the same: someone accessing something they shouldn’t.

Why this keeps happening

Authentication has mature, well-tested standard patterns that most frameworks handle reasonably well by default. Object and function-level authorization is inherently application-specific — the framework can’t know on its own whether the currently authenticated user should be allowed to see order #1025, because that depends entirely on your data model and business logic. This means authorization checks have to be deliberately written for each resource type and each endpoint, and any one that’s missed is a gap, not a framework misconfiguration you can patch centrally.

How to actually prevent it

Deny by default, allow explicitly. Every endpoint and every resource access should require an explicit authorization check to succeed, rather than being open unless something blocks it. This flips the failure mode from “silently overexposed” to “loudly broken,” which is far easier to catch in testing.

Enforce authorization server-side, every time, regardless of what the client already checked. Never trust a client-supplied value (a role field, a permission flag) without independently verifying it against the actual authenticated identity’s real permissions on the server.

Test authorization explicitly, not just authentication. A test suite that confirms “unauthenticated users are rejected” but never confirms “user A cannot access user B’s resources” is testing less than half of what actually matters here. Include this as its own category of test, per resource type, not an afterthought bundled into general functional testing.

Centralize authorization logic where possible. Scattering ad hoc permission checks across individual route handlers makes it easy for one to be forgotten. A centralized authorization layer or middleware that every request passes through, with each route declaring what it requires, reduces how many places the check has to be independently remembered and correctly implemented.

Broken access control isn’t a single vulnerability to patch. It’s a category that requires deliberate, per-resource enforcement — which is exactly why it remains the most common category in real-world findings even after years at the top of the list.

Many Kubernetes clusters run workloads that could mount the host filesystem, share the host network or run as root, simply because nothing told the API server not to allow it. Pod Security Admission (PSA) is the built-in answer: a check that runs when a pod is created and compares its settings with a named standard. This guide explains how it works and gives an order of operations that avoids breaking deployments.

Scope. This is research-based analysis of the official Kubernetes documentation as published for v1.37 on October 15, 2026 (the site’s configured latest version). We did not run a cluster for this article; the manifests and commands below are taken from, or built from, the documentation and are untested by us. If you run an older Kubernetes version, read that version’s docs: some controls carry version markers, such as host probes, which the docs tag “v1.34+”.

What PSA is and where it sits

The Pod Security Admission documentation describes a built-in admission controller, a component that inspects API requests after authentication and authorization and before objects are stored, and enforces the Pod Security Standards. Restrictions are applied at the namespace level when pods are created. The admission controllers reference lists it as a validating controller, meaning it can accept or reject a request but not modify it.

Two practical consequences follow:

• It looks only at the pod specification. It does not check which image is running, whether the image is signed (see our guide to verifying signed images with policy-controller), whether the image is vulnerable (what scanning misses), or what network and RBAC permissions the pod has.
• It offers three fixed levels and no custom rules. If you need, for instance, an allowlist of registries, the Kubernetes docs point to third-party tools such as Kubewarden, Kyverno and OPA Gatekeeper, and say that using any of them is better than doing nothing.

The three levels

The standards are cumulative, from permissive to restrictive:

What restricted adds on top of baseline

From the Pod Security Standards page for this version:

Baseline itself also restricts, among other things, hostPort (the built-in controller does not support the docs’ “known list” option, so effectively no host ports), the SELinux type and the AppArmor profile type. Read the full tables before choosing a level for workloads such as node agents or ingress controllers, which often need exceptions.

The three modes and the labels that control them

A namespace opts in with labels. The docs define the modes this way:

For each mode there are two labels:

pod-security.kubernetes.io/<MODE>: <LEVEL>          # privileged | baseline | restricted
pod-security.kubernetes.io/<MODE>-version: <VERSION> # a Kubernetes minor version such as v1.37, or latest

A namespace may set any or all modes, at different levels. The version label pins the rules to those that shipped with a given Kubernetes minor version. The docs’ own example pins to the current version, v1.37. Pinning avoids a surprise when a cluster upgrade tightens a level, while latest always tracks the running version. The docs suggest a useful pattern: keep enforce pinned and set audit and warn to the same level at latest, which surfaces settings that older rules allowed but current best practice does not.

Here is the docs’ example, which blocks pods failing baseline and warns about, and audits, anything failing restricted:

apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.37
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.37
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.37

Unlabeled namespaces default to privileged

This is the most common misunderstanding. The admission controller configuration page shows cluster-wide defaults applied “when a mode label is not set,” and lists privileged as the default level for each mode and latest as the default version. So a namespace with no labels is, by default, unrestricted, unless an administrator changed it. The “Enforcing Pod Security Standards” page calls namespaces lacking any configuration “significant gaps in your cluster security model” and suggests treating them as “yet to be evaluated.”

Cluster defaults and exemptions are set through an AdmissionConfiguration file passed to the API server with --admission-control-config-file. On managed Kubernetes services you may not control API server flags; we did not check any provider’s options.

Pods versus Deployments: where enforcement happens

Pods are usually created indirectly, by a controller acting on a Deployment or Job template. The docs state that audit and warn modes apply to those workload resources too, “to help catch violations early,” but that enforce mode is not applied to workload resources, only to the resulting pod objects.

Our reading, which we have not tested: a Deployment that violates an enforced level can be accepted by the API server while its pods are then refused, so the failure appears as missing pods rather than a rejected kubectl apply. If you see a Deployment with zero ready replicas after labeling a namespace, look at the events on its ReplicaSet. Having warn set at the same level gives the person applying the manifest an immediate message.

Exemptions, and the one that backfires

PSA can skip checks by exempting usernames, runtime class names or entire namespaces. Exempted requests are ignored entirely, with all three modes skipped. The documentation adds a caution: most pods are created by controllers, so exempting an end user exempts them only when creating pods directly, not when creating workload resources; and controller service accounts such as system:serviceaccount:kube-system:replicaset-controller “should generally not be exempted,” because that would implicitly exempt anyone who can create the corresponding workload.

Separately, updates that change only certain fields are not rechecked, so an already-running violating pod can still receive those updates: metadata changes (except seccomp or AppArmor annotations), valid updates to .spec.activeDeadlineSeconds, and valid updates to .spec.tolerations.

A rollout that follows the Kubernetes guidance

Apply this order, adapted from the namespace labels task and the enforcement best practices:

1. Inventory. Find namespaces with no enforce label (the docs’ command):

   kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'
   

2. Turn on visibility, not blocking. The docs’ suggested first step for all namespaces:

   kubectl label --overwrite ns --all \
     pod-security.kubernetes.io/audit=baseline \
     pod-security.kubernetes.io/warn=baseline
   

   The docs deliberately leave enforce unset so that unevaluated namespaces remain distinguishable. Collect the warnings and audit annotations, then set the target level per namespace. In the docs’ words: “set to the desired level and version you would eventually like to enforce.”
3. Dry-run the enforce label. The docs’ server-side dry run shows how the new level would treat existing pods without changing anything:

   kubectl label --dry-run=server --overwrite ns --all \
     pod-security.kubernetes.io/enforce=baseline
   

   The docs note that when an enforce label is added or changed, the admission plugin tests every pod in the namespace and returns violations as warnings.
4. Enforce namespace by namespace, pinned to a version:

   kubectl label --overwrite ns my-existing-namespace \
     pod-security.kubernetes.io/enforce=restricted \
     pod-security.kubernetes.io/enforce-version=v1.37
   

5. Keep warn and audit on at the same level as enforce so authors get feedback.
6. Put privileged workloads in their own namespaces and document why, as the docs advise: namespaces allowing privileged workloads “should establish and enforce appropriate access controls.”

Also consider monitoring. The kube-apiserver exposes pod_security_evaluations_total, pod_security_exemptions_total and pod_security_errors_total. The docs warn that non-fatal evaluation errors “may result in the latest restricted profile being used for enforcement,” so a rise in errors is worth an alert.

An example pod that should satisfy restricted

We built this from the controls above; we have not run it against a cluster. The image name is a placeholder, and your image must really be able to run as a non-root user, otherwise the container will start and then fail.

apiVersion: v1
kind: Pod
metadata:
  name: restricted-example
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: registry.example.com/team/app:1.0.0   # placeholder
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

Check against the table: emptyDir is an allowed volume type; allowPrivilegeEscalation is false; runAsNonRoot is true at pod level, which the docs permit in place of per-container values; seccomp is RuntimeDefault at pod level; ALL capabilities are dropped and none are added. The usual failure causes when you move an existing workload to restricted are a missing seccomp profile, a missing drop: ["ALL"], an image whose default user is root, and a volume type outside the allowed list such as hostPath.

Where PSA is not enough

• Windows pods. Several restricted controls (privilege escalation, seccomp, Linux capabilities) apply only when spec.os.name is not windows, and the docs warn that clusters containing nodes older than v1.24 should pin restricted policies to a version before v1.25.
• Policy beyond pod fields. Registry allowlists, required labels, resource limits and image signatures need another policy engine.
• Pods that need privilege. Node-level agents and some storage or networking components legitimately need privileged; isolate them rather than weakening everything.
• Detection. PSA reduces what can be created; it does not tell you what already runs. Pair it with the practices in our cloud misconfiguration guide and identity hygiene from least privilege without slowing teams.

Limits of this article

We did not run any of the commands or manifests. We read the Kubernetes documentation source for the v1.37 site on October 15, 2026; older and newer versions may differ, and we did not check any managed Kubernetes provider’s behavior. The statement about where enforce failures surface for Deployments is our inference from the documented scope of enforce mode.

Sources and verification

Checked on October 15, 2026, against the Kubernetes documentation source (kubernetes/website, main branch; site latest version v1.37).

If a CVE record has been analyzed by CISA, it contains three small fields that answer a triage question faster than most advisories do: is this being exploited, can attackers automate it, and what do they get if it works. They sit inside the record under CISA’s Authorized Data Publisher (ADP) container, and you can read them with one curl and one jq command. This article shows where the fields are, what each value means, what the data cannot tell you, and how CISA’s own decision table converts the three values plus one input from you into one of four actions.

We read CISA’s Vulnrichment README and flowcharts, the SSVC project’s definitions of the decision points, and CISA’s published decision tree file, and we ran the commands below against the live CVE Services API on October 14, 2026. This is research-based explanation plus our own command-line checks of public records; we did not scan any systems.

The short answer

• What it is: CISA’s Vulnrichment project enriches public CVE records. For each CVE CISA analyzes it adds three SSVC (Stakeholder-Specific Vulnerability Categorization) decision points: Exploitation, Automatable and Technical Impact. For some it also adds a CWE weakness identifier or a CVSS score.
• Where to read it: the adp array in the CVE record, in the entry whose providerMetadata.shortName is CISA-ADP.
• What to do with it: combine it with your own exposure and asset criticality. CISA’s decision table needs a fourth input, which only you can supply.

Where the data lives

A CVE record in the CVE Record Format has a CNA container, written by the organization that assigned the CVE, and zero or more ADP containers, written by other authorized publishers. CISA’s README says CISA never overwrites the CNA’s data in the CNA container; it writes its additions to its own ADP container.

You can fetch any record from the CVE Services API and filter for CISA’s entry. This is the command we ran (it needs curl and jq):

curl -s https://cveawg.mitre.org/api/cve/CVE-2024-4947 | jq '[
  .containers.adp[]?
  | select(.providerMetadata.shortName == "CISA-ADP")
  | .metrics[]?
  | select(.other.type == "ssvc")
  | .other.content
  | {version, timestamp, options: (.options | add)}
]'

On October 14, 2026 it returned, for CVE-2024-4947:

[
  {
    "version": "2.0.3",
    "timestamp": "2024-05-23T20:01:07.846921Z",
    "options": {
      "Exploitation": "active",
      "Automatable": "no",
      "Technical Impact": "total"
    }
  }
]

If CISA has not analyzed a CVE, the command returns []. Replace "ssvc" with "kev" and .other.content with .other.content.dateAdded to read the date CISA’s ADP container recorded the CVE being added to the Known Exploited Vulnerabilities (KEV) catalog; for CVE-2024-4947 that was 2024-05-20.

Two fields deserve attention:

• timestamp is when CISA produced that SSVC result. The record above is from May 2024. Exploitation can change after that date.
• version follows a major.minor.patch pattern. CISA’s README says major.minor is the SSVC version and the patch number is the version of CISA’s decision tree, so 2.0.3 means SSVC 2.0 and CISA Coordinator tree version 3. The README asks consumers to check this before validating or processing the JSON.

What the three values mean

Some details change how you should read them:

• Exploitation is present-tense, not predictive. The SSVC documentation says it measures current exploitation, not predicted future exploitation, and points to predictive systems such as EPSS for that. A none value means no exploitation evidence at the time of analysis, not that exploitation will not happen.
• The definitions of poc differ between versions. The SSVC project says Exploitation version 1.0.0 also counted privately attested exploitation and widespread hearsay under poc; version 1.1.0 limits it to public PoCs and well-known methods. CISA’s Coordinator tree file we read (v2.0.3) still carries the broader 1.0.0-style wording. Treat poc as “exploit knowledge exists”, not as a measured exploit-development effort.
• Automatable defaults to yes. The SSVC documentation says that if nothing is known, assume Yes, and that remote code execution or command injection should generally be scored Yes. Reasons for No include a component that is not discoverable on the network, weaponization that needs manual work per target, delivery blocked by common network controls, or exploit-prevention features that make exploitation unreliable.
• Technical Impact is relative to the vulnerable component. The SSVC documentation says control is judged relative to the affected component where the flaw resides. It does not describe how much of your network the attacker then reaches.

How CISA picks which CVEs get more data

CISA’s README says that CVEs rated Total Technical Impact, Automatable, or with Exploitation poc or active get further analysis for a CWE identifier and a CVSS score, where there is enough information, and that CISA may provide those even for lower-rated CVEs. The README also says that if the CNA later provides its own CWE, CVSS or CPE data, CISA removes its own, and if both exist the CNA’s data takes precedence. As of December 10, 2024, CISA no longer adds CPE strings.

Four records, four profiles

We pulled these records from the CVE Services API on October 14, 2026. The three values are as CISA recorded them at the timestamp shown.

CVE-2024-25522 shows why you need more than one field. CISA’s ADP container also carries a CVSS v3.1 base score of 9.4 for it (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), yet its SSVC profile is only poc, with no exploitation evidence. A near-critical severity score and an unexploited status can coexist; they answer different questions. Our companion article on CVSS, EPSS and KEV covers how to combine them.

For records published in September 2026, the same command returned active / yes / total for CVE-2026-76504 (KEV block dated 2026-09-30, and covered in our Cisco SD-WAN Manager article) and for CVE-2026-88771 (KEV block dated 2026-09-27, covered in our NetScaler article).

From three values to a decision

CISA’s SSVC page says its tree uses five decision points (exploitation status, technical impact, automatable, mission prevalence and public well-being impact) and ends in one of four outcomes. It describes them as follows:

Vulnrichment fills in three of the five. The other two, Mission Prevalence and Public Well-being Impact, are combined in CISA’s tree file into a single input called Mission and Well-being, with three values:

• Low: Mission Prevalence is Minimal and Public Well-being Impact is Minimal.
• Medium: Mission Prevalence is Support and Public Well-being is Minimal or Material, or Mission Prevalence is Minimal or Support and Public Well-being is Material.
• High: Mission Prevalence is Essential, or Public Well-being Impact is Irreversible.

Our reading, not stated in the README, is that these two are left out of the public record because they depend on who you are and what the component does in your environment, which a public CVE record cannot know.

CISA’s tree file lists all 36 combinations. The table below is the full result for the three Vulnrichment values and each Mission and Well-being level. We extracted it directly from the file (CISA-Coordinator.json, title “CISA Coordinator v2.0.3”) and checked that each of the 12 combinations has exactly one outcome per level.

Applying it to the records above:

• CVE-2024-4947 (active / no / total): Track if the affected software is of minimal mission relevance to you, Attend at medium, Act at high.
• CVE-2024-25522 (poc / yes / total): Track at low, Track* at medium, Attend at high. Despite the 9.4 CVSS score, the tree does not send it to Act at any level.
• CVE-2024-34974 (none / yes / partial): Track at low and medium, Attend at high.
• CVE-2021-44228 (active / yes / total): Attend at low, Act at medium and high.

Two cautions on this table. First, it uses a data file from the CERT/CC SSVC repository’s main branch, which the Vulnrichment README links as the tree CISA currently uses; a newer tree version would change both the version string in records and possibly the table. Second, “Track” in the tree is not “never patch”: CISA’s description says remediation still follows standard update timelines.

How to use this without over-trusting it

1. Read the timestamp first. A May 2024 none for Exploitation says nothing about October 2026. Cross-check the KEV feed and the vendor advisory.
2. Treat a missing block as missing data. CISA’s README describes Vulnrichment as covering new and recent CVEs that CISA assesses. No CISA-ADP entry means no CISA SSVC result, not low risk.
3. Decide your Mission and Well-being input per asset class, once. Write down which systems are Minimal, Support or Essential for your organization, so triage does not reopen the question for every CVE. That classification is yours; CISA’s data cannot supply it.
4. Keep your own exposure facts separate. The tree does not know whether the vulnerable service is reachable from the internet in your environment. An internet-facing instance can justify a faster timeline than the table’s output.
5. Do not confuse SSVC outcomes with legal deadlines. Our BOD 26-04 explainer covers the KEV deadlines that bind federal agencies. SSVC’s Track, Attend and Act are decision aids, not deadlines.

Limits of this article

• We ran read-only queries against public records and read documentation; we did not test any automation at scale or measure how complete Vulnrichment coverage is.
• The records in the tables are examples chosen to show different profiles, not a statistical sample.
• Values in live records can change; the numbers above are as of October 14, 2026.
• We did not read CISA’s separate SSVC Guide PDF, so the tree logic is taken from the published JSON file rather than from CISA’s prose explanation.

Sources and verification

If you work for a U.S. federal civilian agency, Binding Operational Directive 26-04 (BOD 26-04) sets how fast you must fix known exploited vulnerabilities. If you do not, it still matters, because CISA’s Known Exploited Vulnerabilities (KEV) catalog entries now carry its deadlines and its forensic-triage language, and many private teams use KEV as a patching signal. This article explains what the directive says, what we could and could not verify, and which parts transfer to organizations it does not bind.

We read CISA’s directive page, CISA’s implementation guidance page, the KEV catalog and National Vulnerability Database (NVD) records on October 12, 2026. This is research-based analysis; we did not test any system.

What BOD 26-04 is and who it covers

Source: CISA, BOD 26-04.

The four inputs that set the deadline

Instead of one deadline for every KEV entry, the directive uses a table (Table 1, Appendix A) with four yes/no style decision points, measured in calendar days:

1. KEV status: is the vulnerability in the KEV catalog?
2. Publicly exposed: is the asset reachable by unauthenticated or untrusted parties over public networks, wherever it physically sits? If several methods are used and any finds the asset exposed, the value is “yes.”
3. Automatable: can exploitation be scripted reliably? CISA’s heuristic: if a public proof-of-concept achieves remote code execution and reliably runs against a vulnerable system, it is automatable. CISA publishes results through its Vulnrichment Program.
4. Technical impact: total if the attacker can run arbitrary software, trigger all actions of the component, get a full-privilege account, or both CVSS confidentiality and integrity impacts are High; otherwise partial. Denial of service generally counts as partial.

The clock starts at whichever comes first: CISA adding the CVE to KEV, or the agency identifying the vulnerability on an asset and updating its Continuous Diagnostics and Mitigation (CDM) dashboard. Timelines are dynamic: removing an asset from public exposure can lengthen its deadline, and a KEV addition shortens it.

What the deadlines actually are

This is where we must be careful. CISA’s text states that where the table says “& forensic triage,” the agency must remediate or mitigate within three days and also perform forensic triage. The page also describes “fix on system upgrade” for lower-risk cases. The individual day counts for every row are in an image of Table 1 that our reading tool could not extract, so we have not verified them against CISA’s own table.

For orientation only, Tenable’s secondary summary describes tiers of 3 days with triage, 3 days without triage, 14 days, 60 days and fix-on-upgrade. Treat that as a pointer, and read Appendix A on CISA’s site before relying on a specific number.

Phase dates

The directive phases its requirements. Phase I applies immediately; Phase II within 60 days of issuance; Phase III within 180 days.

The dates in the last column are our arithmetic from the page date. The directive measures from issuance, and we found no separate issuance date, so treat them as approximate. On that count, Phase III had not yet begun as of October 12, 2026.

Case study: five old CVEs added on October 8, 2026

The KEV catalog lists five entries added on 2026-10-08, each with a due date of 2026-10-11. Each entry’s required action refers to BOD 26-04 and CISA’s “Forensics Triage Requirements,” but the catalog’s forensic-triage field is not the same for all five: it is marked “Yes” for four and “No” for the BIND denial-of-service flaw, CVE-2015-5477.

Sources: CISA KEV catalog and the NVD records (CVE-2015-3306, CVE-2021-3199, CVE-2023-22894, CVE-2016-3081, CVE-2015-5477). The scores are the CVSS v3.1 scores CISA added to each CVE record (its “ADP” enrichment), as updated on October 9, 2026; NIST’s own NVD analysis has scored only the Strapi entry, at 4.9, and shows no v3.1 score for the BIND entry. Scores may change.

What this shows, and what it does not:

• Age is not safety. These flaws date from 2015 to 2023, yet were added with a three-day due date. The three-day interval is what the catalog and NVD show; we cannot tell from public data which row of Table 1 applies to any agency’s asset, since that depends on exposure.
• CVSS and KEV answer different questions. The Strapi entry has an NVD base score of 4.9 yet is in KEV. Our guide to CVSS, EPSS and KEV explains why exploitation evidence outranks severity.
• We do not know how or by whom these were exploited. The catalog entries we read do not say, and we have not assumed it.
• Dates differ by product version. If you run any of these products, check your exact version against the NVD affected ranges and your vendor’s fixes; backported distribution patches can change the answer.

Forensic triage: what “three days” includes

CISA’s implementation guidance presents baseline steps as best practice, and says the directive requires an adequate triage but not these specific timings. If a KEV entry has its own triage steps, those take precedence.

The ordering matters: evidence is collected before remediation where possible, because patching can destroy the traces you need.

What non-federal teams can borrow

The directive does not bind you, so these are our suggestions, not requirements.

1. Make exposure a first-class input. Tag assets by environment, exposure and type, as the directive’s Phase III tagging requires, so “is it internet-reachable?” is a query rather than a meeting.
2. Treat KEV as a trigger for compromise checks, not only patching. An exploited flaw that was exposed before you patched may already have been used. Compare with how we handled recent zero-day roundups and the Cisco SD-WAN log checks.
3. Rehearse the 72 hours. Decide who runs scoping, where evidence goes and how you communicate if email is suspect. Our piece on why vulnerability backlogs never shrink covers the process side.
4. Inventory old software. The October 8 batch is a reminder that forgotten FTP daemons, unpatched Struts apps and DNS servers can matter. If you cannot list them, you cannot fix them.
5. Know your response to a zero-day before one lands: see what to do when a zero-day is announced.

Limits of this article

We could not read Table 1 as text and have not verified individual day counts beyond the three-day forensic triage requirement. We did not find a separate issuance date, so the phase dates are approximate. We did not verify whether any of the five products is exploited in a particular environment, nor the exploitation details behind the KEV additions. We did not review agencies’ compliance with the directive.

Sources and verification

Checked on October 12, 2026.

Correction

October 12, 2026: An earlier version of this article described the CVSS v3.1 scores in the KEV table as “listed in NVD”. They are CISA’s enrichment (ADP) scores in the CVE records, not NIST’s own NVD scores. It also said every entry added on October 8 was marked for forensic triage; CVE-2015-5477 (BIND) is not. Both points have been corrected.

Check the CISA Known Exploited Vulnerabilities (KEV) catalog first, then EPSS, then CVSS, and apply your own knowledge of exposure at every step. KEV tells you a flaw has been exploited. EPSS estimates how likely exploitation is when you have no such evidence. CVSS tells you how bad exploitation would be. Using any one of them alone produces a predictable failure, and seven flaws from the past two weeks show each failure clearly.

This article explains what each signal measures, tests them against those seven flaws, and gives an order of operations you can implement.

What each one measures

CVSS: severity, not risk

The CVSS v4.0 specification describes the base score as reflecting a vulnerability’s severity according to intrinsic characteristics that stay constant over time. It covers things like whether the flaw is reachable over a network, whether the attacker needs an account, and what happens to confidentiality, integrity and availability.

The qualitative labels map to score ranges: Low is 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.

CVSS v4.0 has three other metric groups that most published scores leave empty:

• Threat metrics, mainly Exploit Maturity, which can be set to Attacked, Proof-of-Concept or Unreported.
• Environmental metrics, which adjust for your own controls and how much the affected system matters to you.
• Supplemental metrics, which add context without changing the score.

The specification names scores by which groups were used: CVSS-B is base only, CVSS-BT adds Threat, CVSS-BE adds Environmental and CVSS-BTE uses all three. It expects vendors and analysts to supply base metrics and the consuming organization to supply Threat and Environmental ones. In practice, the number in an advisory or scanner report is almost always CVSS-B, which is the general-case severity and nothing more.

Two scoring versions are in circulation. Among the flaws discussed below, Cisco and Fortinet published CVSS 3.1 scores and Citrix published CVSS 4.0 scores. The two versions are calculated differently, so treat a 9.8 on one and a 9.5 on the other as “both Critical”, not as a ranking.

EPSS: likelihood, with a time window

FIRST’s FAQ defines EPSS as “a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days.” Three details matter when you read a score:

• It is a probability. A score of 0.02 means an estimated 2% chance of observed exploitation activity in the next 30 days.
• The percentile is a ranking, not a probability. A percentile of 0.82 means the score is higher than 82% of all scored CVEs. Because most CVEs have very low scores, a high percentile can sit on top of a small probability. When we queried the API on October 7, 2026, it reported about 383,000 scored CVEs.
• “Exploitation activity” means attempts. FIRST’s model description defines it as evidence that exploitation was attempted, not that it succeeded, and says the data comes from sources such as honeypots, intrusion detection sensors and host-based detection.

Scores are republished every day, typically just after 13:30 UTC according to the FAQ.

FIRST is direct about the limits. The FAQ says “EPSS is not a complete risk score”, that it does not measure how much damage exploitation would cause or whether a flaw affects your environment, and that “multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea.”

KEV: evidence, not prediction

CISA adds a vulnerability to the catalog when three conditions are met: it has a CVE ID, “there is reliable evidence that the vulnerability has been actively exploited in the wild”, and “there is a clear remediation action for the vulnerability, such as a vendor-provided update.”

CISA’s definition of exploitation is specific. Scanning, security research on an exploit and the existence of a proof of concept do not count. Attempted exploitation, including against a honeypot, does.

As of catalog version 2026.10.04, the catalog held 1,734 entries, of which 250 were added in 2026. It flags 361 entries, about 21%, as known to be used in ransomware campaigns.

What a listing does not tell you is how widespread exploitation is, or whether you are a likely target. And the criteria imply two gaps, which is our reading rather than CISA’s wording: a flaw can be exploited before CISA has reliable evidence of it, and a flaw with no clear remediation does not meet the third criterion. Absence from KEV means “no listing”, not “not exploited”.

A fourth signal you already have: CISA’s SSVC values

SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision-tree method that CISA says was created in 2019. CISA’s version uses five decision points, including exploitation status, technical impact and whether exploitation is automatable, and ends in one of four outcomes: Track, Track*, Attend or Act.

The useful part for day-to-day triage is that CISA publishes three of those values inside many public CVE records: Exploitation (none, proof of concept or active), Automatable (yes or no) and Technical Impact (partial or total). Automatable asks whether an attacker can reliably automate creating exploitation events for the vulnerability, in the wording of the SSVC project’s documentation. A flaw marked active, automatable and total impact is the kind that gets sprayed across the internet.

Seven exploited flaws, three signals

We covered seven flaws that CISA added to KEV between September 27 and October 4, 2026. The table puts their published CVSS base scores next to their EPSS scores for October 6, 2026 and CISA’s Automatable value.

EPSS values are rounded from the API’s figures, which run from 0.00592 to 0.02201. The Zammad records also carry a second score of 9.4 for the two flaws chained together.

What each signal would have done on its own:

• EPSS alone would have missed all seven. Every score is at or below 2.2%. A team that acts on EPSS of 10% or higher, a commonly used cut-off, would have flagged none of them. Even a team working by percentile and taking the top 10% of CVEs would have flagged none, since the highest sits at the 82nd percentile.
• CVSS “Critical only” would have missed three. Four of the seven score 9.0 or higher. The two Zammad flaws and the NetScaler denial-of-service flaw score 8.5 to 8.7, which is High. A rule of 7.0 and above catches all seven, but that rule also puts every High and Critical flaw in your inventory into the same urgent queue, which is the backlog problem in the first place.
• KEV caught all seven, by construction. We picked these because they were listed. That is the point of the comparison, not a flaw in it: for a flaw with exploitation evidence, the evidence is the signal.

This is not a criticism of EPSS, and seven flaws are not a statistical sample. EPSS is doing what FIRST says it does. Its FAQ states that the model generates scores “without knowing if the vulnerability was recently exploited” and that “if direct evidence of active exploitation exists, that evidence should supersede EPSS.” These were newly disclosed flaws: CISA added all seven to KEV within two days of their CVE records being published. That is the situation where a model built on broad observation has the least to work with, which is our interpretation, not a statement from FIRST.

The mistake would be on the reader’s side: seeing 0.6% next to a CVE and lowering its priority without checking KEV.

An order of operations

This sequence is our recommendation. It uses each signal for the question it can answer.

1. Is it in KEV, or does the vendor say it is being exploited? If yes and the affected system is reachable from untrusted networks, act now, and plan a compromise check as well as a patch. If the system is internal only, schedule it within days. Vendor statements count: Fortinet’s advisory for CVE-2026-104286 said the flaw was being exploited on the day it was published.
2. If not, what does EPSS say? A score above your chosen threshold moves the item up. Our EPSS data feed guide shows how to add the daily scores to a scanner export. Pick the threshold from your capacity: lower it until the resulting queue is the size your team can clear.
3. If EPSS is low, is it Critical and exposed? A CVSS base score of 9.0 or higher on an internet-facing system still deserves the next patch cycle, because a low EPSS score on a fresh CVE can change quickly.
4. Everything else follows the routine schedule.

At every step, the exposure question is yours to answer. None of the three sources knows whether your FortiMail web interface faces the internet.

Here is that logic as a small Python function. It is an illustration of the ordering, not a finished tool. We ran it against the KEV data file and the seven flaws above; the thresholds are examples.

import json

EPSS_WATCH = 0.10  # probability, not percentile; tune to your own capacity


def load_kev(path: str) -> set[str]:
    with open(path) as f:
        return {v["cveID"] for v in json.load(f)["vulnerabilities"]}


def triage(cve: str, cvss: float, epss: float, internet_facing: bool, kev: set[str]) -> str:
    if cve in kev:
        return "1 - act now" if internet_facing else "2 - this week"
    if epss >= EPSS_WATCH:
        return "2 - this week" if internet_facing else "3 - next cycle"
    if cvss >= 9.0 and internet_facing:
        return "3 - next cycle"
    return "4 - routine"

load_kev reads the JSON file CISA publishes at github.com/cisagov/kev-data. With the KEV check in place, all seven flaws returned “1 - act now” for an internet-facing system. With an empty KEV set, simulating a team that skips that check, four returned “3 - next cycle” and three returned “4 - routine”. Same flaws, same scores, one missing lookup.

Daily EPSS scores are available from FIRST’s API at https://api.first.org/data/v1/epss?cve=CVE-2026-104286, which accepts a comma-separated list of CVE IDs.

Common mistakes

• Sorting the backlog by CVSS and working from the top. This treats a Critical flaw on an isolated test server as more urgent than a High flaw being exploited on your gateway.
• Reading a low EPSS score as “safe”. It is a 30-day estimate from a model. Check KEV and the vendor advisory before lowering priority.
• Confusing EPSS percentile with probability. “82nd percentile” sounds urgent. The probability behind it in the table above is 2.2%.
• Treating KEV as complete. It lists what CISA has evidence for and can point to a fix for.
• Multiplying the scores together. FIRST says not to. The result has no defined meaning.
• Recording “patched” instead of the fixed version. Citrix issued two bulletins for NetScaler within a week, and the builds that fixed the first were still affected by the second, as we covered in the NetScaler CVE-2026-88779 article.
• Trusting one data source for affected versions. In the FortiMail case, the CVE record and the vendor advisory listed different version ranges.

For the organizational side of this, including why backlogs grow when everything is ranked by count, see the vulnerability backlog that never shrinks. For what to do once something lands in the top tier, see how to respond to a zero-day.

Sources and verification

Checked on October 7, 2026. EPSS scores change daily and the KEV catalog grows, so the figures below describe those dates only. The seven flaws were chosen because we had already reported on them; they are examples, not a representative sample.

Security champions programs almost always launch well — volunteers sign up, there’s a kickoff meeting, enthusiasm is genuinely high. Then within two quarters, champions stop showing up to the monthly sync, the security team stops preparing content for it, and the program quietly becomes a Slack channel nobody posts in. The failure pattern is consistent enough across companies that it’s worth designing around from day one.

Give champions authority, not just information

Most programs are structured as a one-way information pipe: security team teaches champions about threats, champions are supposed to relay it to their teams. This makes champions a newsletter forwarding service with extra steps, and that role doesn’t sustain motivation. Champions who instead get real authority — reviewing their own team’s threat models, having a say in which security debt gets prioritized on their team’s roadmap — have a reason to stay engaged, because the role does something rather than just knows something.

Make the time investment visible to managers

Champions almost always take on the role on top of their regular workload, with no adjustment to their sprint capacity or performance goals. When crunch time hits, the champion work is the first thing to slip, invisibly, because no one but the champion notices. Get explicit buy-in from engineering managers that champion time (even just 2-3 hours a month) is accounted for in planning, not absorbed silently — this single change predicts program longevity better than almost anything else.

Rotate the content, not just the people

Programs that repeat the same “here’s this quarter’s OWASP Top 10 refresher” format burn out fast because champions stop learning anything new. Mix in things champions can’t get elsewhere: a walkthrough of an actual internal incident, a live threat-model session on a real upcoming feature, or a chance to red-team a teammate’s design. Content that’s specific to your company’s actual systems is what keeps a champions program from feeling like a recurring training module people tolerate rather than value.

Most logging strategies get built to answer “what does normal look like” — the questions a dashboard needs. Incident response needs the opposite: enough detail to reconstruct exactly what an attacker did, in order, across systems that don’t share a clock or a request ID. Those are different design goals, and optimizing for one quietly starves the other.

Correlation IDs matter more than log volume

Teams often respond to “we couldn’t reconstruct the incident” by logging more of everything, which mostly adds noise. The actual gap is usually that a request touching five services produces five sets of logs with no shared identifier linking them. A consistent correlation ID propagated through every service call turns a volume problem into a query problem — you can pull the full story in one search instead of manually time-correlating timestamps across systems that drift by seconds.

Log the auth decision, not just the auth attempt

Most systems log “login succeeded” or “login failed” but not why an authorization check passed or failed for a specific resource — which role, which policy, which condition matched. During an incident, “did this account have access to this resource, and under what policy” is one of the first questions asked, and without decision-level logging, answering it means reverse-engineering the access control logic from scratch under time pressure.

Retention matters more than most teams budget for

Attackers increasingly wait weeks or months between initial access and objective — meaning the logs you need to reconstruct the intrusion may have already rolled off retention by the time you’re investigating. Check your actual log retention against your industry’s typical dwell time, not against your storage budget’s comfort zone; a shorter retention window than your realistic detection lag means some incidents are unreconstructable by design, regardless of how good your logging schema is.

A tabletop exercise where everyone sits in a conference room and narrates what they’d do tests whether people remember the runbook. It doesn’t test whether the runbook survives contact with a real incident — degraded communication tools, a key person on vacation, or an attacker who doesn’t follow the scenario’s script.

Run at least one exercise with a communication channel down

The single most common real-incident failure mode isn’t a missing step in the runbook — it’s that Slack, your usual coordination tool, is either compromised or unavailable (because it’s hosted on the infrastructure that’s on fire). If your tabletop always assumes normal tooling, you’ve never actually tested your incident response — you’ve tested your ability to read a document out loud. Run one exercise per year with the primary comms channel explicitly ruled out of scope.

Inject a wrong turn, not just a scenario

Most tabletop scripts hand the team accurate information and let them respond correctly. Real incidents include red herrings — a misleading log entry, an alert that points at the wrong service, a well-meaning engineer who changes something mid-incident without telling anyone. Build at least one deliberate wrong signal into your next exercise and see how long it takes the team to notice and correct course; that recovery time is a more useful metric than whether they reached the “right” answer eventually.

Test the decision-maker’s availability, not just their competence

Plans routinely name a single incident commander with no tested backup. Pick a tabletop date and explicitly remove that person from the exercise without warning the rest of the team beforehand — if response quality collapses, you’ve found a single point of failure that a real 2am incident will find for you anyway, just with worse timing.

Most orgs respond to alert fatigue with rotation schedules, mental health check-ins, or hiring more analysts. All reasonable, none of them fix the actual problem: a detection pipeline generating more noise than signal, which is a tuning failure, not a staffing shortfall.

Track signal-to-action ratio, not alert volume

Counting total alerts tells you nothing useful — it doesn’t distinguish between 10,000 alerts that each require a decision and 10,000 that are auto-closeable duplicates. The metric that matters is what fraction of alerts result in an actual action (escalation, ticket, remediation) versus a dismiss-and-forget. If that ratio is under 5%, your rules are too broad, and adding headcount just spreads the same noise across more people instead of removing it.

Kill rules before you tune them

The instinct when a rule is noisy is to tighten its thresholds. Often the faster fix is deleting it and confirming nothing important was riding on it — most legacy detection rules were written for an environment that no longer exists, and nobody owns the decision to retire them. Run a 90-day audit of which rules have never once led to a real action, and sunset them explicitly rather than letting them quietly erode trust in the rest of the pipeline.

Separate “needs a human now” from “needs a human eventually”

A huge share of fatigue comes from routing informational alerts through the same channel as ones requiring immediate triage. If a Slack channel or pager gets both “unusual login from a new device, self-resolved” and “ransomware indicator on a production host,” analysts learn to skim everything — including the alert that actually mattered. Split your routing by required response time, not by source system, and the urgent channel becomes trustworthy again.

Blameless postmortems are now the default at most engineering orgs, which is progress. But a document being blameless doesn’t automatically make it useful. The most common failure mode isn’t blame creeping back in — it’s that the postmortem produces a list of action items that never get prioritized against feature work, so the same root cause resurfaces in six months wearing a different symptom.

The action item graveyard

If your postmortem template has an “action items” section with no owner, no deadline, and no forcing function to revisit it, you don’t have a prevention process — you have a documentation exercise. Action items from incidents need to compete for sprint capacity the same way any other ticket does, with a visible cost to deferring them repeatedly.

Root cause is rarely singular

Most postmortems stop at the first plausible technical explanation: a bad deploy, a missing rate limit, an expired certificate. The more useful question is what allowed that technical failure to become a customer-facing incident — was there no monitoring on that path, no runbook, no one on call who knew the system well enough to catch it early? Fixing the technical trigger without fixing the detection gap guarantees a different trigger produces the same outcome later.

Track recurrence, not just resolution

Most incident tracking measures time-to-resolution and calls it done. Add one more metric: how many incidents this quarter share a root cause category with an incident from last quarter. If that number isn’t trending toward zero, your postmortem process is documenting problems, not solving them.

What a working process looks like

• Every action item gets a named owner and a sprint, not a someday-list
• Postmortems ask what let the failure surface to users, not just what failed technically
• Recurrence rate is tracked as a metric leadership actually looks at

The blameless part was never the hard part. Follow-through is.