Trivy as Bazel rule

[danmx]

It would be awesome if Trivy could be used easily with Bazel build system. Probably there would be some issues around the database and caching.

[andyliuliming]

hi, any chance to add this support? thanks.

[libratiger]

Is there any new progress or update for this ?

[knqyf263]

We welcome contributions.

[libratiger]

@knqyf263 what's your advice to contribute, which dir should we put in, since there is no bazel rules now.

[knqyf263]

I'm not familiar with Bazel. Do we want to provide a Bazel rule?
https://bazel.build/extending/rules#target_instantiation

How can we distribute it? Do people download a .bzl file from GitHub and load it?
https://bazel.build/concepts/build-files#load

[jtcarnes]

@knqyf263 You would likely want to provide a Bazel rule as well as a module which exports a toolchain. Lot of words to say:

You need one thing describes how to download trivy (this is to ensure everyone is all using the same version of trivy) then you'd define a rule on that toolchain to running trivy.

Typically how this would work is during your normal releases, you provide a tar.gz of the bazel rules. This is used by people in their WORKSPACES by using an http_archive that downloads and extracts those rules so they are available for their builds.

Similar to @libratiger , I am happy to contribute to this end if you have a preference for where it might live. I'd suggest something like a bazel directory or something similar.

This would be helpful to me as someone who uses trivy and am moving into bazel so that I can have scanning be a target in my builds. We build our image using bazel, then can use that output as a target for bazel.

[knqyf263]

Typically how this would work is during your normal releases, you provide a tar.gz of the bazel rules. This is used by people in their WORKSPACES by using an http_archive that downloads and extracts those rules so they are available for their builds.

Interesting. Do you have an example? It helps my understanding.

[jtcarnes]

Sure! Actually, these might do best in their own repo in your organization so as to not pollute your core repo. Bazels suggestion can be read here: https://bazel.build/rules/deploying

New rules should go into their own GitHub repository under your organization
Repository names for Bazel rules are standardized on the following format: $ORGANIZATION/rules_$NAME

Generally, the rules would consist of: a macro that registers a toolchain (ie: downloads the proper version of trivy for the platform), rules for what you'd want your rules to do (in trivy's case, perhaps ones for image_scan, repo_scan?) and then some tests.

There are tools for generating the standard documentation from comments in the code.

As the upstream suggestion is to make it it's own repo, I can write the rules and if they are something of interest, have them moved to a repo in your organization. If Trivy isn't interested at that point, I could at least still use them myself so there would be no loss on my part.

An example though of one would be rules_oci. It would be what I use these rules in conjunction with. (meaning: some languages normal rules -> binary , rules_oci + binary -> image/tar , rules_trivy + image/tar -> security scan)