The update looked clean later: why software supply-chain reviews need a timeline
An alert suggests a device received a suspicious software update. Someone checks the supplier’s download service later and finds the expected file. That is useful information about the service at the time of the check. It does not, by itself, tell you what the device received earlier.
A software supply-chain attack uses something an organisation already relies on, such as an update service or a supplier’s delivery process, to reach downstream systems. When the change exists only briefly, the timing of the evidence becomes central to understanding who may have been exposed.
The recent report behind the question
On 15 October 2026, Google Threat Intelligence Group and Mandiant published an investigation into tampering with AOMEI update infrastructure between April and July. They described configuration changes lasting five to ten minutes before legitimate content was restored. They also reported that AOMEI said it had taken corrective action to secure its distribution servers.
The publication is recent; the activity it describes happened earlier. It does not establish that every installation received malicious content or that the same infrastructure remains compromised today. For an individual environment, exposure needs investigation against its own records and the investigators’ technical findings.
The practical question for product, delivery and operations teams is simple: can you connect a particular device to a particular update event? The exercise below is an original way to make that question easier to answer.
Separate three different observations
“The supplier service looks normal now” describes a present observation. “This device contacted it yesterday” describes an earlier event. “The device installed and executed this file” is a further claim requiring its own evidence.
Those statements should not be collapsed into either “everything is fine” or “every device is compromised”. A useful incident discussion keeps confirmed facts, reasonable hypotheses and gaps visible. That makes it easier for responders to decide what to investigate next.
Build a small update-evidence timeline
1. Identify the device and update channel
Purpose: Establish what the record refers to.
Record the managed device identifier, product and known version, update channel, responsible team and relevant time period. An update channel is the route through which the product receives releases or instructions. Distinguish a centrally managed rollout from software that independently checks a supplier’s service.
Avoid collecting a large amount of personal data “just in case”. Ask the incident lead which identifiers are necessary and where they should be stored. Use the approved incident record rather than a public document or an open chat channel.
2. Put times on the same basis
Purpose: Make records comparable without hiding uncertainty.
For each event, record its timestamp and timezone. Note whether a time came from a device, a server or the moment a person observed it. If there is reason to doubt a clock, preserve that uncertainty rather than silently correcting the record.
Write events in sequence and retain their sources. A network contact, an installer log and a process-start record describe different stages. A gap between them is a question to investigate, not a space to fill with an assumption.
3. Describe the evidence behind each claim
Purpose: Distinguish a contact from a completed execution.
Use columns for time, observation, source, interpretation and next question. Ask the responsible technical team what records are available for the request, downloaded artifact, installation and subsequent behaviour. An artifact is the actual file or package involved in the event.
A hash is a fingerprint used to compare file content. It can help identify whether two retained files match, but an expected hash obtained from a source that may also have been altered is not independent proof of authenticity. Ask specialists which verification evidence can be trusted in the particular case.
4. Keep “unknown” as a usable outcome
Purpose: Stop missing evidence becoming false reassurance.
Suppose a record shows contact with an update service but no retained response or installer record. The defensible conclusion may be that the content received is not yet established. Record what you checked and which source might resolve the gap.
Do not rerun a suspicious installer or collect malware on an ordinary work device to answer the question. Let authorised responders choose safe collection and analysis methods. Their investigation may need evidence beyond the records your team normally uses for delivery reporting.
A fictional twelve-minute example
Illustrative exercise: at 09:02 UTC, a managed laptop records an update check. At 09:04, it records a downloaded file. At 09:07, a process starts from the updater’s working area. At 09:14, an administrator checks the supplier’s service and sees the normal configuration.
The 09:14 observation does not identify the 09:04 download. The next question is whether the team can connect that earlier artifact and process to the advisory’s affected behaviour. The example contains no actual campaign indicators and does not describe a real customer.
Now imagine a second laptop contacted the service at 09:20 but has no installation event in the period being investigated. Its record belongs in the same investigation, but it should not automatically receive the same conclusion. Document the distinction and the remaining uncertainty.
Questions to ask a supplier before an incident
Ask how the product verifies update authenticity, which parts of the update instructions are protected, and which customer-visible records identify a received version or package. Ask how a security notice will describe affected products, delivery periods, exposure checks and recovery actions.
Request a named contact and a route for urgent questions. Clarify how the organisation would pause a specific risky channel, deploy a verified alternative or restore service if the supplier advised it. These are planning questions, not an instruction to disable updates. Indefinitely stopping updates can leave other vulnerabilities unaddressed.
Try a safe tabletop review
Choose one product in your approved software inventory. Ask its owner to show how a routine update appears in the records already available. Use fictional events to test the timeline format. Can a colleague distinguish “contacted”, “downloaded”, “installed” and “executed” without guessing?
If not, agree one visibility improvement with an owner and review date. Better evidence helps a team make a more proportionate decision when the next supplier notice arrives.
Sources and review
Researched and reviewed 19 October 2026. Primary report: GTIG and Mandiant, 15 October. Collaborating investigation: ManageEngine METAL’s technical analysis. The timeline, supplier questions and fictional events are original editorial exercises. They are not product-specific forensic instructions or evidence that a reader is affected.
You May Also Like
How to mentor junior developers when AI can finish the task for them
How to write useful user stories: examples and acceptance criteria
