Change Details

This is //heavily// dependent upon the outcomes of T287211, T301168 and T290339. If it appears that blubber will be successfully ported over to gitlab.wikimedia.org and function with pipelinelib similarly to how it does now, then we would likely want to implement some variety of container scanning within the appsec pipeline that followed a basic workflow of: # parse `blubber.yaml` for relevant images for a given app, repo, system. # build relevant dockerfiles # scan for vulnerabilities (and possibly lint/analyze for best practices) # report results as console output similar to other tests OSI/FSL-compliant tooling to consider: # [[ https://github.com/anchore/syft | syft ]] (for sbom) and [[ https://github.com/anchore/grype | grype ]] for (vuln-scanning) # [[ https://github.com/quay/clair | clair ]] - perhaps a bit much for our needs # [[ https://github.com/docker/docker-bench-security | docker bench ]] - more of a linter/best practices tool # [[ https://github.com/goodwithtech/dockle | dockle ]] - also more of a linter # [[ https://github.com/aquasecurity/trivy | trivy ]] - perhaps a bit much as well Tools like [[ https://snyk.io/product/container-vulnerability-management/ | snyk's alleged oss container scanner ]], [[ https://github.com/eliasgranderubio/dagda | dagda ]], etc simply do not satisfy current licensing requirements.

This is //heavily// dependent upon the outcomes of T287211, T301168 and T290339. If it appears that blubber will be successfully ported over to gitlab.wikimedia.org and function with pipelinelib similarly to how it does now, then we would likely want to implement some variety of container scanning within the appsec pipeline that followed a basic workflow of: # parse `blubber.yaml` for relevant images for a given app, repo, system. # build relevant dockerfiles # scan for vulnerabilities (and possibly lint/analyze for best practices) # report results as console output similar to other tests OSI/FSL-compliant tooling to consider: # [[ https://github.com/anchore/syft | syft ]] (for sbom) and [[ https://github.com/anchore/grype | grype ]] (for vuln-scanning) # [[ https://github.com/quay/clair | clair ]] - perhaps a bit much for our needs # [[ https://github.com/docker/docker-bench-security | docker bench ]] - more of a linter/best practices tool # [[ https://github.com/goodwithtech/dockle | dockle ]] - also more of a linter # [[ https://github.com/aquasecurity/trivy | trivy ]] - perhaps a bit much as well Tools like [[ https://snyk.io/product/container-vulnerability-management/ | snyk's alleged oss container scanner ]], [[ https://github.com/eliasgranderubio/dagda | dagda ]], etc simply do not satisfy current licensing requirements.

This is //heavily// dependent upon the outcomes of T287211, T301168 and T290339. If it appears that blubber will be successfully ported over to gitlab.wikimedia.org and function with pipelinelib similarly to how it does now, then we would likely want to implement some variety of container scanning within the appsec pipeline that followed a basic workflow of: # parse `blubber.yaml` for relevant images for a given app, repo, system. # build relevant dockerfiles # scan for vulnerabilities (and possibly lint/analyze for best practices) # report results as console output similar to other tests OSI/FSL-compliant tooling to consider: # [[ https://github.com/anchore/syft | syft ]] (for sbom) and [[ https://github.com/anchore/grype | grype ]] (for (vuln-scanning) # [[ https://github.com/quay/clair | clair ]] - perhaps a bit much for our needs # [[ https://github.com/docker/docker-bench-security | docker bench ]] - more of a linter/best practices tool # [[ https://github.com/goodwithtech/dockle | dockle ]] - also more of a linter # [[ https://github.com/aquasecurity/trivy | trivy ]] - perhaps a bit much as well Tools like [[ https://snyk.io/product/container-vulnerability-management/ | snyk's alleged oss container scanner ]], [[ https://github.com/eliasgranderubio/dagda | dagda ]], etc simply do not satisfy current licensing requirements.