TL;DR: Scan results show what is exposed right now only if you can rescan the moment risk changes, and most tools still wait for the next scheduled cycle. Aqua real time scanning lets teams start an on demand scan from the Aqua Hub or API, rescan only what changed in an image and use one architecture across SaaS, hybrid, multi-cloud, on premises and air gapped environments. Aqua then focuses attention on findings with available exploits and runtime context from running workloads.
What is real time vulnerability scanning?
Real time vulnerability scanning is the ability to scan a specific image on demand instead of waiting for the next scheduled cycle. That matters because a scan result can go out of date in two ways after it is produced. The image itself can change when a team rebuilds or patches it. The vulnerability intelligence can also change when a new CVE is published against packages the image already contains, which leaves an unchanged image newly vulnerable. In either case, a real time scan returns a result that reflects both the image and the vulnerability data as they exist right now.
Why does real time scanning matter right now?
Attackers move faster than scan schedules, so the value of a scan result now depends on how current it is. In cloud native environments, new workloads start with every deployment and running containers can drift from what the pipeline originally scanned.
A scheduled scan accurately describes the environment at the moment it ran, and every change after that becomes a blind spot. When a new vulnerability is disclosed, teams end up answering a question about production today with results from an earlier cycle, often pieced together by hand from more than one console.
Where do current approaches to vulnerability scanning fall short?
Scheduled scanning remains the right foundation for coverage, and pipeline scanning catches risk before deployment. The trouble starts when a question cannot wait for the next cycle.
Rescanning a large registry after a disclosure usually means pulling and fully analyzing images that have not changed, so teams choose between scanning everything slowly or scanning a few repositories quickly. Coverage can also differ between public cloud accounts, private data centers and disconnected sites.
Noise compounds the problem. When severity is set inconsistently across teams and pipelines are blocked by findings that never mattered, developers learn to stop trusting the results.
What does a better approach to vulnerability scanning look like?
Every scanning decision should help your team answer one question quickly and accurately: are we exposed right now?
Scheduled and real time scanning should work together. A schedule maintains baseline coverage across every registry, and real time scans give teams a current result for a specific image the moment a disclosure or a rebuild changes the picture.
The scanning model should also be the same wherever images live. When public cloud registries, private data centers and air gapped sites each depend on a different tool or console, someone has to assemble the exposure answer by hand. A single architecture that applies the same policies everywhere produces an answer the team can use as soon as it arrives.
Rescans should scale by doing only the work that is new. Reanalyzing an image that has not changed adds time without adding information, so a better approach checks unchanged images against new vulnerability intelligence and reserves deeper analysis for what has actually changed.
Findings should be ranked by evidence, not severity alone. Consistent policy keeps a critical finding meaning the same thing in every team’s pipeline, while exploit intelligence and runtime evidence move the findings worth fixing to the top. When developers see that a blocked build reflects real risk, they start trusting the results again.
How does Aqua real time scanning work?
When you start a scan from the Aqua Hub or our API, the request goes to the Aqua Scanner attached to the relevant registry. Scanners can sit wherever your registries live, and they compare image contents against CyberCenter vulnerability intelligence before returning results to the console.
Before scanning, we check what has changed. An unchanged image is checked against newly published vulnerabilities without a rescan, an image with new layers has only those layers scanned and an image we have never seen is pulled and fully scanned. The same architecture runs on our SaaS platform and in self hosted deployments, including air gapped environments where the console sits behind your firewall.
For example, a developer patches an image that failed policy, clicks rescan and sees the updated compliance status as soon as the scan completes. We then rank findings by whether an exploit is available, including whether it can be exploited remotely, and add runtime context from running workloads.
What will runtime reachability add to vulnerability prioritization?
A current scan tells you what is present in an image, while the harder question is which vulnerable packages your running application actually uses. Runtime reachability is a planned capability we are adding to connect image scan results with evidence of the packages a running application loads.
An image might contain 100 vulnerabilities while the application loads packages tied to only two of them. Those two are not automatically proven exploitable, but they are the findings where remediation is most likely to reduce production risk. Image scanning still establishes the inventory, and runtime reachability will show which findings in it matter to the running application.
How do traditional, modern and Aqua approaches compare?
| Dimension | Traditional Approach | Modern Approach | Aqua Approach |
| When results update | Next scheduled cycle | Platform defined scan cadence | Scheduled plus real time scans |
| Recanning large registries | Full rescan of every image | Broad rescans across connected accounts | Only new layers scanned; unchanged images checked against new vulnerabilities |
| Environment coverage | Separate tools per environment | Strongest in connected public cloud accounts | One architecture across SaaS, hybrid, multi-cloud, on premises and air gapped |
| What gets prioritized | Severity score | Severity score plus exploit intelligence | Exploit availability, remote exploitability and runtime context |
| Evidence of what is in use | Image contents only | Image contents with exploit intelligence | Runtime context today, with runtime reachability planned |
What mistakes do security teams make with vulnerability scanning?
Treating the last scheduled scan as current exposure. Every image rebuilt or workload started after that scan stays invisible until the next cycle, which is when leadership asks the question.
Rescanning everything after every disclosure. Full rescans of unchanged images slow the response and push teams toward scanning only a subset of repositories.
Treating every vulnerable package in an image as equally urgent. An image can contain vulnerable packages the running application never loads, so ranking by presence alone sends developers after fixes that may not reduce production risk.
What should you do next?
Rehearse the next critical disclosure now. Measure how long your team takes to say which running workloads are exposed and how many consoles that answer requires. Then rescan a recently patched image and check whether the result reflects the change. If either step depends on a scan cycle, that waiting period is where you lose control of exposure.
Watch the webinar to see Aqua real time scanning in action:
No. Aqua supports scheduled scanning for recurring coverage and real time scanning for moments that cannot wait, such as a new disclosure or a freshly patched image.
Large environments can contain thousands or hundreds of thousands of images. An efficient architecture can reduce unnecessary work by using existing information about unchanged images and focusing analysis on what has changed.
Many organizations run applications across multiple cloud providers, private infrastructure and on premises environments. Vulnerability management needs to account for the environment that actually exists rather than assuming workloads are concentrated in one place.
Runtime reachability connects vulnerability information with evidence that the relevant package or library is loaded by the running application. It provides additional context for prioritization but does not by itself prove exploitability.
Vulnerability management identifies and prioritizes potential risk, but remediation takes time. Runtime security provides a control point where teams can reduce risk while applications continue to run.