feat(checks): Adding IAC check for secrets inserted into docker layer

[simar7]

Discussed in #7570

^{Originally posted by tzurielweisberg September 22, 2024}

Description

Wbserved recently that when the secrets are passed to docker build with --build-args, it saved into the image layers unexposed and that leads to a secret leak if someone inspects the image layers or reviews the scan layers from Aqua UI for the scanned image.

We need a IAC rule for Dockefile to search for Secrets/Password usage.

It of course will be matched in secret scanning later, but we want to know about it before

Target

Filesystem

Scanner

Misconfiguration

[nikpivkin]

Should the check find potential use of secrets in the Dockerfile, or find secrets in the docker history?

[knqyf263]

find secrets in the docker history?

It's already supported. I think we need the former.

[nikpivkin]

Then I think we can define secrets in the following ways:

• analyze ARG and ENV and look for a match with known environment variables (github, aws for example). An example of such a case:
  • https://github.com/drutiny/drutiny/blob/a2c8b5e92f982ad65a9804fd759fa879dd90d9ce/Dockerfile#L4C5-L4C17
  • https://github.com/git-goods/gitanimals/blob/8b6791dfbcc317abdcbea0d0bb38f38e598bc44a/Dockerfile#L6
• analyze ARG and ENV and look for words similar to password. Example:
  • https://github.com/git-goods/gitanimals/blob/8b6791dfbcc317abdcbea0d0bb38f38e598bc44a/Dockerfile#L5
• setting environment variables via RUN
  • https://github.com/nessos/Streams/blob/627db254181f69faa57d304829290cf18f43f4f8/Dockerfile#L5-L8

We can also take into account setting environment variables in a specific way. You need to add the VITE and REACT_APP prefix to pass environment variables to React or Vite applications, respectively. Here is an example of a Dockerfile (the repository has 2.7k stars) with multiple credentials set up this way: https://github.com/hahahumble/speechgpt/blob/215e3a07a65eafede2ba3257939a4e59cfd01ae6/Dockerfile#L4-L10

Docker has the ability to pass secrets and we need to take this into account to avoid false positives. Example: https://github.com/super-linter/super-linter/blob/c4fe4da1f3bda7fd0f28bf92dd357fb9feeef5bf/Dockerfile#L103

[nikpivkin]

We have the ability to pass user data to the checks, so users will have the ability to extend the check or disable some rules.

[nikpivkin]

Also, we should only analyze the final stage commands

[simar7]

We have the ability to pass user data to the checks, so users will have the ability to extend the check or disable some rules.

Do you have an example for this? Do you mean define user based exceptions to detections?

[simar7]

Also, we should only analyze the final stage commands

@nikpivkin Just thinking about this: if the secret was present in an intermediate layer but later removed from subsequent layers, it is still exposed via the history right?

[knqyf263]

Also, we should only analyze the final stage commands

@nikpivkin Just thinking about this: if the secret was present in an intermediate layer but later removed from subsequent layers, it is still exposed via the history right?

I think @nikpivkin is talking about multi-stage builds.

[nikpivkin]

Also, we should only analyze the final stage commands

@nikpivkin Just thinking about this: if the secret was present in an intermediate layer but later removed from subsequent layers, it is still exposed via the history right?

I meant multi-stage build. The image history only stores information about the final stage.

[nikpivkin]

We have the ability to pass user data to the checks, so users will have the ability to extend the check or disable some rules.

Do you have an example for this? Do you mean define user based exceptions to detections?

We can define the following rule:

included_envs := included if {
	is_array(ds031.included_envs)
	included := {e | some e in ds031.included_envs}
} else := set()

Then the user can include additional environment variables:

❯ cat my-envs.yaml
ds031:
  included_envs: ["MY_SECRET"]

❯ cat Dockerfile.custom
from alpine

arg MY_SECRET

❯ trivy conf -d Dockerfile.custom --config-data my-envs.yaml
CRITICAL: Possible exposure of secret env "MY_SECRET" in ARG
═══════════════════════════════════════════════════════════════════════════════════════════════════════════
Passing secrets via `build-args` or envs or copying secret files can leak them out

See https://avd.aquasec.com/misconfig/ds031
───────────────────────────────────────────────────────────────────────────────────────────────────────────
 Dockerfile.custom:3
───────────────────────────────────────────────────────────────────────────────────────────────────────────
   3 [ arg MY_SECRET
───────────────────────────────────────────────────────────────────────────────────────────────────────────

[nikpivkin]

@simar7 I found a discussion about the parametrization of checks.