Turn parameters in Trivy as customizable

[Lucassino]

In order to implement trivy scanners in my pipeline, i want to stop the step if it finds a critical vulnerability in my FS. To do so, i need to change the parameter "--exit-code 0" to --exit-code 1".

My main idea is to turn this parameter as a variable, so when i config my step in github actions i can pass the value that i want.

For example
trivy filesystem $FURTHER_PARAMETERS --quiet --exit-code $EXIT_CODE --format cyclonedx --scanners vuln --output "$WORKSPACE/$REPORT_NAME" "$TARGET"

  - name: Run Trivy FileSystem SCA
    uses: MaibornWolff/secobserve_actions_templates/actions/SCA/trivy_filesystem@main
    continue-on-error: true
    with:
      target: '.'
      report_name: 'report_trivy_filesystem_sca.json'
      so_api_base_url: ${{ vars.SO_API_BASE_URL }}
      so_api_token: ${{ vars.SO_API_TOKEN }}
      so_product_name: ${{ vars.SO_PRODUCT_NAME }}
      **exit_code: ${{ vars.EXIT_CODE }}**

What do you guys think?

[StefanFl]

Hi @Lucassino, I see your point. Personally I don't like breaking CI pipelines for these checks, but I know from discussions within my company there are other opinions.

I would like to implement a solution that works for other scanners as well, so it might be something like stop_pipeline_on_observations=true. Does that make sense for you?

[Lucassino]

Hello @StefanFl ,

Thanks for the response.

I'm using Trivy now, what i like about this tool is that i can manage my pipeline with some filters (stop if there's a Critical vuln, or create exceptions and so on).

Withou this configs, i cant build my app in production environment safely.

Do you have any suggestions how can i handle this situation with SecObserve steps only?

Also, i have some other contributions that i'd like to talk with you. I'm running SecObserve on a k8s, so i transformed the docker compose into helm chart, if you are interessed, i can share with you.

BTW, i'm having a really good time working with SecObserve because i believe in it's potential. So i'll keep sharing my experience with you guys and try to help whenever i can!

[StefanFl]

Not sure I described my idea properly: The parameter would be stop_pipeline_on_observations, if it is set to true and the scanner finds an observation, the action responds with an exit code of 1 on which your pipeline can then react accordingly.

Would that work for you or would you want to be able to set other exit codes than 1?

[StefanFl]

Also, i have some other contributions that i'd like to talk with you. I'm running SecObserve on a k8s, so i transformed the docker compose into helm chart, if you are interessed, i can share with you.

BTW, i'm having a really good time working with SecObserve because i believe in it's potential. So i'll keep sharing my experience with you guys and try to help whenever i can!

Glad you like SecObserve. I am very much interested in contributions. Always wanted to have a Helm chart for SecObserve. But other contributions, in form of PR's, ideas, feedback or anything else is highly appreciated.

[StefanFl]

Hi @Lucassino, I had a rethink about it and would propose something different. The right way to control the CI pipeline would be to utilize SecObserve's security gate. This would

• give a lot of flexibility, e.g. you can stop the pipeline only when there are critical/high observations
• work uniformly for all scanners
• take manual assessments and rules into account

I will write an action / template to read the security gate of a product and set an exit code 1, if the security gate has failed.

Does that make sense for you?

[Lucassino]

Hello @StefanFl , sorry for the delay in the response.

That makes sense! I'm glad that you guys thought about my concerns.

Also, i'll share in a PR the Helm Chart so you can review!

Kind regards

[StefanFl]

The action and template for the check of the security gate have been released, see https://github.com/MaibornWolff/secobserve_actions_templates/releases/tag/v2024_11_2.

Thanks again @Lucassino for your impulse.