# List of ignored known vulnerabilities
#
# Keep this file in sync with deny.toml
#
# When osv-scanner reports a vulnerability, evaluate if the vulnerability affects the security
# of our app. If it does, escalate the issue and discuss in the team and with tech leadership.
# If the vulnerability does *not* affect the security of the app, there are three ways to fix it.
# Here they are listed in priority order:
#
# 1. Try to upgrade the dependency to a version that does not have the vulnerability.
#    If possible and does not come with too many other downsides, this is always recommended.
# 2. If upgrading is not feasible and the vulnerability does not affect the security of our app,
#    it can be ignored with an `IgnoredVulns` entry. See below for rules.
# 3. If one package has very many vulnerabilities or a constant stream of new vulnerabilities
#    found, and they are never a threat to our app's security, the entire package can be ignored
#    with a `PackageOverrides` entry. See below for rules. This should be avoided if feasible.
#
# Every ignored vulnerability/package entry must have an end date. It is not allowed to ignore
# vulnerabilies indefinitely. This means specifying an `ignoreUntil` for `IgnoredVulns` entries
# and `effectiveUntil` for `PackageOverrides` entries.
# * The default should be to ignore a vulnerability for three months.
# * A vulnerability can be ignored for up to a year at most (Use extremely sparsely).
# * If anything above three months is used, write a short comment about why this ignore is longer,
#   and add it as a comment after the `ignoreUntil` line for the entry.
#
# Every entry must have a `reason` field that explains why this vulnerability does not affect us,
# and why we can't/decided not to change to an unaffected version.
#
# Try to use the "original" identifier as `id` in `IgnoredVulns`. This means the identifier used
# by the original vulnerability database it originates from.
# These are usually listed as "Aliases" on osv.dev.
# Feel free to add more identifiers as comments after the `id`.
#
# Write a comment above each entry specifying what dependency it is about and what type of
# vulnerability it is. The other fields do not convey this.
#
# Remove the ignore as soon as we upgrade or otherwise get rid of the vulnerable dependency from
# our product.
#
# When an `ignoreUntil`/`effectiveUntil` expire and start yielding errors on a previously ignored
# issue, follow these steps:
# 1. Try to upgrade away from the vulnerable versions and get rid of the ignore.
# 2. Update any outdated info in this ignore.
# 3. Bump the `ignoreUntil` following the same rules as when initially adding an ignore entry.
#
# Example `IgnoredVulns` entry:
#
# ```
# # libbaz remote code execution in get_date() function
# [[IgnoredVulns]]
# id = "CVE-2020-12345" # GHSA-abcd-efgh-1234
# ignoreUntil = 2024-12-05 # Ignored for six months at a time. Unlikely to be fixed, but also unlikely to be an issue for us.
# reason = """
# The vulnerable code path is currently not triggered by us or our dependencies.
# `renderer-helper` currently depend on this version of libbaz, preventing us from upgrading to a fixed version.
# """
# ```
#
# Example `PackageOverrides` entry:
#
# ```
# # Entire package ignored since there is a constant stream of newly found regular expression attacks.
# # All of these attacks rely on the input being malicious. We only use this package in our trusted
# # build environment with trusted inputs.
# [[PackageOverrides]]
# name = "rexml"
# ignore = true
# effectiveUntil = 2024-11-02
# reason = "The XML payload is generated by Apple tooling which we trust"
# ```