GitHub user ronak-sirwani created a discussion: Should frontend/UI build manifests (package.json, package-lock.json) be present in production Python images?
Context: I recently scanned our Airflow 3.0.6 deployment (using the official apache/airflow:slim-3.0.6-python3.12 image) and encountered a critical severity vulnerability flagged by Snyk in [email protected]. The Finding: The scanner pointed to this path: /home/airflow/.local/lib/python3.12/site-packages/airflow/api_fastapi/auth/managers/simple/ui/package.json Upon investigation inside the image, I found: - airlfow UI build Manifests: A package.json and package-lock.json (pinning the vulnerable [email protected]) exist in this directory. - No Code: The node_modules directory is correctly stripped, so the vulnerable code itself is missing. - Conflicting Lockfiles: A pnpm-lock.yaml is also present, which pins the safe version 4.0.4. I noticed that while the 'main' branch has updated package-lock.json to the secure form-data version, the underlying issue remains: why do we ship these files at all? I've little knowledge of the frontend build, but from a runtime perspective, these manifests appear to be "ghost" artifacts. Since node_modules are stripped and the UI is pre-compiled, keeping these files in the production image—even if patched—leaves the door open for future false positives whenever a frontend dependency (that isn't even installed) gets flagged. I am currently planning to patch our internal Docker builds by deleting package.json and package-lock.json to satisfy our security scanners, but I want to make sure I’m not breaking anything critical. Is there any specific runtime reason why these files must remain in the production image? Any insights or validation would be greatly appreciated! GitHub link: https://github.com/apache/airflow/discussions/59820 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
