Build System or Bust and Wrapping Security Tools Using Docker

Build System or Bust and Wrapping Security Tools Using Docker

Easy deployment of security tools using Crash Override Chalk

As we continue to work with early adopters to deploy Chalk, and onboard users onto the free tier of our commercial platform, it has been reinforced to us time and time again, that if you're deploying appsec tools today, it's ‘build system or bust’.

“We add all tools as Github actions”’ and “we need to be able to validate any security checks before a PR is accepted” are normal non-negotiable requirements. There is no doubt to us that CI/CD, has become the appsec assessment equivalent of the security checkpoint pattern, and validating the security quality of software at the checkpoint, is now the only game in town.

But we have also come to learn that the most important requirement that drives adoption across an enterprise is also about the build system. We typically hear something like “we have to be able to deploy across all of the pipelines without the developers having to do anything”. That’s a high bar, but today, repo by repo code scanning, or parallel security checks on a branch, are no longer considered viable options. It’s a case of having to be inline through the checkpoint, and doing it without the developer having to change anything.

We have been utilizing a neat little trick in Chalk, and have done the work to enable you to spin up any tool you want for every Docker build that happens on a build server, and all without the developer having to make any changes whatsoever. It really is neat.?

When you install Chalk on your Docker based build systems, we recommend putting it in the same directory where your Docker executable is, though anywhere in the default PATH is fine. You could of course deploy Chalk and ask everyone to run it by invoking Chalk before their Docker commands, but that's easy to forget. It's really better to automatically call Chalk when invoking Docker and that is the neat trick.?

You do it with a global alias. Your build systems will have a global file for bash configuration, which, these days, is almost always /etc/bash.bashrc (but if it's not there, then it should be at/etc/bashrc).

This file runs when any bash shell starts. All you need to add to this file is:

alias docker=chalk

With that, Chalk will now run each time you call Docker. The way we've configured Chalk when it doesn't see any of its own commands, is to use the Chalk Docker command.

We always run the Docker command intended by the user, but we also collect and report on environmental info using Chalk.?

In your Chalk config you can use run_sbom_tools and run_sast-tools to automatically run Syft and Semgrep with every build to generate an SBOM and run a SAST scan. We chose Syft for SBOMs and Semgrep for SAST, because we think they are best of breed open-source tools, but you can apply the same technique to run any tools, and here is where we need some help.??

What should we wrap next, so that you can use Chalk to run all of your appsec tools, on every Docker build, across all of your build pipelines, without having to ask the developer to do anything??

Suggestions in the comments will be very welcome.

Jose Miguel Parrella

Principal Architect at Microsoft

1 年

If you want to have Chalk orchestrate the execution of a tool to marshal its output into the chalk mark, then I'd approach it with: what are tools that are popular in CI processes that produce output that is tied to the state of the workflow (e.g., a commit) - a number in the 100s that ranges from linters to fuzzers, and have several implementation considerations (one example: how do you chalk a WAR file with the results of a ZAP run?) I'd start with the profiles of any tool aggregator; Megalinter is a good example. I'd filter down by tools that can already output, e.g., SARIF. In the context of Chalk, you might also want to look into CI posture tools like the ones mentioned in the latest OpenSSF SCM Best Practices Guide. Another interesting one is IaC files. This raises a couple Qs. The first one is what's the equivalent of a chalk mark in IaC world. The most immediate comparison is cloud resource tagging as implemented by Yor, for example, and I believe perhaps also KICS and others. The other one you alluded to: this tools are run today as native actions in the CI tool of choice, and this is likely how organizations have visibility of the coverage of those tools.

回复

要查看或添加评论,请登录

Mark Curphey的更多文章

社区洞察

其他会员也浏览了