Docker Image CVEs about spiff-arena HOT 4 CLOSED

We have overhauled our security scanning that occurs at build time. We added a pile of snyk actions that are now scanning both frontend and backend, docker images, libraries, and code. Previously we had been scanning just backend libraries. A number of issues were surfaced, and we have fixed a number of them. We will continue to make progress on this over time, but the framework now exists. Thank you very much, @tedpatrick ! Are you unblocked? :)

from spiff-arena.

@tedpatrick , thank you very much for the report. we definitely don't want to see security concerns stopping anyone from using Spiff. We take these issues very seriously. We've been lucky to have had the opportunity for multiple third parties to review the source code, and we have mitigated all concerns. We do run snyk in CI, https://github.com/sartography/spiff-arena/actions/runs/6509463582, but there is an obvious gap here in our security scanning automation, and we will look to close that up rapidly. In the meantime, the base image has been updated, and the resulting image has 322 fewer vulnerabilities. There is one critical vulnerability, and no high severity issues, according to docker scan. The critical vulnerability, https://security.snyk.io/vuln/SNYK-DEBIAN12-NGHTTP2-5953379, was earned through apt-get install curl and unfortunately "There is no fixed version for Debian:12."

The Dockerfiles in question are:

• https://github.com/sartography/docker-python/blob/main/Dockerfile aka ghcr.io/sartography/python:3.11
• https://github.com/sartography/spiff-arena/blob/main/spiffworkflow-backend/Dockerfile aka ghcr.io/sartography/spiffworkflow-backend:latest / ghcr.io/sartography/spiffworkflow-backend:main-2023-10-14_03-32-24 / ghcr.io/sartography/spiffworkflow-backend:v0.0.45

If you see any opportunity to improve the Dockerfiles, or if the image is still not meeting expectations, please let us know. If it would be easier to discuss synchronously, please reach out via our website or discord.

I'm going to leave this issue open until checks have been added to our CI process.

Thank you again for bringing this to our attention. 🙇

from spiff-arena.

Thanks for the great response. This is one of those hard ongoing problems.

The base python docker images are a great base but we found we got more control building it up ourselves.

# builder image.
FROM {AWS_ACC}.dkr.ecr.us-east-1.amazonaws.com/server:builder_1 as builder
COPY apps/server/api/locks/environment-linux-64.txt /locks/environment-linux-64.txt
RUN conda-lock install -p /opt/env --copy /locks/environment-linux-64.txt

# platform image.
FROM --platform=linux/amd64 debian:bookworm-slim
COPY --from=builder /opt/env /opt/env

ARG APP_DIR
ARG SHARED_DIR

ENV PATH="/opt/env/bin:${PATH}"

WORKDIR /app

# Copy the shared and application code
COPY ${SHARED_DIR} /app/shared
COPY ${APP_DIR} /app

CMD ["uvicorn", "server.app:app", "--host", "0.0.0.0", "--port", "80", "--proxy-headers"]

This one used a builder with conda-lock to build a python+deps from conda-forge, then the environment is copied into a clean base image using debian:bookworm-slim. The builder allows you to keep any dev tools out of the production image.

Builder Dockerfile:

FROM continuumio/miniconda:latest as builder
COPY /locks/environment-linux-64.txt /locks/environment-linux-64.txt
RUN conda create -p /opt/builder --copy --file /locks/environment-linux-64.txt
ENV PATH="/opt/builder/bin:${PATH}"

Builder environment.yml

name: builder
channels:
  - conda-forge
  - defaults
dependencies:
  - conda-lock=2
  - python=3.11.2

Builder build.sh for Lockfile generation - These solve the environment offline targeting specific platforms

rm -rf locks
mkdir locks

# prod linux-64
conda-lock -f environment.yml --mamba --platform linux-64 --kind explicit
mv conda-linux-64.lock ./locks/environment-linux-64.txt

Again, this is a hard problem, great to see a proactive posture around security.

Ted :)

from spiff-arena.

Updated Scan. Looks to be mostly system tools with outstanding CVEs now.

from spiff-arena.