In benchmark testing, OpenAI’s latest model, GPT -6 Astra, was able to find unknown zero-day vulnerabilities and exploit them in real-time. Although this capability is being sandboxed and restricted for now, this finding should worry everyone, especially those responsible for public services. 

The security threat landscape is moving to a mass risk of zero-days, yet the public sector still struggles to respond to known vulnerabilities, especially third-party flaws that take an average of 358 days to fix.

To see where the response can stall, let’s follow a vulnerability alert through a public service and examine what it takes to get the affected code fixed. 

How fast is fast enough?

Imagine a council security team receiving an alert about a flaw in software used to process uploaded documents. A scan finds the affected component in several projects, including one that appears to support the housing repairs portal.

The service director wants to know whether residents can keep using it. The team needs to check which version is running and whether the upload function exposes the flaw. An external supplier maintains the application.

The scan has taken minutes. Answering the director could occupy much of the morning.

In Veracode’s 2026 State of Software Security research, third-party flaws took an average of 358 days to fix and accounted for 66% of critical security debt in its dataset.

Public-service leaders can examine the delay within their own organisations, starting with the work required to turn a component finding into an agreed plan for the affected service.

The search needs to reach below the application

A service register might identify the repairs portal and its supplier. It is unlikely to tell the security team which open-source library handles a resident’s uploaded photograph.

That detail belongs in the software’s component inventory. A software bill of materials, or SBOM, records the components in a build, including their versions. For this investigation, the inventory must cover dependencies brought in by other packages, known as transitive dependencies.

The distinction matters when the development team says it has never selected the affected library. Another component may have introduced it.

Search results should show that dependency path. It helps the engineer determine which package needs updating, especially when the vulnerable library cannot be changed independently.

Then check the inventory’s scope and date. Confirm that supplier-managed software is included in the search. If it is excluded, the team needs evidence from the supplier before ruling the service out.

Follow the finding all the way to production

Suppose the supplier confirms that the library appears in the portal’s codebase. Its latest development build already contains a corrected version.

The council still needs to establish what residents are using today.

Link the component finding to a specific build, then check where that build was deployed. The evidence should identify the live service and any running instances that still contain the affected version.

This connection takes preparation. Repository names rarely explain a service’s purpose to someone outside its delivery team. Maintain the relationship between each project and the service it supports as part of normal delivery. Changes of supplier or platform are good moments to check that the record still holds.

Once the team locates the affected release, it can assess exposure. Some vulnerabilities require particular settings or a reachable function before an attacker can exploit them. Record the relevant configuration and the reasoning behind the assessment.

That gives the service director something useful to act on. If the upload function is exposed, restricting it may be appropriate while a fix is prepared. The decision must account for how residents will submit repair requests during that restriction.

“We’re investigating” needs a next step

A supplier’s acknowledgment can arrive quickly while useful answers take longer.

In our scenario, the council needs a response tied to its deployed release. The supplier should explain whether that release is affected and identify the proposed remedy. Agree when the next substantive update will arrive.

Inside the council, assign someone to coordinate the remediation. That person needs a working technical contact at the supplier and a route for escalating delays. The accountable service owner must also be available to approve operational decisions.

Ownership should be established before the alert arrives. Test the escalation route during routine supplier reviews. A contract reference is little help if the named contact has moved on or cannot reach the engineers responsible.

Where several public services share the same component, assess their exposure individually. Prioritisation should reflect evidence of exploitation and the consequences for each service. A common package does not mean every deployment needs the same response.

The fix has to survive contact with the service

A suggested replacement version gives engineers a starting point. It still needs testing against the application.

An upgrade can change behaviour elsewhere in the dependency chain. For the repairs portal, regression testing should include the document-upload workflow residents rely on. The team also needs a recovery plan if deployment causes problems.

Keep the finding open until the evidence shows that the corrected build has reached the affected instances. Recheck the deployed software and retain the result with the remediation record.

If an update must wait, document the reason and set a review date. Any temporary restriction needs someone responsible for checking that it remains effective. Otherwise, the next person handling the service inherits an unresolved decision with little explanation.

Find out where your own morning goes

Choose one important service and rehearse this investigation using a component it actually contains. Time how long the team takes to produce:

• A deployment record: the affected version linked to the live service.
• An exposure decision: the evidence supporting the assessment.
• A named lead: someone able to coordinate remediation and escalate delays.
• A tested route to closure: the proposed update and the checks required after deployment.

Record where the investigation stalls. Waiting for supplier evidence requires a different remedy from finding an ownerless repository. Repeat the exercise once the team has addressed the delay.

Meterian can support the component investigation by identifying dependencies across projects and monitoring published vulnerabilities. Its reports provide remediation guidance, with integration into existing delivery pipelines. Teams can connect those findings to their service records to complete the investigation.

We’ll be discussing that work at DigiGov Expo, 23–24 September 2026, at ExCeL London. Meet Meterian to explore how quickly your team could trace an affected component through to a public service and put someone in charge of the fix.