Release notes 0.1.163

28 October 2026: An outside change and the scanner finding that followed it now meet on the finding.

Release notes · Updated 2026-10-28 · Describes release 0.1.164

0.1.163 — 28 October 2026

An outside change and the scanner finding that followed it now meet on the finding. Two Guardrails switches are on by default: an incident stays open while its fix waits for a person, and a change whose before-state cannot be captured does not run on the platform. The scanner pull clears the open findings Security Hub no longer reports or that fall outside the tag scope, and lands Inspector CVEs in a tag-scoped workspace; Alerts searches on the server; a built-in alert joins its resource's service. Built-in detection sees a crash loop between back-offs, the estate joins a controller load balancer and a vendor-API firewall to their services, and a release whose quorum lapsed waits for a vote again instead of failing. One additive column (cloudfinding.failing_since), one one-shot data fix (migration:finding-family-v1), one new setting (AIOPS_REQUIRE_BEFORE_STATE, the platform default of aiops_require_before_state), two new query parameters on GET /api/aiops/{tenant_id}/alerts (q and service) and four new audit actions (incident.change_linked, change.finding_linked, compliance.finding_gone, compliance.scanner_out_of_scope); no new route, permission or chart value. Read the upgrade row before upgrading: both default flips change what a workspace that never set them does.

Behaviour changes in 0.1.163

Two Guardrails switches are now on by default. aiops_hold_for_approval (Keep an incident open while its fix waits for a decision) and aiops_require_before_state (Refuse a change when its before-state cannot be captured) were off and are now on for every workspace that never set them. A workspace that stored an explicit value keeps it: a box ticked or unticked on Guardrails, or true or false sent to PATCH /guardrails, wins over the platform default, and only null follows it. switch_state on GET /guardrails shows each switch's stored override and the platform default. On 0.1.162 the page showed an unset before-state switch and a stored false the same way (off), so a workspace that unticked it then keeps the rule off until it sends null or ticks the box.
An incident whose fix waits stays open. With the hold on, the quiet-window close, and the close of a ticket resolved at its source, leave an escalated incident open while a change request for it was requested (drafted, pending approval, or approved but not run), or while the analysis's proposal matched a certified runbook; the plain proposal every escalated run drafts holds nothing. Each held incident is audited once (incident.autoclose_held). A held incident no longer uses up the quiet window's batch, so the closeable incidents behind it are still reached.
A step with no before-state reader is manual-only. With the rule on, a direct write runs only after the platform has read and stored the resource's current state. A step the platform has no before-state read for — a typed step over a CLI connection, or a legacy direct route (api, cli or mcp) that declares no snapshot read — is offered on the manual route only: the review reads Manual route only: step N (…) has no before-state the platform can capture, lists the steps to run with your own access, and asks for the outcome to be recorded. An approved or scheduled change on such a step is refused when it fires. A read that fails at release stops before the write (Nothing was written, audit change.prestate_blocked), and the review then offers the manual route only until the write connection is tested again. Pull requests, backup steps and rollbacks are exempt, and every forward write of the built-in runbooks and step templates has its read. With the rule off, the 0.1.162 default, such a write ran with an honest none as its before-state.
Alerts searches on the server. The Alerts search box (Search alert, service or label) used to search only the page already loaded; it now asks GET /alerts, which takes q (a case-insensitive part of any label value or key, or of the fingerprint) and service (the alert's service label, exact in any case). Both are prefilled from ?q= and ?service=, at most 200 characters each: the box stops at 200 and the API answers a longer one with 422. X-Total-Count counts the matches.
The scanner register clears what Security Hub no longer reports — as no longer reported, not fixed. When every region was read in full, an open Security Hub finding the hub answers in no region, last seen over 48 hours ago, clears as no longer reported by the scanner (audit compliance.finding_gone). That applies to the connection's own account and to an account the same pull returned a finding of; a finding of another account — one the webhook feeds, say — clears this way only once it was last seen over 90 days ago, Security Hub's own retention. While every pulling AWS connection has a tag scope, an open finding whose harvested resource carries none of their tags, and that no read re-sent for 48 hours, clears as out of scope (audit compliance.scanner_out_of_scope). Neither counts as fixed: the incident's Resources line counts them apart (N no longer reported by the scanner (cleared, not fixed), N out of scope (cleared, not fixed)). Their incidents resolve, with the resolve notification and ticket write-back.
Inspector findings under a tag scope. A tag-scoped connection's Inspector read used Security Hub's resource-tag filter, which an ECR image or Lambda finding never matches (it carries no resource tags), so no CVE of a tagged repository or function landed. The read is now filtered after it returns: the finding's own tags decide, else the harvested estate's tags on its resource. A CVE on a tagged ECR repository or Lambda function lands, and a P1 or P2 one may start an analysis (aiops_auto_investigate_p1p2); the rest is counted per region as vulnerabilities_out_of_scope (at most 5,000 read a region and pull).
A built-in alert carries its resource's service. A built-in metric alert whose metric names no service takes the service its resource's tags name (a service, app, application or Name tag, as patch schedules read them), so an R04 alert on an EC2 instance tagged service=web joins web's other alerts instead of opening its own incident; its summary keeps the resource name. A resource with none of those tags keeps its name as the service.

Scanner findings and the outside write

An outside write is named on the scanner finding it preceded. Since the platform's own checks went off (0.1.147), a captured cloud write re-checked nothing on the platform side, and the compliance incident a scanner pull opened never named it. An unmanaged change on a finding's resource — captured by the platform's audit harvest, applied, and accounted for by no platform request, approval or execution receipt — in the 24 hours before the finding started failing, and after it last passed, is now listed under Changes that triggered this check on the finding's incident, with Captured change named on this finding on its timeline. The change gets a re-checked by Security Hub · EC2.19 · failed chip that links to the incident, and Scanner finding failed after this change on its timeline. Either side may land second: a write the audit log delivers after the finding is named at the next harvest. This is detection, not proof of cause, and nothing changes status. Only a control finding on a resource names a change (no CVE or threat finding, no subscription, resource group or account scope), a tag-only write only on a tagging control, and a finding the scanner saw failing more than 24 hours before the platform heard of it names none. GET /findings carries each row's failing_since; the harvest report and the manual pull's answer carry findings_linked.
Stored findings in their current family. The one-shot migration:finding-family-v1 classifies every stored finding again, so the DynamoDB.1, DynamoDB.6, ELB.6, Cognito.6 and RDS.8 rows that 0.1.148 moved out of backup missing leave the Backup list.
A connection's tag scope is checked at save. A connection's finding_tag_scope without exactly one key=value pair is refused at save (400) instead of failing at the next pull.

Change requests and approvals

Upgrade warning. A package, runtime, image or OS-patch upgrade (aws.ssm.patch_baseline, aws.ssm.upgrade_packages, aws.lambda.update_runtime, aws.ecr.rebuild_image) carries an Upgrade warning in its change request's 2.4 and under Affected resources & blast radius: what runs on the target, who calls it and the target version's known breaking changes, as the change management agent wrote them in its existing run, else exactly unknown, not checked (upgrade_warning on the change detail).
Approvals. A release whose approval quorum lapsed before it ran (a scheduled release, the automatic lane) goes back to waiting for approval instead of being rejected, with each vote listed once and a vote given after a lapse kept. A person's release of an API route no longer writes to a resource only a merged-in alert names. A refused rollback attempt keeps its time, and a backup step no longer shows a not captured row after the change.

Detection and the estate map

Crash loops between back-offs. R31 Pod crash loop also fires for a container restarted 3 times or more that crashed again since the previous read: between back-offs the kubelet shows it terminated, and a single-replica crash loop went unalerted for 27 minutes. A container lost with its node, as on a reboot, is no crash loop. A workload in alarm whose pods are gone, in a namespace still read and in scope, now clears and can close on the quiet window.
A scoped workspace's denied attempts stay in its scope. On a workspace with a tag scope, an AWS or Azure denied attempt opens a SecOps report only when it was made as one of the workspace's connections or targets an in-scope estate resource; the rest stay on the ledger, counted as denied_out_of_scope on the harvest report.
Load balancers and firewalls on the service path. A load balancer the AWS Load Balancer Controller made is joined to the Ingress or Service it serves, so a service group climbs from the workload to it. A firewall read through its vendor's API is joined by address to the cloud instance that runs it, and the instance's firewall row on the service path lists the device's enabled policies (a policy the device no longer lists is left out).
Cloud health with no answer. When the cloud-health triage step or built-in detection's AWS Health read gets no answer, it says what a private network needs: an interface endpoint for AWS Health and STS, or outbound HTTPS.

Pages and smaller fixes

Pages. The Alerts label chips wrap, and an ingest.batch audit row reads in words (received N · stored N · own ticket echoes skipped N). Every Status and Source count on Changes is the total of the list it opens, whichever filter chip is pressed. List tables fit their card, breaking an id, ARN, region or port only after a separator (a long id or checksum with no separator may break anywhere), and a scanner re-check chip and a captured write's title wrap. Thresholds and why is its own reference page, with the rows it lacked.
Audit. Model routing and residency audit rows carry the incident's correlation ID.