Release notes 0.1.154
25 October 2026: A vulnerable container image can be rebuilt by a step runbook under a new tag, with an opt-in block of pulls from its repository; a fix's validation rounds can ask AWS Reachability…
Release notes · Updated 2026-10-28 · Describes release 0.1.164
0.1.154 — 25 October 2026
A vulnerable container image can be rebuilt by a step runbook under a new tag, with an opt-in block of pulls from its repository; a fix's validation rounds can ask AWS Reachability Analyzer whether its neighbours still reach the changed instance; and the runbook permission check no longer reads a permission the write role lacks as unknown (live test of 0.1.153). No schema change and no new route. New settings aiops_ecr_block_pulls and aiops_reachability_checks (both off), aiops_reachability_max_per_change and aiops_image_reminder_h; new write-role permissions (see the upgrade row).
- Container image rebuild: the step-runbook operation
aws.ecr.rebuild_image(runbook only: the analysis never proposes it) starts ONE build of the customer's own CodeBuild projectaiops-image-rebuild, which pulls the vulnerable image by digest, upgrades the packages the scanner named to the versions it says fix them in a layer on top (OS packages through apt, apk, dnf, microdnf or yum, Python packages through pip — only packages the image already has, never to an older version) and pushes the result to the same repository under a NEW tag,<tag>-aiops-chg-<change>. The old tag and digest stay untouched and nothing running is redeployed, so the rollback step isnone. A package compiled into a binary, or one with no fixed version, refuses the whole step (rebuild it from source with a pull request), and so does a multi-architecture image (the build rebuildslinux/amd64only). The runbook binds the image from the finding'sannotation:resource_arnand the packages fromannotation:vulnerable_packages. The platform never creates or edits the project:deploy/awscreates it withimage_rebuild = true(its buildspec refuses a tag that exists or is not a rebuild tag, matches each of the five variables as a whole value and passes the change id as a build label, never as a Dockerfile line; its own role pulls and pushes only repositories taggedaiops-managed=true). A build the platform stopped waiting on is read again on the scheduler's tick. Not yet run against a live registry: tested against simulated ECR and CodeBuild answers. - Built, not deployed: once the new tag is pushed, the validation reads the scanner's finding on the OLD digest ($0, no agent run). While it is still open the change completes, the incident goes to a person (the deploy is theirs) and the incident and finding pages show New image built, not deployed with the new tag and digest. Notification targets that take the new event
image_not_deployedhear it then and again everyaiops_image_reminder_hhours (24;0= once) until the scanner stops reporting the old digest, which resolves the incident (auditimage.not_deployed, one row per reminder). Moving the workloads to the new tag does not stop the reminders on its own: the old tag and digest stay in the registry and the scanner keeps reporting them until someone deletes or untags the old digest, or the scanner's re-scan period for it ends. Incident and finding details carryimage_rebuilds. - Block pulls of this image (opt-in, off): with Allow a runbook to block pulls of a vulnerable image on (Change safety,
aiops_ecr_block_pulls), a runbook stepaws.ecr.block_image_pullsadds one Deny statement to the image's ECR repository policy (pulls refused to every principal but the account'saiops-*roles). ECR authorizes a pull per repository, so it blocks every image there, the rebuilt tag included. Always L3 (two people), never automatic; the policy read before the write is recorded and Roll back puts it back, or deletes the policy when there was none. The guided setup never grants the repository-policy actions: onlydeploy/awswithimage_pull_block = true. Not yet run against live AWS: tested against simulated ECR answers. - Neighbour reachability in the validation rounds (AWS, off): with
aiops_reachability_checkson (API only), a validation window chosen from the service graph also asks Reachability Analyzer whether a path on any TCP port exists between each one-hop neighbour that has an EC2 network interface and the changed instance, once per window (later rounds carry the answer). The path and analysis are created through the change's write connection, taggedaiops:change, and deleted as soon as the answer is in; an analysis not finished in 60 seconds reads not observed; while the switch is on a sweep removes any such path older than an hour. AWS bills about USD 0.10 per analysis to the account: at mostaiops_reachability_max_per_change(10,0–60) a change. It uses the write role's Reachability statements added in 0.1.146. Not yet run against live AWS: tested against simulated EC2 answers. - The runbook permission check reads an absent permission as missing: on the live test of 0.1.153 a write role lacking
ec2:ModifyNetworkInterfaceAttributeandssm:DescribeInstancePatchStatesread unknown for both and the runbook was certified. IAM'sMissingContextValueslists every condition key the role's policies use, related to the action or not, even on a deny; the check read any listed key as unknown. A deny — implicit or explicit, whether a statement matched or not (the write role's Deny boundary, a permissions boundary) — is now missing, and the certification is refused. Unknown is kept for an allow IAM answered with a key still absent and for a real target whose tags could not be read (before an automatic run, the instance's network interfaces); a listed key the check can supply after all (a region key, a resource tag under another service's prefix) is filled in and asked once more. The image operations' ECR actions are simulated against the image's repository, the isolation's group side against the security groups it attaches. The route editor and the certification line now say unknown does not mean granted, and a refusal says the role lacks the permission or grants it only under a condition the check cannot supply (a source IP or VPC endpoint, a principal tag). With no target the check simulates a resource tagged with the write connection'sscope.resource_tag— whichdeploy/aws'sdatasource_snippetnow prints fromresource_tag_key/resource_tag_value— elseaiops-managed=true: a role scoped by another tag reads missing and is refused until the connection names its tag. The S3 Block Public Access fix's rollback is checked fors3:PutAccountPublicAccessBlockonly (it also authorizes the delete when the account had no block before; the check asked for ans3:DeleteAccountPublicAccessBlockIAM does not have).