💀 Bound to Fail

Here is code that is bound to fail. It's using old docker images and not using best practices in multiple areas. This code demonstrates how GitHub actions can be used to safely create, scan, and publish container images using some nice best practices like fail-left and don't do unneeded work

small change

Steps -

Look at the .github/workflows/main.yaml file.

CI Pipeline flow....

1. developer pushes a feature branch
   • triggers a SAST code scan of code (python, npm, java etc) - scan issues won't fail the build
   • triggers a scan of the Dockerfile scan issues won't fail the build
2. store container artifact locally
   • deploys container and runs mock tests
   • reports go to output folder
   • if these pass, then artifact promotes to integration container repo
   • a GIT tag is cut
3. container image is tagged with latest and git-tag and pushed to CI repo
4. image is deployed into CI
5. tests are fired off
6. report generated
7. if these pass, container is retagged with git-tag and pushed to the final ECR image repo
8. continuous scanning happens on PROD ECR repo

Improvements Needed

• only build if files have changed or have been added
• add tagging
• add push to registry if the scan passed
• integrate with tooling selected by InfoSec
• get feedback
  • InfoSec
  • Dev Teams management
  • Architects
  • SRE

TODO

• Create drawing to visually display the flow
• Create SBOM (software bill of materials)
• Scan for licenses
• Auto create release notes
• Helm chart scanning
• Helm chart promotion
• Jira GitHub integration GitHub link
  • create issues based on failing tests
  • link issues in Jira
• GitHub repo best practices
  • global git
    • set default branch to main git config --global init.defaultBranch main
    • create user and email
  • don't allow anyone to push to main