HAL9000
ab974c49a9
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Failing after 1m19s
CI / push-validation (pull_request) Successful in 28s
CI / helm (pull_request) Successful in 32s
CI / build (pull_request) Successful in 44s
CI / benchmark-regression (pull_request) Failing after 43s
CI / quality (pull_request) Successful in 1m21s
CI / typecheck (pull_request) Successful in 1m40s
CI / security (pull_request) Successful in 1m43s
CI / e2e_tests (pull_request) Successful in 5m1s
CI / integration_tests (pull_request) Successful in 5m22s
CI / unit_tests (pull_request) Failing after 8m51s
CI / coverage (pull_request) Has been skipped
CI / docker (pull_request) Has been skipped
CI / status-check (pull_request) Failing after 5s
Added Trivy-based security scanning to the CI pipeline for the Dockerfile.server image. The scan is configured to fail the build on any HIGH or CRITICAL severity vulnerabilities, preventing insecure images from being deployed to production. Changes: - Added security scan step to .forgejo/workflows/ci.yml docker job - Trivy is installed and executed after building the Dockerfile.server image - Scan results are displayed in CI job output with detailed vulnerability report - Build fails (non-zero exit) if HIGH or CRITICAL vulnerabilities are detected - Added BDD feature file and step definitions for security scanning verification
37 lines
1.7 KiB
Gherkin
37 lines
1.7 KiB
Gherkin
Feature: Dockerfile.server security scanning
|
|
As a DevOps engineer
|
|
I want the CI pipeline to scan the Dockerfile.server image for vulnerabilities
|
|
So that we can prevent insecure images from being deployed to production
|
|
|
|
Background:
|
|
Given the Dockerfile.server exists in the repository root
|
|
And Trivy is available in the CI environment
|
|
|
|
Scenario: Security scan step is configured in CI pipeline
|
|
Given the CI workflow file exists at .forgejo/workflows/ci.yml
|
|
When I examine the docker job in the CI workflow
|
|
Then the docker job should include a step to scan the Dockerfile.server image
|
|
And the scan step should use Trivy or equivalent tool
|
|
And the scan step should be configured to fail on HIGH or CRITICAL severity findings
|
|
|
|
Scenario: Scan results are visible in CI output
|
|
Given a Dockerfile.server image has been built
|
|
When the security scan is executed
|
|
Then the scan results should be displayed in the CI job output
|
|
And the output should include a summary of vulnerabilities found
|
|
And the output should indicate the severity levels of findings
|
|
|
|
Scenario: Pipeline fails on high-severity vulnerabilities
|
|
Given a Dockerfile.server image with known HIGH severity vulnerabilities
|
|
When the security scan is executed
|
|
Then the scan should exit with a non-zero status code
|
|
And the CI job should fail
|
|
And the failure should block merge to master
|
|
|
|
Scenario: Pipeline passes when no high-severity vulnerabilities exist
|
|
Given a Dockerfile.server image with no HIGH or CRITICAL severity vulnerabilities
|
|
When the security scan is executed
|
|
Then the scan should exit with status code 0
|
|
And the CI job should pass
|
|
And the build can proceed to the next stage
|