Flavors: security vs others

[pjungermann]

MegaLinter provides various flavors. One of these flavors is the security flavor. There are also other flavors like java, javascript, python, etc.

Those flavors overlap, however, none of the others contains all linters of the security flavor.

Do you use combinations like

• java + security
• python + security
• etc.

or just one of the language-specific flavors or any other setup?

Would it make sense to consider the security flavor rather a subset of the others and include all its linters at the others?

[nvuillam]

@pjungermann there is currently no other choice than using the full flavor of MegaLinter to have ALL security linters

But most of language oriented flavors contain many security linters except devskim which is not stable, space consuming and more and more boring :)

Ex with java flavor:

[pjungermann]

Yes, I compared e.g. java vs security and the following linters from security are not included at java:

• CLOUDFORMATION_CFN_LINT
• PYTHON_BANDIT
• REPOSITORY_DEVSKIM
• REPOSITORY_DUSTILOCK
• REPOSITORY_KICS
• REPOSITORY_SYFT
• TERRAFORM_TFLINT
• TERRAFORM_TERRASCAN
• TERRAFORM_TERRAGRUNT

Some of them like PYTHON_BANDIT are clearly focused on a different language.

[pjungermann]

The full one is pretty big. 😅

[pjungermann]

Is there a way to create a custom flavor for yourself? 🤔

However, maybe it is more about a discussion about whether certain security linters should be contained in the Java flavor, too, or not.

E.g., CLOUDFORMATION_CFN_LINT as you may use Java within a CloudFormation stack/Lambda function; or REPOSITORY_KICS for the same reason or if you have Dockerfiles, etc.

[echoix]

I think one of end goal solutions for these kinds of problems would be to have an eStargz or other content addressable enabled image (there's more than a solution available). This would allow to always use the full image, but only pay the download cost of the extra linters when you use it. That might also be a bigger breaking change since maybe the images aren't in a pure OCI format yet.

Technically, now there isn't anything preventing us from doing it, except free time to actually work on it. However, a containerd backed image store should be used to enable that behavior, otherwise it should be like a normal image. Docker Desktop has had this option to use it, and is now recently out of beta. If speaking about the action on GitHub, if we define that it's a Docker-based image, then GitHub pre-pulls the image when downloading the action. Containerd doesn't seem used, it doesn't seem installed (last time I checked). If however we make users install containerd before in their Megalinter workflow, something like https://github.com/crazy-max/ghaction-setup-containerd or other, then our action could be rewritten to use the mega-linter-runner (to pull later on). The pull might either be super short (incomplete), or maybe we need to simply run without pulling to benefit for on-demand downloading of content.

We had a user here that suggested that to us a while back, but the ecosystem wasn't ready yet.

[nvuillam]

• CLOUDFORMATION_CFN_LINT
• PYTHON_BANDIT
• REPOSITORY_DEVSKIM
• REPOSITORY_DUSTILOCK
• REPOSITORY_KICS
• REPOSITORY_SYFT
• TERRAFORM_TFLINT
• TERRAFORM_TERRASCAN
• TERRAFORM_TERRAGRUNT

Is it frequent to have java + terraform in the same repo ?

Other linters are either SBOM, either heavy and slom (like Devskim & Kics)

With trivy + checkov + gitleaks + secretlint + trufflehog, you are already well equiped about security for your java project :)