FortiCNAPP runtime risk combines what is installed, exposed, executing, communicating, and behaving abnormally in cloud workloads so teams can prioritize issues that are actually active rather than treating every vulnerable package or misconfiguration as equal. Current FortiCNAPP correlates host and container vulnerabilities with internet exposure, active package usage, attack paths, identity relationships, workload behavior, and Polygraph anomaly alerts. The platform’s current documentation explicitly distinguishes static risk from runtime evidence such as whether a vulnerable package is active and whether an asset is exposed to the internet.
Within Fortinet Security Operations, runtime risk is the operational layer between posture and incident detection. FortiCNAPP Cloud Posture identifies configuration and compliance weaknesses; runtime context helps answer which weakness is part of an active workload, reachable attack path, or anomalous behavior today.
The related FortiCNAPP Risk Prioritization article covers the current risk-score model. This page focuses on the runtime evidence that should change response priority.
Active package detection separates installed from executing risk
FortiCNAPP’s current active package detection—also called Active Vulnerability Detection or Code Aware Agent in parts of the console—shows whether a vulnerable package is actually used by a process on supported Linux hosts and containers.
The feature is disabled by default and requires the FortiCNAPP agent; a package becomes active when a process executes a file belonging to that package.
This lets teams prioritize a critical vulnerability in a package currently executing over the same package sitting unused on a host, without pretending inactive means harmless forever.
Inactive is a prioritization signal, not a remediation exemption
Current documentation treats a vulnerable package as inactive when no process has accessed files from the package during the recent activity window.
That can justify lower urgency, but software may become active later after configuration, feature enablement, or a new workload path.
Keep vulnerability ownership and patch planning even when runtime evidence temporarily lowers priority.
Internet exposure changes the risk story materially
FortiCNAPP can identify internet exposure for supported cloud assets using resource configuration and reachability context.
An asset that is internet exposed, runs an active vulnerable package, and has a public path should rank higher than the same vulnerable package behind isolated internal routing.
Use the exposure filter and polygraph together rather than relying on CVSS alone.
Exposure Polygraph makes the path visible
The Exposure Polygraph visualizes how the internet can reach an instance or container image and overlays risk factors such as vulnerabilities, secrets, compliance violations, and network path details.
This is useful for explaining risk to application teams because the remediation conversation becomes “this path reaches this vulnerable workload” instead of a generic scanner finding.
Prioritize changes that break high-leverage paths—public exposure, excessive identity, or a critical active package—rather than fixing low-impact items first.
Behavioral analytics adds compromise context
FortiCNAPP Polygraph builds a model of normal relationships among users, resources, applications, processes, containers, and network activity and alerts on meaningful deviations.
Current examples include new users, new binaries, privilege escalation, new external connections, new parent processes, and connections to known-bad infrastructure.
These alerts can indicate that a posture weakness has moved from theoretical exposure to suspected compromise.
Agent and agentless coverage should be understood separately
FortiCNAPP supports agent-based workload security and agentless workload scanning for supported host/container environments.
Agentless scanning gives fast coverage for vulnerabilities and workload state, while agent-based telemetry provides deeper runtime information such as process behavior, file integrity, active packages, and host-based threat detection.
Document which asset classes receive which level of runtime evidence so “FortiCNAPP onboarded” does not imply identical detection depth everywhere.
Container runtime context should link image and active container
FortiCNAPP scans container images for vulnerable OS and language packages and correlates those images with containers running in the monitored environment.
A critical vulnerable image that is not deployed is different from one running hundreds of internet-facing pods.
Use repository/image hash, active container count, namespace, cluster, exposure, and active package information to direct remediation toward the deployment that creates real risk.
Risk queries should combine several factors
Current FortiCNAPP Explorer workflows demonstrate queries such as high-risk production hosts with active packages, active exploits, internet access, and identity relationships.
This is the right operational model: combine environment, vulnerability, exploit evidence, runtime activity, reachability, and blast-radius context.
One-dimensional queues sorted only by severity leave analysts chasing the largest number rather than the most exploitable path.
Suppressions must remain narrow
Behavioral anomaly policies can be cloned and scoped with exclusions for known benign activity.
Use suppression only for specific host, IP, port, resource, region, service, or user patterns that have a documented reason.
A broad suppression can hide a future attacker who deliberately reuses an allowed automation pattern or service account.
Runtime risk should feed the SOC, not stay inside vulnerability management
When behavioral alerts indicate suspicious execution, identity use, or network behavior, route them into incident handling rather than leaving them as vulnerability remediation tasks.
Threat Detection and Incident Workflows provides the wider model for deciding when a risk signal becomes an investigation.
Preserve host/container/process/network evidence early because ephemeral workloads can disappear before manual analysis begins.
FortiCNAPP runtime risk succeeds when static findings gain operational context
The mature program knows which vulnerable packages are active, which assets are reachable, which images are running, which identities increase blast radius, and which behaviors are anomalous. It uses those factors to drive urgency, routes suspected compromise into SecOps, and keeps suppressions narrow.
Runtime context should help the organization fix the vulnerabilities most likely to matter first without losing track of the longer remediation backlog.
Runtime-risk design should distinguish a vulnerability that is active from a workload that is compromised. Active package detection tells you software is being used; it does not prove the vulnerable code path was exploited. Pair package activity with anomalous process, file, identity, and network signals before escalating a vulnerability directly into an incident. This keeps urgency high without collapsing vulnerability management and threat detection into one undifferentiated queue.
FortiCNAPP currently supports active package detection on Linux hosts and containers, with documented limitations for some environments such as Fargate where agent privilege is insufficient for file-system monitoring. Coverage reports should therefore show which workloads can generate active-package evidence and which cannot. An absence of ‘active’ status is not meaningful if the feature is unsupported or was never enabled on that workload.
The platform’s current risk scoring runs on a scheduled cycle, while some runtime observations and alerts arrive more quickly. Operations should know which views are near real time and which reflect the latest scheduled calculation. During an incident, do not wait for a daily score refresh if process or Polygraph evidence already shows a high-confidence suspicious behavior that requires response.
Runtime prioritization should include production context. Use tags such as environment, business service, data class, owner, and criticality so a vulnerable active package on a public production API ranks above the same package inside an ephemeral developer sandbox. Tags are only useful when the organization enforces their accuracy through cloud landing zones and deployment pipelines.
Attack-path analysis should be treated as a graph, not a single severity. One workload can be indirectly reachable through another compromised asset, a powerful identity, or exposed data service. Remediation can break the path at several points: close the public route, reduce IAM privilege, patch the active package, rotate a secret, or isolate the workload. Choose the action that reduces risk fastest with the least business disruption.
Runtime anomaly investigation should preserve the baseline context that made the activity unusual. A new parent process, new outbound destination, or new privilege escalation may be legitimate after a software release. Correlate the alert timestamp with deployments, configuration changes, user activity, and maintenance. The behavioral model is a strong lead, not a substitute for understanding planned operational change.
File and registry integrity signals are particularly useful for servers where the application binary should change only during controlled releases. Unexpected file creation, modification, or registry change can indicate persistence or tampering. Link these alerts to the CI/CD deployment record so responders can quickly distinguish an authorized release from a change that occurred outside the expected pipeline.
Runtime-risk exception handling should expire automatically where possible. A vulnerability may be deprioritized because the package is inactive today or a network path is temporarily closed, but that condition can change after a deployment. Require the owner to revalidate the runtime assumption on a schedule or when the image, package, security group, identity, or exposure changes.
Metrics should show how much prioritization actually changes outcomes. Track the percentage of critical vulnerabilities that are active, internet-exposed, exploitable, or on attack paths; time-to-remediate for those groups; and the number of runtime alerts tied to previously known vulnerabilities. If every issue still receives the same SLA, the runtime context is being collected but not used operationally.
Runtime-risk response should preserve ephemeral evidence. Containers can restart, pods can reschedule, and autoscaling can terminate compromised instances. Capture container/image ID, pod/namespace, process tree, command line, network connections, identity, cloud audit events, and relevant alerts before the workload disappears.
Agent rollout should be governed by performance and privilege. Privileged agents on Kubernetes nodes provide deeper host/container visibility but have broader access than non-privileged container deployments. Choose the deployment mode deliberately, monitor resource overhead, and document which runtime features are unavailable when a less-privileged model is selected.
