How do you handle libraries that Veracode flags but we can't upgrade?

We've been running Veracode SCA (Software Composition Analysis) in our CI/CD pipeline for several months. While it's excellent at surfacing vulnerabilities, we consistently hit a major operational snag: **libraries flagged as critical/high severity that we cannot immediately upgrade.**

Common scenarios in our enterprise environment:
* A flagged library is a deep transitive dependency of a major framework (e.g., something pulled in by Spring Boot).
* The library is "vendor-locked" by a third-party commercial SDK we must use.
* The "fixed" version isn't actually available yet, or the upgrade path requires a breaking change we can't absorb this quarter.

Our current process feels clunky. We manually suppress findings in the Veracode portal after a Jira ticket is created, which breaks our "everything-as-code" flow and creates audit trail gaps.

I'm interested in how others automate the triage and governance of these unavoidable exceptions. Specifically:

* **Pipeline Handling:** Do you fail the build on new critical findings, or only on an increase in severity score? What's your gate rule?
* **Exception Workflow:** How do you track and approve unavoidable exceptions *outside* the Veracode UI? We're considering embedding a `veracode-exceptions.yaml` file in the repo that our pipeline script checks.
* **Mitigation Documentation:** When you suppress a finding, what evidence do you require? Common answers we document are:
* CVE is a false positive for our usage pattern.
* Upgrade path blocked by incompatible dependency `X`.
* Risk accepted until `Y` date, with compensating controls (e.g., WAF rules).

Here's a rough example of the YAML approach we're prototyping for pipeline integration:

```yaml
# veracode-exceptions.yaml
accepted_findings:
- cve: "CVE-2021-44228"
library: "log4j-core-2.14.1"
justification: "Upgraded to 2.17.0 in Q2 roadmap. Mitigated via environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true."
ticket: "SEC-445"
valid_until: "2024-06-30"
- cve: "CVE-2023-12345"
library: "vulnerable-lib-1.2.3"
justification: "Transitive dependency from vendor SDK v5.2. Vendor patch scheduled for Q3."
ticket: "VENDOR-789"
valid_until: "2024-09-01"
```

Does anyone have a more elegant solution? How do you balance security enforcement with practical development velocity when upgrades aren't immediately feasible?