Fix Pillow CVE in foundation-model-serve environment (bump to 12.2.0)

[Copilot]

Close remediation loop: transitive fixes, build-break repair, single tagged PR

• Add scripts/environment/resolve_and_audit.py helper — resolves transitive set, audits, classifies into parent_bump / transitive_pin / residual, surfaces ResolutionImpossible. Semver-aware minimum-fix selection (via packaging.version.Version). Passes flake8, pydocstyle, and the repo's own validators.
• Extend fm-serve-vuln-audit.yaml:
  • workflow_dispatch inputs repair_mode (build-break / post-scan) and repair_attempt; runaway-cap guard.
  • Repair passes check out the existing auto branch and commit on top of the open PR.
  • Stage-2 transitive sweep loop (max 3 iterations) that appends transitive pins with # CVE-xxxx transitive pin; drop when … markers.
  • reasoning.md now includes Residuals, resolver-conflict, repair-pass, and merge-gate sections; new transitive-summary.json artifact; security/auto-remediation label; stable auto/fm-serve-vuln-audit branch (no delete-branch).
• Extend fm-serve-vuln-audit-postbuild.yaml:
  • ems-scan runs only on CI success; emits summary.json (totals + fixable_severe); Trivy column labelled "Fixed (suggested)"; merge-gate line added.
  • On HIGH/CRITICAL > 0, dispatches the audit workflow in post-scan repair mode against the same branch.
  • New repair-on-failure job: fires on environments-ci failure on an auto branch, counts prior 24h repair-pass runs, dispatches build-break repair or posts a "cap reached" @-mention to the reviewer.
  • Added actions: write permission to allow workflow dispatch.
• Validation: YAML + embedded-Python syntax, flake8, pydocstyle, repo validators all green.
• Address code review: use packaging.version.Version for minimum-fix selection so min("2.0.0", "10.0.0") picks 2.0.0 (covered by a smoke test).

[github-actions]

Test Results for assets-test

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 90a32e6.

♻️ This comment has been updated with latest results.

[pabhatia-ms]

@vizhur can you provide thumsup for this.

I have a quick query, these scan changes are againts gh advisory db, once we publish this to registry is this DB synced with CVE in the registry vulnerability scans ?

[vizhur]

can't the same be achieved with unpinned dependencies? is there a validation if dependencies are compatible? what about nested dependencies

[pabhatia-ms]

can't the same be achieved with unpinned dependencies? is there a validation if dependencies are compatible? what about nested dependencies

@vizhur keeping the pinned version I see will help:

1. rebuild the exact changes locally and test if needed on say CI.
2. pinning helps to know the version in case of code dependency failing at runtime, otherwise need to figure out what is present in container.
   I have added limits and checks for transitive, I hope to try this out and updates max values based on experiments.

[vizhur]

I don't see a value of the pipeline. Pinning changes can go through. You may want to create a pipeline/agent outside of this repo, that would get the findings for the latest image, build context from release branch, confirm the fix is actually needed. Build an image with proposed changes, check for vulnerabilities using our internal tool, issue a PR.