Closed robmonct closed 1 year ago
Hi @robmonct. Thanks for the ticket. We upgraded many golang and docker dependencies recently but haven't done an official release. We used to dependabot to keep up with new versions and have recently switched to renovatebot.
I don't have access to GCP but could you scan the latest dev
image?
Related issues
Alpine images https://github.com/orgs/runatlantis/packages/container/atlantis
dev
- updated with every new PR mergelatest
- latest stable version currently v0.21.0
prerelease
- latest prerelease currently v0.22.0-pre.20221226
We recently also added debian support so feel free to scan those.
Please feel free to propose changes to resolve some of these issues.
Could you also go over some of these vulnerabilities? Some may not affect atlantis
For example,
Critical:
https://github.com/advisories/GHSA-8c83-vp4v-h7fq - resolved by using latest golang. We use go 1.19 in the latest release.
https://github.com/advisories/GHSA-xv38-944c-p763 - resolved by using latest golang. We use go 1.19 in the latest release.
https://github.com/advisories/GHSA-x24g-9w7v-vprh - resolved by latest go-getter. We use 2.1.1 in dev
image and 1.6.2 in the latest release.
https://github.com/runatlantis/atlantis/blob/de953fe25575ac2acd5709fd0dea26f946e3effc/go.mod#L3
https://github.com/runatlantis/atlantis/blob/de953fe25575ac2acd5709fd0dea26f946e3effc/go.mod#L23
Hi Thank you for the quick response. I've tried with dev, latest and prerelease and the list is the same. Debian versions have more vulnerabilities. Maybe, some of them may not affect atlantis. I've reported just for your information.
I don't understand why is showing the vulnerability with a newer version of Go. The information for critical one are this:
Thanks in advance.
That is quite bizarre. If you pay for support from gcp, I would contact them about it. Once you do, please follow up here so we know what the potential next steps are to improve the project.
If I'm not wrong, the problem is that you are building the new versions with this base:
ARG ATLANTIS_BASE=ghcr.io/runatlantis/atlantis-base
ARG ATLANTIS_BASE_TAG_DATE=2022.12.12
ARG ATLANTIS_BASE_TAG_TYPE=alpine
# Stage 1: build artifact
FROM golang:1.19.4-alpine AS builder
WORKDIR /app
COPY . /app
RUN --mount=type=cache,target=/go/pkg/mod \
--mount=type=cache,target=/root/.cache/go-build \
CGO_ENABLED=0 go build -trimpath -ldflags "-s -w" -v -o atlantis .
# Stage 2
# The runatlantis/atlantis-base is created by docker-base/Dockerfile
FROM ${ATLANTIS_BASE}:${ATLANTIS_BASE_TAG_DATE}-${ATLANTIS_BASE_TAG_TYPE} AS base
Then you are using as a base the image: ghcr.io/runatlantis/atlantis-base:2022.12.12-alpine which contains most of the vulnerabilities included in the dev and prerelease version. Is that possible?
You are correct that the atlantis-base
image (alpine, debian) is built first and then the atlantis
(alpine, debian) uses the respective base image.
However, the critical vulnerabilities (and other vulnerabilities) that you posted, many of them affect neither the latest code base (see dev
image) nor the latest released version (see v0.21.0
image). Many of those vulnerabilities are from older golang versions and I do not quite understand why gcp's container scan is flagging them.
I pointed the references to the code where the latest golang version is used.
Have you
atlantis
binary itself or its go.mod
which is built from the latest golang version?I don't understand neither why scan is showing them then. I didn't scan atlantis binary itself. The scan is in preview, so maybe they don't give support. I will try it just in case. Not yet.
I'm going to close this for now to avoid alarming anyone until there is a CVE that's affecting the current release.
Once you have more information, please respond and if there are action items, we can reopen the issue.
Scanning the current release with Snyk, this is the output just in case is useful:
Thank you @robmonct. The snyk scan looks a lot more actionable. The curl and git-lfs versions are about to be bumped in a contributed PR #2889.
Please feel free to propose changes to resolve any of the other issues raised here.
Some of these vulnerabilities are a bit odd again or seem to be "stale". It's possible that your local dev
image may be an older version?
https://github.com/runatlantis/atlantis/blob/e0f92e7e941fa18602927bfb84f1f1b6e4691111/go.mod#L47
These seems to be flagged appropriately. I did not do a full search. I only spot checked.
https://github.com/runatlantis/atlantis/blob/e0f92e7e941fa18602927bfb84f1f1b6e4691111/go.mod#L123
https://github.com/runatlantis/atlantis/blob/e0f92e7e941fa18602927bfb84f1f1b6e4691111/go.mod#L122
https://github.com/runatlantis/atlantis/blob/e0f92e7e941fa18602927bfb84f1f1b6e4691111/go.mod#L48
The YAML dependency is an open issue at the moment since it's difficult to get 1:1 results, at the moment, with the v2.
My dev image is yesterday dev image. I think the problem is related with this: https://stackoverflow.com/questions/69825533/why-does-go-sum-include-so-many-older-packages go.sum contains older versions even if they aren't being used and GCP and Snyk take them as a vulnerabilities. Is that possible? I'm trying to find how it's possible to remove those older versions from go.sum file.
@robmonct I'm unsure if that's the case. Some of the snyk issues you mentioned are actual issues which were just addressed today.
The dependencies you're referring to may be the // indirect
dependencies which come from other dependencies.
Please download a fresh dev
/ dev-alpine
image and scan.
The dev-debian
image is new and currently unused. It has more vulnerabilities most likely due to the fact that the debian
package repositories are slower to upgrade.
I wrote up a small issue here to help address more of these docker image dependency issues going forward https://github.com/runatlantis/atlantis/issues/2890. Please feel free to comment there on the process if you have suggestions.
Also the issues regarding older versions of terraform that snyk is flagging. We recently culled the 0.x versions from the container and the older 1.0.x, 1.1.x, 1.2.x, may be next to remove since terraform will auto download versions based on the hcl required_version
block.
Now that we know that security is flagging those, it may give more credence to the argument of only supporting the latest tf version.
I updated your comment here with summaries https://github.com/runatlantis/atlantis/issues/2883#issuecomment-1367241025
These ones out of scope
These ones in scope
The only remaining issues are in the debian
image which currently is set to only installing packages from its stable
repository. This limits it to older versions even if they are technically vulnerable such as curl
. We could install from unstable
but that may cause other issues.
For now, we are discussing using >=
pins in the Dockerfile.debian
image to keep more up to date. See PR https://github.com/runatlantis/atlantis/pull/2896. This will not resolve the current debian curl
issues (for example) but will allow us to upgrade sooner when those packages are available from the stable
repository.
cc: @jamengual
Thanks for your work @nitrocode I've downloaded the new dev version and this is the scan output:
A lot of these are out of scope unfortunately. Please see my previous post and my edit of your last scan. Also please edit your post so it's a bit more digestible (see previous edit).
The debian vulnerabilities are mostly from the binaries available from their stable repo unfortunately. If we downloaded from their unstable repo, we could avoid these vulnerabilities for debian but then we'd be trading stability for security.
The older terraform binaries are also out of scope.
Ok, thanks a lot for your work. Let's see if Hashicorp could fix those vulnerabilities but some of those versions seems to be a bit old. Do you think to offer a version of Atlantis with only Terraform 1.3.x and maybe another version with older TF versions to allow people between compatibility and security. Something like this: https://github.com/runatlantis/atlantis/pull/2901
I do not think they will fix the vulnerabilities in older versions of terraform.
May I ask, what is your current threat model? Why is it important to eliminate the older terraform version specific vulnerabilities from this container?
And I'd also like to remind that we encourage users to customize their own image so removing the tf binaries or any other customizations are welcomed and encouraged downstream. We want to make the maintenance and stability as easy as possible from our side.
The main problem is that GitHub doesn't provide the option to configure webhook headers, so it is not possible to use GCP IAP to protect the endpoint.
@robmonct wouldn't the github web hook with a secret token be sufficient enough?
No. For GCP IAP secret token isn't enough.
@robmonct please see this open issue regarding gcp iap. We can reopen that issue if it is needed or requires more documentation on the website
Community Note
Overview of the Issue
According with GCP vulnerabilities scan, Atlantis latest versions are affected by 3 critical, 36 high and 5 medium vulnerabilities
Additional Context