FortiCNAPP Cloud Posture combines cloud configuration compliance, Kubernetes configuration compliance, and cloud activity violation policies to identify insecure configurations and governance drift across integrated cloud environments. Current FortiCNAPP provides built-in policies and compliance frameworks, supports custom policy creation through the console, API, CLI, or LQL-based YAML definitions, and offers consolidated dashboards for AWS accounts, Azure subscriptions, Google Cloud projects, OCI compartments, and Kubernetes clusters.
Within Fortinet Security Operations, cloud posture should be operated as a continuous control loop: discover the cloud estate, evaluate policy, prioritize risk, assign owners, manage exceptions, verify remediation, and report against the frameworks that actually matter to the organization.
FortiCNAPP Risk Prioritization provides the broader risk context across vulnerabilities, identities, exposure, and workloads.
Posture policy spans more than static configuration
Current FortiCNAPP posture policies include cloud configuration compliance policies, Kubernetes configuration compliance policies, and cloud activity violation policies.
Static misconfiguration and suspicious control-plane activity are related but different risk signals.
Use policy type to keep remediation ownership clear: infrastructure teams fix insecure state, while SecOps may investigate an unexpected activity violation.
Built-in policies provide a broad baseline
FortiCNAPP ships numerous built-in compliance and violation policies.
Use them to establish broad coverage quickly, then tune/customize for the organization’s cloud architecture and risk appetite.
Do not enable every framework equally; too many overlapping compliance views can create duplicated findings without improving security.
LQL policies make detection logic portable and reviewable
Many FortiCNAPP posture policies use Lacework Query Language (LQL), and the platform supports creating or modifying policies through YAML with the CLI/API.
Store custom policy definitions in source control, review changes, and deploy consistently across environments.
Non-LQL policy types use condition-based rules, so maintain documentation that identifies which authoring model each policy uses.
Compliance dashboards are assessed daily and on demand
Current Cloud Compliance Dashboard provides daily assessments and allows supported on-demand rescans subject to timing limits.
Use the “last run” and assessment status to verify current visibility.
A compliance percentage is meaningless if the cloud integration has not assessed recently or a scan is failing.
Frameworks should reflect the audience
FortiCNAPP includes policy frameworks based on benchmarks and standards such as CIS and other industry/regulatory sets.
Current documentation recommends thinking about the report audience: cloud security teams may care about CIS baseline, while compliance teams may need one or two specific regulatory frameworks.
Use custom frameworks to group policies around the controls the organization actually owns and reports.
Policy severity should not be the only prioritization input
The dashboard categorizes policies by severity and affected/compliant/non-compliant resources.
Combine severity with internet exposure, resource criticality, identity privilege, sensitive data, exploitability, and recurrence.
One critical policy on a disposable test resource may matter less than a high-severity issue that creates an attack path to production secrets.
Exceptions need owner, reason, and expiry
FortiCNAPP supports policy exceptions, and compliance reporting can treat resources with full exceptions as compliant in some views.
That makes exception governance essential: an unreviewed blanket exception can improve the dashboard while leaving the risky configuration unchanged.
Record business justification, compensating control, exact resource/scope, owner, and expiration date.
Kubernetes posture should be reviewed separately
FortiCNAPP provides a dedicated Kubernetes Compliance Dashboard with daily assessments for integrated clusters.
Kubernetes misconfiguration has different owners and remediation paths from cloud-account configuration.
Track cluster admission/RBAC/network/workload policy alongside cloud IAM/network/storage posture instead of collapsing everything into one generic cloud score.
Reporting should drive remediation, not audit theater
FortiCNAPP can generate and distribute compliance/posture reports based on configured frameworks.
Reports should identify affected policies/resources, trends, owners, and aging so engineering can act.
Schedule management reports around decision cycles, but use live dashboards/issues for operational remediation rather than waiting for a monthly PDF.
Posture changes should feed infrastructure-as-code
Recurring findings should be fixed in Terraform, CloudFormation, Bicep, Kubernetes manifests, CI policies, or landing-zone templates where possible.
Closing individual findings manually without changing the creation path guarantees recurrence.
Track repeat violations by resource type and policy to identify which platform guardrail is missing.
FortiCNAPP Cloud Posture succeeds when compliance evidence and attack-surface reduction reinforce each other
The mature program keeps cloud/Kubernetes integrations complete, runs current assessments, uses relevant frameworks, versions custom policies, governs exceptions, prioritizes by context, and pushes recurring fixes into IaC.
Posture management creates security value when dashboards lead to fewer risky configurations—not merely higher reported compliance percentages.
Cloud integration permissions should be least privilege and monitored for drift. FortiCNAPP needs enough read/access capability to inventory and assess resources; additional capabilities may be required for other CNAPP functions. Review provider role/service-account changes after onboarding so a security platform connector does not accumulate broad write privileges simply because teams enabled more features.
Asset inventory coverage should be reconciled with organization/account-management systems. Compare AWS Organizations accounts, Azure management groups/subscriptions, GCP organizations/projects, and OCI compartments with FortiCNAPP integrations. A missing account can make posture percentages improve while the unmonitored environment contains the highest-risk resources.
Policy customization should preserve vendor updates. Clone or create organization-specific policies instead of modifying a baseline in a way that prevents understanding FortiGuard/FortiCNAPP content changes. Store YAML/LQL in source control, test against representative accounts, and document why the custom policy exists beyond the built-in baseline.
Cloud activity violation policies should have an incident-response path. A posture engine that detects suspicious control-plane behavior—such as unusual configuration changes—can indicate active compromise rather than static drift. Route these alerts to SecOps with cloud identity, source, resource, and activity context instead of sending every violation to a compliance backlog.
Compliance exceptions should be excluded only at the smallest resource scope possible. If one service legitimately cannot meet a benchmark, exempt the exact resource or condition rather than the entire account or policy. Broad exceptions create misleading compliant scores and hide new resources that repeat the same misconfiguration without the original business justification.
Custom frameworks should avoid duplicating dozens of near-identical policies. Map each technical policy once to the organizational control set and generate different reports/views for auditors, engineering, and leadership. This reduces remediation confusion when one misconfiguration appears as five separate compliance failures across overlapping frameworks.
Posture data should be trended, not viewed as a snapshot. Track non-compliant resources created, remediated, reopened, and aging by policy/owner/account. A stable 95% compliance score can hide constant churn where teams create risky resources as fast as security fixes them.
Cloud-security ownership should be derived from tags, account hierarchy, resource metadata, and CMDB/application mapping. Findings without owners become central-security toil. Enforce owner/environment tags in landing zones so FortiCNAPP issues can route automatically to the team capable of fixing the resource.
High-severity findings should be enriched with FortiCNAPP risk context before emergency escalation. Combine posture failure with vulnerability, identity, exposure, data, runtime, and activity risk where available. This prevents the SOC from treating every Critical benchmark violation as equal and focuses response on configurations that form plausible attack paths.
Platform teams should use recurring posture findings as feedback into preventive policy such as cloud-native org policies, SCPs, Azure Policy, GCP Organization Policy, Kubernetes admission, and IaC guardrails. FortiCNAPP then becomes both detective evidence and a measurement layer showing whether preventive engineering reduces recurrence.
Scan-now workflows should be used after high-impact remediation or landing-zone changes rather than waiting for the next daily assessment. Current FortiCNAPP limits immediate rescans when a scan is already running or completed too recently, so operational runbooks should account for assessment cadence before declaring a fix verified.
Compliance dashboards should distinguish ‘could not be assessed’ from ‘compliant.’ Unknown assessment state is not a pass. Track unassessable resources and integration errors separately because missing permissions or unsupported configurations can hide risk behind incomplete coverage.
Historical assessment views can show whether posture improves over time. Use past framework/account results to demonstrate sustained remediation rather than one good current snapshot after a cleanup campaign. Recurrence trends often reveal which teams need better preventive controls.
Reports should be tailored by cloud/provider because current custom frameworks are constrained by cloud type. Build comparable control objectives across AWS/Azure/GCP while accepting that technical policy implementation differs. Management can then compare risk themes without forcing identical provider-specific checks.
Policy ownership should distinguish platform controls from application exceptions. Central cloud teams may own organization-wide encryption, logging, IAM, and network policies, while application teams own resource-specific exceptions. Routing violations to the correct layer shortens remediation and prevents central security from fixing symptoms that should be solved in a shared landing-zone module.
Posture programs should define service-level targets for critical findings, recurring high-risk violations, and exception review. Measure median/95th-percentile age by severity and business unit, not only closure count. Long-lived misconfigurations indicate that ownership or preventive controls are failing even when the dashboard’s overall compliance percentage looks acceptable.
FortiCNAPP integrations should be validated after cloud-provider API or permission changes. If an organization tightens SCPs, Azure roles, GCP service-account permissions, or Kubernetes RBAC, ensure FortiCNAPP can still assess the intended resources. Monitoring integration health is part of posture accuracy.
Posture findings should be tied to reachable attack paths and accountable owners. Prioritizing every misconfiguration equally creates fatigue; combining exposure, privilege, asset value, exploitability, and remediation evidence helps teams focus on changes that materially reduce risk.
