Create rule S6472: Using ENV to handle secrets is security-sensitive (#1399)

rules/S6472/ask-yourself.adoc

@@ -0,0 +1,6 @@
+== Ask Yourself Whether
+
+* The environment variable contains a value that should be kept confidential.
+* The container image or Dockerfile will be distributed to users who do not need to know the secret value.
+
+There is a risk if you answered yes to any of those questions.

rules/S6472/description.adoc

@@ -0,0 +1,24 @@
+Using ENV to handle secrets can lead to sensitive information being disclosed
+to an inappropriate sphere.
+
+The `ENV` commands in a Dockerfile are used to configure the container
+environment. The variables set that way can be used at image build time,
+during the execution of commands in the container, or at run time.
+
+In most cases, environment variables are used to propagate configuration items
+from the host to the container. A typical example is the `PATH` variable, used
+to configure where system executables are searched for.
+
+Using `ENV` to propagate configuration entries that contain secrets causes a
+security risk. Indeed, in most cases, artifacts of those values are kept in the
+final container image and, thus, disclosed to its users. The secret information
+leak can happen either in the container environment itself, the image
+metadata or the build environment logs.
+
+The concrete impact of such an issue highly depends on the secret's purpose and
+the exposure sphere:
+
+* Financial impact if a paid service API key is disclosed and used.
+* Application compromise if an application's secret, like a session signing
+key, is disclosed.
+* Infrastructure component takeover, if a system secret, like a remote access key, is leaked.

rules/S6472/docker/metadata.json

@@ -0,0 +1 @@
+{}

rules/S6472/docker/rule.adoc

@@ -0,0 +1,44 @@
+include::../description.adoc[]
+
+include::../ask-yourself.adoc[]
+
+include::../recommended.adoc[]
+
+== Sensitive Code Example
+
+[source,docker]
+----
+FROM example
+ARG ACCESS_TOKEN
+# Sensitive
+ENV ACCESS_TOKEN=${ACCESS_TOKEN}
+CMD /run.sh
+----
+
+== Compliant Solution
+
+For build time secrets:
+[source,docker]
+----
+FROM example
+RUN --mount=type=secret,id=build_secret ./installer.sh
+----
+
+For runtime secrets:
+
+[source,docker]
+----
+FROM example
+ENV ACCESS_TOKEN=""
+CMD /run.sh
+----
+
+The container is then started with:
+[source,text]
+----
+docker run --env-file .env myImage
+----
+
+include::../see.adoc[]
+
+include::../implementation.adoc[]

rules/S6472/implementation.adoc

@@ -0,0 +1,19 @@
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+== Message
+
+When a dangerous environment variable is found:
+
+* Make sure that using ENV to handle a secret is safe here.
+
+== Highlighting
+
+The environment variable name.
+
+'''
+
+endif::env-github,rspecator-view[]

rules/S6472/metadata.json

@@ -0,0 +1,30 @@
+{
+    "title": "Using ENV to handle secrets is security-sensitive",
+    "type": "SECURITY_HOTSPOT",
+    "status": "ready",
+    "remediation": {
+        "func": "Constant\/Issue",
+        "constantCost": "20min"
+    },
+    "tags": [
+        "dockerfile",
+        "cwe"
+    ],
+    "defaultSeverity": "Blocker",
+    "ruleSpecification": "RSPEC-6472",
+    "sqKey": "S6472",
+    "scope": "All",
+    "securityStandards": {
+        "CWE": [
+            522
+        ],
+        "OWASP Top 10 2021": [
+            "A2"
+        ],
+        "ASVS 4.0": [
+            "1.6.2"
+        ]
+    },
+    "defaultQualityProfiles": ["Sonar way"],
+    "quickfix": "unknown"
+}

rules/S6472/recommended.adoc

@@ -0,0 +1,11 @@
+== Recommended Secure Coding Practices
+
+* Use Buildkit's secret mount options when secrets have to be used at build
+time.
+* For run time secret variables, best practices would recommend only setting
+them at runtime, for example with the `--env` option of the `docker run` command.
+
+Note that, in both cases, the files exposing the secrets should be securely
+stored and not exposed to a large sphere. In most cases, using a secret vault or
+another similar component should be preferred. For example, *Docker Swarm*
+provides a *secrets* service that can be used to handle most confidential data.

rules/S6472/see.adoc

@@ -0,0 +1,6 @@
+== See
+* https://docs.docker.com/engine/reference/builder/#env[Dockerfile reference]  - ENV command
+* https://docs.docker.com/engine/reference/builder/#run---mounttypesecret[Dockerfile reference] - RUN command secrets mount points
+* https://docs.docker.com/engine/swarm/secrets/[Docker documentation] - Manage sensitive data with Docker secrets
+* https://cwe.mitre.org/data/definitions/522.html[MITRE, CWE-522] - Insufficiently Protected Credentials
+* https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[OWASP, TOP 10 2021] - Cryptographic Failures