-
-
Notifications
You must be signed in to change notification settings - Fork 616
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Official Bandit Images #1088
Changes from all commits
ef645de
8c96d06
2b2beca
9e97dd2
475408c
5aab55a
91ae422
8d6dcf6
69d4c68
50ce0c9
70ebbc9
4ed7858
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
name: Build and Publish Bandit Images | ||
|
||
on: | ||
release: | ||
types: [created] | ||
schedule: | ||
- cron: '0 0 * * 0' # Every Sunday at midnight | ||
workflow_dispatch: | ||
|
||
jobs: | ||
build-and-publish: | ||
runs-on: ubuntu-latest | ||
permissions: | ||
contents: read | ||
packages: write | ||
id-token: write | ||
|
||
steps: | ||
|
||
- name: Get latest release tag | ||
if: github.event_name != 'release' | ||
id: get-latest-tag | ||
run: | | ||
TAG=$(curl -s https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r .tag_name) | ||
echo "Latest tag is $TAG" | ||
echo "RELEASE_TAG=$TAG" >> $GITHUB_ENV | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've never seen this construct before, is it possible that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a pretty standard approach for setting key values in actions: https://github.com/lukehinds/testrepo/actions/runs/7612691776/job/20730842060 |
||
|
||
- name: Check out the repo | ||
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4 | ||
with: | ||
ref: ${{ github.event_name == 'release' && github.ref || env.RELEASE_TAG }} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if after this we should set something up for adding to the docker image as a label. But we can probably do that as a fast follow to this change |
||
|
||
- name: Set up Docker Buildx | ||
uses: docker/setup-buildx-action@f95db51fddba0c2d1ec667646a06c2ce06100226 # v3 | ||
|
||
- name: Log in to GitHub Container Registry | ||
uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d # v3 | ||
with: | ||
registry: ghcr.io | ||
username: ${{ github.actor }} | ||
password: ${{ secrets.GITHUB_TOKEN }} | ||
|
||
- name: Install Cosign | ||
uses: sigstore/cosign-installer@9614fae9e5c5eddabb09f90a270fcb487c9f7149 # v3.3.0 | ||
with: | ||
cosign-release: 'v2.2.2' | ||
|
||
- name: Build and push Docker image | ||
id: build-and-push | ||
uses: docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f42f56 # v5 | ||
with: | ||
context: . | ||
file: ./docker/Dockerfile | ||
push: true | ||
tags: ghcr.io/${{ github.repository }}/bandit:latest | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can specify a list here, do we want to try to do that? For example, we could do use the current date too so that we're tagging both latest and the current date, e.g., There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also don't see us including the version of Bandit here but maybe that's because we are using the same action on a schedule and for releases? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, also, if we're doing this on a schedule like this, does that mean we're publishing the head of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is actually a very good point, with a schedule we end up pushing main and not a release (I am not at my best this morning!). Let me dwell on if there is a better method for this (I am not sure there is) unless we get into trying to predict what the last release was There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also thought it best to not use bandit releases, latest should always be usable. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder, also if we want to add labels here to the image, e.g., If we're running a schedule, could we find the latest tag, check that out and rebuild? I assume the scheduled rebuild is to address vulnerabilities in the base image like I raised as a concern? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Getting back on to this , apologies for the haitus.
Yes, this rebuild the entire image every sunday at midnight. This covers off any CVEs in the base image that have collected since our last release. I am going to push another commit now with a workflow_dispatch. this will allow us to manually start the action if anything particular comes out nasty between the scheduled runs. |
||
platforms: linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v8 | ||
|
||
- name: Sign the image | ||
env: | ||
TAGS: ghcr.io/${{ github.repository }}/bandit:latest | ||
DIGEST: ${{ steps.build-and-push.outputs.digest }} | ||
run: | | ||
echo "${TAGS}" | xargs -I {} cosign sign --yes {}@${DIGEST} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
FROM python:3.12-alpine | ||
|
||
# Install Git (required for pbr versioning) | ||
RUN apk add --no-cache git | ||
|
||
# Copy the source code into the container | ||
COPY . /bandit | ||
|
||
# Set the working directory | ||
WORKDIR /bandit | ||
|
||
# Install Bandit from the source code using pip | ||
RUN pip install . | ||
|
||
# Define entrypoint and default command | ||
ENTRYPOINT ["bandit"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to do this in a specific environment for the project to make it harder for untrusted folks to publish? https://github.com/urllib3/urllib3/blob/8beb3502cf6c945485174d96d90f2f5e5929bcbd/.github/workflows/publish.yml#L15-L16 I believe urllib3 has it such that only a handful of the core maintainers can actually publish a release. I need to see if I can find Seth's blog post on the benefits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good
Could we take this as a follow up?