# Release notes 0.1.155

> 26 October 2026: Fixes from the live tests of 0.1.154 (the EC2 patch drill, the ServiceNow test and the Kubernetes, ECR and change lanes), a Lambda runtime upgrade runbook and a not needed end…

_Release notes · Updated 2026-10-28 · Describes release 0.1.164_

## 0.1.155 — 26 October 2026 {#0-1-155-26-october-2026}

Fixes from the live tests of 0.1.154 (the EC2 patch drill, the ServiceNow test and the Kubernetes, ECR and change lanes), a Lambda runtime upgrade runbook and a *not needed* end state for a change. A scanner finding or a security alert is never fixed without a person's approval. No new setting and no new route; one index is added at start. The write role gains permissions and its policies are split into one inline and four managed policies: re-run the AWS setup (see the [upgrade row](/help/ops-upgrade-and-verify.md)).

- **Findings never fix themselves:** a compliance control, a scanner finding, a vulnerability or a security alert (the SecOps agent's, including one a generic webhook sends from Trivy, Wazuh, CrowdStrike or Falco, and any alert whose labels name a CVE: a `cve`, `cve_id` or `cve_ids` label or a CVE id in its alertname) is fixed only after a person approves it, on every automatic lane — pull-request route, direct API call and step runbook — whatever runbook matches and whatever the switches say. An incident's fix still runs on its own under the existing rules. Before, a certified step runbook could release a finding's change with both automatic-fix switches on. The incident's Timeline says why each time a pre-approved fix matched and waited. On the plan lane, in a workspace with a write-capable connection and *Let the analysis pick a matching route instead of typed steps* on, a finding's analysis is now offered the enabled step runbooks certified at their current revision that match it (the EC2 patch runbook on a Patch Manager finding), so its change request can carry the runbook's steps — a person still releases it.
- **EC2 restore from the platform's own backup:** **Roll back** of the EC2 patch runbook (`CreateReplaceRootVolumeTask` from the pre-change image) was refused by AWS on the image: the write role allowed it only with a request tag, which an image that already exists never carries. The role now restores from this account's own image or snapshot that carries the `aiops:change` tag, into a new root volume only (never an existing volume swapped in), with the restore task tagged on create. The step runbook's permission check probes the image with its owner.
- **Change request fixes:** the change request's rollback section prints the runbook's own rollback steps with their CLI lines (the recorded groups back, the root volume from the pre-change image) instead of *no automatic inverse*; a runbook's change request is drafted at the tier its release needs (L2 for its API steps, L3 with a pull block) instead of L1; the validation reads what each criterion says — the patch command's status and Patch Manager's missing and failed counts, the restored groups against the recorded ones — instead of the instance's power state, and a read that cannot answer is *not read*, never a pass; an isolation the same change restores is no longer listed as an end state (a change drafted before the upgrade reads its isolation item by the restore). The isolation check names its group, the assumptions read as one bullet each, and an analysis that names a runbook writes its fix from the runbook's own steps. A step acting only on the resource of an alert merged into the incident, which the service map shows depends on the incident's own service, is left out of the change and listed under Impact, so the incident's own fix can be released (any other such step still refuses the whole plan); a change request whose document was still being drafted when the change was released no longer stays *drafting*; and an incident names the runbook its fix followed, not the first step's operation.
- **Lambda runtime upgrade runbook:** three new operations — a version backup (`aws.lambda.publish_version`) and two runbook-only steps, the runtime of `$LATEST` (`aws.lambda.update_runtime`, `Runtime` only, a supported runtime written in the runbook) and the alias move (`aws.lambda.update_alias`, only when `$LATEST` runs the alias's code with only the runtime changed) — each guarded by the revision it read. The platform never builds or uploads code. Rollback is operator lines (the alias back, the runtime back). The demo workspace gains the disabled example route *EXAMPLE: Lambda runtime upgrade with version backup* for Security Hub's Lambda.2. Not yet run against a live function.
- **Not needed:** a change whose only target already complies (an EC2 instance Patch Manager reads compliant) ends `not_needed`, a terminal state with nothing to roll back, instead of `failed`; the change page, the incident's remediation history and the change request say *Not needed — <reason>* (audit `change.not_needed`, metric outcome `not_needed`). A stop after a write, or with another target still waiting, stays failed.
- **ServiceNow and tickets:** a ticket the platform files fills the fields it requires of a ticket that comes in — ServiceNow's severity, assignment group or assignee and configuration item, Jira's component and assignee, Azure DevOps' priority — when an exact lookup finds them (run **Check** on a Jira or Azure DevOps route and save it again). The *Notify* line names only channels that can deliver (email needs a mail relay); no address is put on a ticket. A person's resolve note leads the write-back, and a stopped analysis is never written as the root cause. **Send test ticket** now works on a disabled route (it answered 409 before) and says the route tickets nothing until it is enabled. A ticket that joins a live incident is counted as `joined` (it read `suppressed`), the platform's own resolve coming back as `ticket_echo`, and Azure DevOps intake reads a Bug's *Repro Steps*.
- **Kubernetes audit noise and denied writes:** EKS's own service-linked role (the Auto Mode controllers, about 3,100 rows a day on the demo cluster) and `kubectl auth whoami` are no longer recorded as changes. A pipeline's refused write is kept as a denied attempt and opens the SecOps report, and the 50-object cap counts per cluster, service account and hour after the dedupe, so overlapping pulls agree. A kubectl cluster is named after its connection in estate ids and alerts (two connections no longer share one); the next harvest removes the old `k8s:cluster/…` nodes.
- **Correlation:** the change-window rule no longer folds a scanner finding into the incident of a suspect change (27 CVE findings of one instance had folded into one incident), nor folds an alert into a finding's incident. A plain alert on the same resource still folds.
- **Image rebuild:** the buildspec upgrades a finding's packages to at least the fixed version: Python packages (`PYTHONPKG`, `PYTHON`) through pip, an epoch-carrying version, a Debian source package (`expat`, `glibc`) through the installed packages built from it, the mirror's newest when the exact fix is gone; it stops on a failed upgrade and refuses a package a dependency file in the image pins (`PIP`, `PIPENV`, `POETRY`), which needs a pull request instead. A project created by `deploy/aws` before 0.1.155 keeps the old buildspec until `deploy/aws` is re-applied.
- **Reachability permissions:** AWS also authorizes a network-insights path on its source and destination interfaces, so every neighbour reachability row read *not observed*; the write role now allows the create on them (a path changes neither). With `aiops_reachability_checks` on, a runbook acting on an EC2 instance has these permissions checked at certification and before an automatic run.
- **Write role policies:** the write role's statements no longer fit IAM's 10,240-character limit for a role's inline policies, so the backup and restore, Reachability, image rebuild and Lambda statements moved into four customer-managed policies attached to the write role only, unchanged. A `deploy/aws` write role now fits every commercial region (it fitted six with the pull block, eight without).
- **Firewall:** a FortiGate connection gets a read-only traffic log tool (`<name>_traffic_log`: one bounded, scrubbed page; not yet validated against a device when released — the request it sends has since answered on FortiOS 8.0.2, in October 2026; its paging and session re-read have not run on a device). **Test** on a FortiGate or PAN-OS connection whose management address is private says *Not a failure*: the estate harvest reads it from inside your network (code `inside_network`); a platform installed in your network, with the network guard off, dials it as before. A service group can be found from a bare AWS resource id.


## Next steps

- Next: [Release notes 0.1.154](/help/release-notes-0-1-154.md)
- [All What's new pages](/help/what-s-new/llms.txt)
- [Documentation home](/help/)