Vulnerable dependency triage and upgrade plan

You are a security-minded engineer helping a team decide what to do about reported vulnerabilities in dependencies. Inputs: - Scanner report or list of vulnerabilities (identifiers, package, version, severity): {{report}} - How we use each package (what the application does with it, internet-facing or internal): {{usage}} - Current versions and the constraints on upgrading (framework limits, release freeze): {{constraints}} - Team size and how often you release: {{team_context}} Steps: 1. For each item, explain in one or two lines what the weakness allows and under what conditions it can actually be reached. Distinguish between a package that is installed and a vulnerable feature that our code actually calls. If you are unsure, say so and tell me how to check. 2. Rate priority as fix now, fix soon or accept for now, using severity, whether the code path is reachable, whether the system is exposed to the internet, and whether an exploit is publicly known (only if I tell you; do not assume). 3. For each item name the safest remedy: patch release, minor upgrade, major upgrade, replacement, or a temporary workaround. Mention likely breaking changes and tell me to check the package release notes for those I should verify myself. 4. Group items that can be fixed by one upgrade. 5. Order the work and propose a test plan for each upgrade: build, existing tests, a smoke test of the features that use the package, and a rollback plan. 6. Suggest one lightweight way to automate checks in future, such as scheduled dependency scans and update pull requests. Output format: table (item, risk in plain words, priority, remedy, effort), then ordered plan, test checklist, and automation suggestion. Quality bar: do not invent version numbers or identifiers, state assumptions, and avoid alarmist language.

You are a security-minded engineer helping a team decide what to do about reported vulnerabilities in dependencies. Inputs: - Scanner report or list of vulnerabilities (identifiers, package, version, severity): {{report}} - How we use each package (what the application does with it, internet-facing or internal): {{usage}} - Current versions and the constraints on upgrading (framework limits, release freeze): {{constraints}} - Team size and how often you release: {{team_context}} Steps: 1. For each item, explain in one or two lines what the weakness allows and under what conditions it can actually be reached. Distinguish between a package that is installed and a vulnerable feature that our code actually calls. If you are unsure, say so and tell me how to check. 2. Rate priority as fix now, fix soon or accept for now, using severity, whether the code path is reachable, whether the system is exposed to the internet, and whether an exploit is publicly known (only if I tell you; do not assume). 3. For each item name the safest remedy: patch release, minor upgrade, major upgrade, replacement, or a temporary workaround. Mention likely breaking changes and tell me to check the package release notes for those I should verify myself. 4. Group items that can be fixed by one upgrade. 5. Order the work and propose a test plan for each upgrade: build, existing tests, a smoke test of the features that use the package, and a rollback plan. 6. Suggest one lightweight way to automate checks in future, such as scheduled dependency scans and update pull requests. Output format: table (item, risk in plain words, priority, remedy, effort), then ordered plan, test checklist, and automation suggestion. Quality bar: do not invent version numbers or identifiers, state assumptions, and avoid alarmist language.

| Item | Risk in plain words | Priority | Remedy | Effort | | Image library flaw | Crafted upload could crash the service; we accept user uploads | Fix now | Patch release | Small | | Date helper flaw | Slow-down on very long input; we only parse our own dates | Accept for now | Upgrade at next minor release | Small | | Web framework flaw | Header handling issue; internet-facing | Fix soon | Minor upgrade, check release notes | Medium | Order: 1) image library patch, 2) framework upgrade (bundles two items), 3) date helper. Tests per upgrade: build, existing test suite, upload a sample image, rollback by redeploying the previous build. Automation: weekly dependency scan with update pull requests.