DEV Community: Takashi Yoneuchi

[Boost]

Takashi Yoneuchi — Tue, 17 Jun 2025 11:27:40 +0000

GMO Flatt Security for GMO Flatt Security Inc.

Jun 9 '25

LLM Framework Vulns Exposed: Learnings from CVEs

#ai #security #development #llm

Comments

11 min read

7 Easy-to-Follow Best Practices for Writing Dockerfile

Takashi Yoneuchi — Wed, 13 Oct 2021 15:59:46 +0000

Dockerfile allows you to create container images in such a way as if you were writing shell scripts. This simplicity is excellent indeed, but it does NOT mean that you don't need to learn good practices for writing Dockerfile. Just a few practices will make your container images more optimized and secure.

This article shows a list of 7 best practices for writing Dockerfile along with some Shisho rules to detect the issues. You may not know Shisho, but it's okay because Shisho is extremely easy to use; all you need to do for checking your Dockerfile is just by running the following command:

curl https://raw.githubusercontent.com/security-aware-repo-examples/dockerfile-best-practice/master/rules/docker.shisho.yaml > docker.shisho.yaml && \
    docker run -i -v $(pwd):/workspace ghcr.io/flatt-security/shisho-cli:latest check ./docker.shisho.yaml .

If you're a user of GitHub Actions, you can copy this example workflow and the rule file in security-aware-repo-examples/dockerfile-best-practice to your repository. The workflow checks your repository with the rule, and it reports them to GitHub Code Scanning. The issues will appear at https://github.com/<your org>/<your repository>/security/code-scanning.

Let's get started!

♻️ Three Practices for Maintainability

1. Avoid to use `latest` tag for immutability

A latest tag is used to create a docker image whose base is the latest version of another image. The use of latest tag, however, might cause confusion and inconsistent behaviour among built images. It is better to pin the version of your base images if possible.

The following Shisho rule will detect the use of latest tag:

version: '1'
rules:
  - id: 'use-fixed-tag-sfor-immutablity'
    language: dockerfile
    message: |
      The use of `latest` tag might cause confusion and inconsistent behavior in automated builds. It is better to pin the version of your base images.
    patterns: 
      - pattern: FROM :[IMAGE]
      - pattern: FROM :[IMAGE] as :[ALIAS]
      - pattern: FROM :[IMAGE]:latest
      - pattern: FROM :[IMAGE]:latest as :[ALIAS]
      - pattern: FROM :[IMAGE]@:[HASH]
      - pattern: FROM :[IMAGE]@:[HASH] as :[ALIAS]
      - pattern: FROM :[IMAGE]:latest@:[HASH]
      - pattern: FROM :[IMAGE]:latest@:[HASH] as :[ALIAS]

(You can see the working example of this rule at Shisho Playground)

2. Use an idiomatic way to run `apt-get install`

You may often run apt-get inside your Dockerfile as follows:

RUN apt-get update
RUN apt-get install -y nginx <... and some more packages>

However, the example above has two issues:

When the cache image for the first RUN is available, the second apt-get might install old packages due to not running apt-get update.
Some layers for this image have cache files for apt-get, resulting in larger image size.

A simple way to address these issues is running apt-get update and apt-get install in a single RUN instruction. The following examples show an idiomatic way to run them once while removing /var/lib/apt/lists/* (i.e. apt caches) to reduce the image size more:

RUN apt-get update && \
    apt-get install -y nginx && \
    rm -rf /var/lib/apt/lists/*

The following Shisho rule will enforce the use of this idiom:

version: '1'
rules:
  - id: 'remove-cache-of-apt-get'
    language: dockerfile
    message: |
      It is better to remove cache files of `apt-get` to keep your image slim.
    pattern: |
      RUN apt-get install :[X]
    rewrite: |
        RUN apt-get update && \
            apt-get install :[X] && \
            rm -rf /var/lib/apt/lists/*

(You can see the working example of this rule at Shisho Playground)

3. Use `--no-install-recommends` flag of `apt-get`

It is even better to avoid to install any unnecessary tools by --no-install-recommends of apt-get command. The following Shisho rule may help the use of this flag:

version: "1"
rules:
  - id: "use-no-install-recommends-flag-apt-get"
    language: dockerfile
    message: |
      You can avoid to install any unnecessary tools by `--no-install-recommends` on `apt-get`.
    patterns:
      - pattern: |
          RUN apt-get install :[...X]
      - pattern: |
          RUN :[...Y] apt-get install :[...X]
    constraints:
      - target: X
        should: not-match
        regex-pattern: ".*--no-install-recommends.*"
    rewrite_options:
      - |
        RUN :[Y] apt-get install --no-install-recommends :[X]

(You can see the working example of this rule at Shisho Playground)

🛡️ Four Practices for Security

While container technology brings many advantages, such as portability or isolation, it also creates new threats from a security perspective. This section describes common docker security issues and explains how to avoid them.

4. Avoid to store secrets in environment variables

Hardcoded secrets in your Dockerfile will be stored in resulting images. You should avoid to embed the secrets. You can inject environment variables at run-time instead.

version: '1'
rules:
  - id: 'avoid-to-store-secrets-in-env'
    language: dockerfile
    message: |
      Hardcoded secrets in your Dockerfile will be stored in resulting images. Please consider to stop embedding the secrets. 
    pattern: |
      ENV :[...] :[KEY]=:[VALUE] :[...]
    constraints:
      - target: KEY
        should: match-any-of
        regex-patterns:
          - "[sS][eE][cC][rR][eE][tT]"
          - "[tT][oO][kK][eE][nN]"
          # ... add as you like ...

(You can see the working example of this rule at Shisho Playground)

5. Use trusted base images

A docker image consists of multiple layers, and some of them are usually derived from the base image. Here exists a risk of supply chain attacks! It is better to use official images to reduce the risk as much as possible.

version: '1'
rules:
  - id: 'use-docker-official-images'
    language: dockerfile
    message: |
      It is better to use official images to reduce the risk of supply chain attacks.
    patterns: 
      - pattern: FROM :[IMAGE]
      - pattern: FROM :[IMAGE] as :[ALIAS]
      - pattern: FROM :[IMAGE]::[TAG]
      - pattern: FROM :[IMAGE]::[TAG] as :[ALIAS]
      - pattern: FROM :[IMAGE]@:[HASH]
      - pattern: FROM :[IMAGE]@:[HASH] as :[ALIAS]
      - pattern: FROM :[IMAGE]::[TAG]@:[HASH]
      - pattern: FROM :[IMAGE]::[TAG]@:[HASH] as :[ALIAS]
    constraints:
      - target: IMAGE
        should: match
        regex-pattern: "/"

(You can see the working example of this rule at Shisho Playground)

If you already have a list of trusted base images, some slight changes will let you use them:

version: '1'
rules:
  - id: 'use-trusted-base-images'
    language: dockerfile
    message: |
      It is better to use trusted base images to reduce the risk of supply chain attacks.
    patterns: 
      - pattern: FROM :[IMAGE]
      - pattern: FROM :[IMAGE] as :[ALIAS]
      - pattern: FROM :[IMAGE]::[TAG]
      - pattern: FROM :[IMAGE]::[TAG] as :[ALIAS]
      - pattern: FROM :[IMAGE]@:[HASH]
      - pattern: FROM :[IMAGE]@:[HASH] as :[ALIAS]
      - pattern: FROM :[IMAGE]::[TAG]@:[HASH]
      - pattern: FROM :[IMAGE]::[TAG]@:[HASH] as :[ALIAS]
    constraints:
      - target: IMAGE
        should: not-match-any-of
        regex-patterns:
            - "^[^/]+$"
            - "^image-name/you-trust$"

(You can see the working example of this rule at Shisho Playground)

6. Avoid to run `curl <...> | sh`

Many shell scripts and dockerfiles use curl <...> | sh as an idiomatic way to run an external script inside computers/containers, but this idiom has a risk of remote code execution by attackers through MITM attacks or compromising the distributed script itself (see the report of recent codecov incident). It is better to check the integrity of what you download before running it as a shell script.

version: "1"
rules:
  - id: "check-integrity-of-downloaded-shell-script"
    title: Check the integrity of downloaded shell scripts
    language: dockerfile
    message: |
      It is better to check the integrity of what you download before running it as a shell script.
    pattern: |
      RUN :[CMD]
    constraints:
      - target: CMD
        should: match-any-of
        regex-patterns:
          - curl[^|^>]*[|>]
          - wget[^|^>]*[|>]

(You can see the working example of this rule at Shisho Playground)

7. Use `COPY` instead of `ADD`

ADD instruction allows us to fetch resources over the network and extract an archive, but it may cause security issues such as Meet-in-the-Middle (MITM) attacks or Zip Slip vulnerabilities. It is better to use COPY instead of ADD if possible.

The following Shisho rule detects the use of ADD instructions:

version: '1'
rules:
  - id: 'use-copy-instead-of-add'
    language: dockerfile
    message: |
      ADD instruction allows us to fetch resources over network and extract an archive, but it may cause security issues such as Meet-in-the-Middle (MITM) attacks or Zip Slip vulnerabilities.
    pattern: ADD :[FROM] :[TO]
    rewrite: COPY :[FROM] :[TO]

(You can see the working example of this rule at Shisho Playground)

Conclusion

In this article, I presented some best practices for writing Dockerfile and demonstrated how to check your Dockerfile is following the practices continuously by Shisho.

You can refer security-aware-repo-examples/dockerfile-best-practice to see the working example.

security-aware-repo-examples / dockerfile-best-practice

Shisho rules that enforce Dockerfile best practices

dockerfile-best-practice

This repository shows an example of a GitHub Actions workflow to detect anti-patterns in your Dockerfile. See "7 Easy-to-Follow Best Practices for Writing Dockerfile" for further details.

View on GitHub

If you have an interest in Shisho, I would be appreciated if you starred the following repository and gave me feedback at discussions!

flatt-security / shisho

Lightweight static analyzer for several programming languages

shisho

Shisho is a lightweight static analyzer for developers.

Please see the usage documentation for further information.

Try at Playground

You can try Shisho at our playground.

Try with Docker

You can try shisho in your machine as follows:

echo "func test(v []string) int { return len(v) + 1; }" | docker run -i ghcr.io/flatt-security/shisho-cli:latest find "len(:[...])" --lang=go

echo "func test(v []string) int { return len(v) + 1; }" > file.go
docker run -i -v $(pwd):/workspace ghcr.io/flatt-security/shisho-cli:latest find "len(:[...])" --lang=go /workspace/file.go

Install with pre-built binaries

When you'd like to run shisho outside docker containers, please follow the instructions below:

Linux / macOS

Run the following command(s):

# Linux
wget https://github.com/flatt-security/shisho/releases/latest/download/build-x86_64-unknown-linux-gnu.zip -O shisho.zip
unzip shisho.zip
chmod +x ./shisho
mv ./shisho /usr/local/bin/shisho

# macOS
wget https://github.com/flatt-security/shisho/releases/latest/download/build-x86_64-apple-darwin.zip -O shisho.zip
unzip shisho.zip
chmod +x ./shisho
mv ./shisho /usr/local/bin/shisho

Then you'll see a…

View on GitHub

NOTE: I'm working on Shisho Cloud, a web service providing this kind of best practice checks for infrastructure-as-code and automated patch generation for detected issues. It's in a beta stage now and all features are available for free. Please try it!

Build Your Own Lint Rules for Terraform with Shisho

Takashi Yoneuchi — Mon, 23 Aug 2021 15:44:38 +0000

tl;dr: Shisho is an open-source static code analyzer that lets you build your own lint rules for Terraform codes. You can find and refactor specific code patterns easily with a handy configuration language.

Building Linter / Static Analyzer is Too Hard

Every developer wants to avoid embedding issues in their software, while finding issues tends to be boring. So here's where a linter / a static analyzer come: they will be a great supporter of you and your team by detecting common bugs with pre-defined rules before the bugs are shipped to the world.

Sometimes, you will want to enforce custom rules for your code to standardize best practices specific to your team. When you want to prevent your team members from using uniform_bucket_level_access = true in google_storage_bucket resources like the following snippet, for example, you hope there's a flexible linter that lets you add custom rules quickly:

resource "google_storage_bucket" "test" {
  project  = var.project
  name     = "${var.project}-test"
  location = var.location
  uniform_bucket_level_access = true
  force_destroy               = true
}

However, adding and maintaining custom rules is quite hard! You need to learn how to write custom rules for each programming language your team use, although different programming languages have different linters or analyzers, with different DSLs and APIs. This difficulty is one of the severe problems of standard linters / static analyzers.

Shisho: A Customizable Static Code Analyzer

Shisho, a lightweight static code analyzer, will help you build custom lint rules for your codebase. I'll explain what and how it is.

flatt-security / shisho

Lightweight static analyzer for several programming languages

shisho

Shisho is a lightweight static analyzer for developers.

Please see the usage documentation for further information.

Try at Playground

You can try Shisho at our playground.

Try with Docker

You can try shisho in your machine as follows:

echo "func test(v []string) int { return len(v) + 1; }" | docker run -i ghcr.io/flatt-security/shisho-cli:latest find "len(:[...])" --lang=go

echo "func test(v []string) int { return len(v) + 1; }" > file.go
docker run -i -v $(pwd):/workspace ghcr.io/flatt-security/shisho-cli:latest find "len(:[...])" --lang=go /workspace/file.go

Install with pre-built binaries

When you'd like to run shisho outside docker containers, please follow the instructions below:

Linux / macOS

Run the following command(s):

# Linux
wget https://github.com/flatt-security/shisho/releases/latest/download/build-x86_64-unknown-linux-gnu.zip -O shisho.zip
unzip shisho.zip
chmod +x ./shisho
mv ./shisho /usr/local/bin/shisho

# macOS
wget https://github.com/flatt-security/shisho/releases/latest/download/build-x86_64-apple-darwin.zip -O shisho.zip
unzip shisho.zip
chmod +x ./shisho
mv ./shisho /usr/local/bin/shisho

Then you'll see a…

View on GitHub

Find Codes

First of all, Shisho enables us to run AST-aware code search over your code. Here's an example command which finds the occurence of uniform_bucket_level_access = true inside google_storage_bucket resource:

docker run -i -v $(pwd):/workspace ghcr.io/flatt-security/shisho-cli:latest find "
resource \"google_storage_bucket\" :[_] {
  :[...]
  uniform_bucket_level_access = true
  :[...]
}
" --lang hcl ./code.tf

The command will make the following outputs in your console:

Here :[_] is an anonymous metavariable, which matches an arbitrary single node in AST (like a function call, identifier, and so on). Similarly, :[...] is an anonymous ellipsis metavariable, which matches zero or more nodes in AST. These operators are something like capture groups in regular expressions. They let you search over your code in a structured but flexible manner.

You can also define a rule, which includes a pattern and the explaination for it. The following YAML snippet is an example of rules describing the use of uniform_bucket_level_access is prohibited:

version: "1"
rules:
  - id: sample-policy
    language: hcl
    pattern: |
      resource "google_storage_bucket" :[_] {
        :[...X]
        uniform_bucket_level_access = true
        :[...Y]
      }
    message: |
      Our team policy prohibits the use of uniform bucket-level access.

You can find patterns by executing shisho find path/to/rule.yaml path/to/search command, resulting in the following outputs:

This is how Shisho makes it possible to build your own lint rules for Terraform codes. You can use Shisho in the CI pipeline with your own rules, let alone your local machine. Please see Learn Shisho for further details.

Refactor Codes

Additionally, Shisho rules can include how detected code patterns should be fixed. The following YAML snippet describes a custom lint rule that suggests the use of uniform_bucket_level_access = true should be deleted:

version: "1"
rules:
  - id: sample-policy
    language: hcl
    pattern: |
      resource "google_storage_bucket" :[NAME] {
        :[...X]
        uniform_bucket_level_access = true
        :[...Y]
      }
    message: |
      Our team policy prohibits use of uniform bucket-level access.
    rewrite: |
      resource "google_storage_bucket" :[NAME] {
        :[X]
        :[Y]
      }

Once this rule is run over your codes and the use of uniform_bucket_level_access = true is detected, Shisho suggests changes following the rule's rewrite section like:

Usecases

You can use Shisho for standardizing your codebase. In addition, it could be a means of conducting "security-as-code" or "policy-as-code"!

For instance, when you want to keep your team's EBS volumes encrypted, you can define a rule as follows:

version: '1'
rules:
  - id: 'unencrypted-ebs-volume'
    language: hcl
    message: |
      There was unencrypted EBS module.
    pattern: |
      resource  "aws_ebs_volume" :[NAME] {
        :[...X]
      }
    constraints:
      - target: X
        should: not-match
        pattern: |
          encrypted = true
    rewrite: |
      resource "aws_ebs_volume" :[NAME] {
        :[X]
        encrypted = true
      }

When you want your colleagues to follow the naming convention for resources, the following rule will work well:

version: "1"
rules:
  - id: "invalid-resource-name"
    language: hcl
    message: |
      A resource was named badly.
    pattern: |
      resource  :[_] :[NAME] {
        :[...]
      }
    constraints:
      - target: NAME
        should: not-match-regex
        pattern: '"team1-.*"'

The rule will report the result like:

Why Shisho?

"Modern Static Analysis: how the best tools empower creativity" explains that good code analyzers or linters are often interoperable, moldable, efficient, and community-driven and that Semgrep works well from these viewpoints. Semgrep is also grep-like (or sed-like) software that lets us find bugs with useful DSLs.

As for Shisho, it is at least interoperable (since it's open-sourced), moldable (though some efforts are needed; see issue #7). Moreover, Shisho is surprisingly efficient! Here's the result of a micro-benchmark of Semgrep, Comby (a similar tool), and Shisho¹:

Tool	Time	Command
Comby (1.7.0)	263.1 ms	`time comby 'len(...)' '' parser.go -match-only &> /dev/null`
Semgrep (0.62.0)	530.0ms	`time semgrep -e 'len(...)' --lang=go parser.go &> /dev/null`
Shisho (0.1.2-alpha.2)	22.8ms	`time shisho find 'len(:[...])' --lang=go parser.go &> /dev/null`

In fact, Shisho aims to refine the existing tools and to make it more feasible to run for large projects. You can use Shisho for your monorepo without hesitation. For your information, this speed is supported by Rust ².

On the other hand, it's true that Shisho lacks some features of Semgrep and Comby. For instance, Semgrep has a feature to match patterns with type information while Shisho doesn't. Semgrep also has Semgrep Registry, in which you can share your own lint rules for the worldwide community. Now I'm making efforts to design and implement these features. Stay tuned!

Now What?

This article explained the usage of Shisho for Terraform codes, but Shisho is extending other language supports! Especially Dockerfile support will be shipped soon. You can follow @y0n3uchy to see the news on Shisho and star our GitHub project to encourage us :-)

Additionally, I'll release a SaaS which supports your Terraform development workflows with this engine. See https://shisho.dev/ for further details.

Time is the average of 20 consecutive command executions. The measurement was run on Ubuntu 20.04.2 LTS with AMD Ryzen 5 3600 / 64GB RAM. The scan target was parser.go. ↩
Both Semgrep and Comby is written in OCaml. ↩

DEV Community: Takashi Yoneuchi

[Boost]

LLM Framework Vulns Exposed: Learnings from CVEs

7 Easy-to-Follow Best Practices for Writing Dockerfile

♻️ Three Practices for Maintainability

1. Avoid to use latest tag for immutability

2. Use an idiomatic way to run apt-get install

3. Use --no-install-recommends flag of apt-get

🛡️ Four Practices for Security

4. Avoid to store secrets in environment variables

5. Use trusted base images

6. Avoid to run curl <...> | sh

7. Use COPY instead of ADD

Conclusion

security-aware-repo-examples / dockerfile-best-practice

Shisho rules that enforce Dockerfile best practices

dockerfile-best-practice

flatt-security / shisho

Lightweight static analyzer for several programming languages

shisho

Please see the usage documentation for further information.

Try at Playground

Try with Docker

Install with pre-built binaries

Linux / macOS

Build Your Own Lint Rules for Terraform with Shisho

Building Linter / Static Analyzer is Too Hard

Shisho: A Customizable Static Code Analyzer

flatt-security / shisho

Lightweight static analyzer for several programming languages

shisho

Please see the usage documentation for further information.

Try at Playground

Try with Docker

Install with pre-built binaries

Linux / macOS

Find Codes

Refactor Codes

Usecases

Why Shisho?

Now What?

1. Avoid to use `latest` tag for immutability

2. Use an idiomatic way to run `apt-get install`

3. Use `--no-install-recommends` flag of `apt-get`

6. Avoid to run `curl <...> | sh`

7. Use `COPY` instead of `ADD`