Risk Acceptance for Vulnerabilities

In modern cloud-native environments, organizations face a continuous stream of vulnerability findings across images, hosts, and workloads. Not every detected vulnerability poses an immediate or relevant risk. Many may be well-understood, mitigated by compensating controls, or otherwise non-actionable in a given context. Risk Acceptance enables security and DevOps teams to formally document and justify why certain vulnerabilities should not count toward policy violations or trigger enforcement actions.

Prerequisites

Risk acceptance can apply to all stages; Pipeline, Registry, Admission and Runtime. In order for Risk Acceptance to be properly respected in your environment and operate as expected, all minimum versions of the following components must be met:

Risk Acceptance in Vulnerability Management

By leveraging Risk Acceptance in Sysdig Vulnerability Management you can achieve the following:

  • Reduce alert fatigue by silencing known, well-understood, or mitigated vulnerabilities.
  • Document security decisions for auditability and compliance purposes.
  • Focus remediation efforts on vulnerabilities that are truly relevant to their environment and risk posture.
  • Allow well known and accepted issues on vulnerabilities, configurations, and other criteria into your workloads where absolutely necessary.

Accepted risks remain visible in the Sysdig platform, clearly labeled with the acceptance reason, scope and stages of acceptance.

Use Cases for Risk Acceptance

  • A vulnerability has been assessed as a false positive by the security team.
  • The vulnerability is not exploitable due to environmental or configuration factors.
  • A business-critical deployment requires postponing remediation, with risk formally documented.
  • Vulnerabilities are mitigated by other controls (e.g., network segmentation, runtime policies).

Accepting risk does not remove the vulnerability from scan results; it suppresses the related policy violation and clarifies why no action is currently required.

Risk Acceptance Entities

Risk acceptance in Sysdig Vulnerability Management can be scoped to several types of entities. The following list of entities are supported for Risk Acceptance and each has specific conditions Sysdig Vulnerability management can consider for flexible acceptance creations, follow the links for each to learn more.

EntityDescriptionExample
VulnerabilitiesA specific CVE identifierCVE-2023-12345
ImagesAll or specific vulnerabilities in a container imagenginx:1.23.1
HostVulnerabilities detected on a particular hosthost-123.acme.local
Policy RuleFindings from a specific vulnerability management policy ruleCritical Severity Only
PackagesA software package, by name, version, or pathopenssl@1.1.1 /usr/lib/openssl

Common Fields for Risk Acceptance

When creating or editing a risk acceptance, you must specify the following fields, regardless of the entity:

FieldDescriptionExample
WhereWhere you would like to accept the current context of the Risk Acceptance. Available options depend on the context of the risk acceptance, and include Global, Image, Host or Package. See Risk Acceptance Entities for more infoGlobal
StageWhere the acceptance is enforced: Pipeline, Registry, Runtime (Applies to Admission Controller), All Stages.Runtime
ReasonThe justification for accepting the risk. For more details, see Standard Risk Acceptance Reasons.Risk Mitigated
Additional DetailsFree-form notes or further justification for audit or documentation purposes.False positive, not applicable to my application.
Expires InDuration until the acceptance expires, after which enforcement resumes, allows for custom selection of date and additional default options.30 days

Risk Acceptance on Runtime stage also applies to the Sysdig Admission Controller evaluations of Kubernetes workloads and their associated Vulnerability Policy evaluations.

Risk Acceptance Reason Examples

  • Risk Avoided: Compensating controls exist that render the risk non-exploitable.
  • Risk Mitigated: The risk is mitigated through other means.
  • Risk Not Relevant: The vulnerability does not apply in this environment.
  • Risk Owned: The risk is accepted as-is by the organization.
  • Risk Transferred: The risk has been transferred (e.g., to a vendor).
  • Custom: User-defined reason.

Vulnerabilities

Accepting the Risk of a Vulnerability provides several scoping options and important considerations:

  • Global Acceptance: Accepting risk for a vulnerability globally means the selected CVE is accepted across your entire environment, regardless of where it appears. Use with caution, as this suppresses risk for all assets and workloads.
  • Image or Host Context: Accepting risk within a specific image or host restricts acceptance to those occurrences only.
  • Package Context: Accepting risk for a vulnerability on a specific package (by version or path) enables fine-grained targeting—ideal when risk is managed for that specific software component.

When you accept risk for a CVE on a container image, acceptance applies to all instances of that image, across all clusters and hosts. Consider your image re-use and deployment footprint before applying.

You can initiate vulnerability-based risk acceptance from the Pipeline, Registry, Runtime, and Findings views.

Interaction with Common Fields

  • Where: Choose the scope you wish to apply the Policy Rule Risk Acceptance.
    • Globally; apply across your entire environment.
    • Image you enable similar available to the Images options
    • Host you enable choices available to Hosts options.
    • Package you enable choices available to the Packages options.
  • Stage: As defined above in Common Fields for Risk Acceptance
  • Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance

Best Practice: Always use the most targeted scope appropriate for your use case to avoid unnecessarily broad exceptions.

Images

Accepting risk at the image level focuses acceptance on a specific container image and all its deployments:

  • When you accept risk on an image, all vulnerabilities matching your acceptance criteria for that image will be suppressed, regardless of where the image is deployed.
  • This is useful for images that are managed externally, regularly patched, or that have unique risk characteristics.

Interaction with Common Fields

  • Where: The Image scope you wish to apply the Risk Acceptance to, with 2 sub-obtions available.
    • This Image: The current Image you are initiating the Risk Acceptance from.
    • Image Name Contains Specified Value: Enables an additional field of Value to accept user input for a contains level match.
  • Stage: As defined above in Common Fields for Risk Acceptance
  • Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance

Best Practice: Only use image-level acceptance for images you control and monitor. If the same image is deployed across multiple environments, acceptance will apply everywhere.

Hosts

Risk acceptance at the host level is scoped to vulnerabilities detected on a specific host (VM or node):

  • This is appropriate for hosts with unique configurations, isolated workloads, or mitigations not present elsewhere.

Interaction with Common Fields

  • Where: The Host scope you wish to apply the Risk Acceptance to, with 2 sub-options available.
    • This Host: The current Host you are initiating the Risk Acceptance from.
    • Host Name Contains Specified Value: Enables an additional field of Value to accept user input for a contains level match on the Host name.
  • Stage: As defined above in Common Fields for Risk Acceptance
  • Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance

Best Practice: Host-based acceptance should be used sparingly. Review host-specific risk regularly, as host roles or workloads may change over time.

Policy Rules

Accepting risk for findings from a specific policy rule allows you to override enforcement when business requirements demand exceptions:

  • Use this when an automated policy is too restrictive or when compensating controls exist.

Interaction with Common Fields

Best Practice: Document the business or technical justification clearly, and review exceptions when policy logic changes.

Packages

Risk acceptance at the package level enables targeted suppression for a specific package (by name, version, or path):

  • Useful when a package is widely used but the risk is well understood and managed for a particular version or deployment path.

Additional Fields:

  • Version: The version of the specific package you wish to Accept as a Risk. There are 3 sub-options to choose from.
    • This Version: You can choose to specify the version of the package you have specifically started the Risk Acceptance on
    • Exact Version: match a string of an exact version detected, limisted between 2 and 256 characters. We do not validate the version against any known good practices so please use with caution.
    • Any Version: of the selected package.
  • File Path: The path of the package you wish to Accept as a Risk, there are 2 sub-options to choose from.
    • This File Path: The exact file path of the Package you have initiated the Risk Acceptance on
    • Any File Path: Any file path the package is detected on, use to accept any location of the affected package.

Interaction with Common Fields

  • Where: Choose the scope you wish to apply the Policy Rule Risk Acceptance. You can apply this Globally, or by choosing Image you enable similar available to the Images options and by choosing Host you enable choices available to Hosts options.
  • Stage: As defined above in Common Fields for Risk Acceptance
  • Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance

Best Practice: Regularly review package-level acceptances to ensure ongoing relevance, especially after upgrades or dependency changes.

Edit a Risk Acceptance

After a risk acceptance is created you can modify certain attributes.

You can edit the attributes Reason, Addtional Details, and Expiry Date.

You can edit a Risk Acceptance on the individual Scan Result for an Image, a Host, or on the Risk Acceptance page.