Quality Gate Passed on PR having a security issue in Dockerfile

[juanfer007 (Juan Fernando Gutierrez)]

• ALM used: Azure DevOps

• CI system used: SonarCloud paid plan - Azure DevOps

• Languages of the repository
  Only a Dockerfile in repository

• Error observed (wrap logs/code around with triple quotes ``` for proper formatting)

Hello.
First of all, Thank you for having corrected the problem in this topic: Dockerfile indexed with language 'null'

My problem is still linked to the Dockerfile

SonarCloud indexes and treats my file, but although it has a security error, the quality gate does not identify it.

My quality gate has the rule active, and does not recognize the problem, neither from a pull request, nor from my main branch or a scan on main main branch directly.

In the analysis, the new lines are recognized as new lines of code but are not classified as High Severity, as described in rule docker:S6437 (Credentials should not be hard-coded).

I would like to know if it is an error on my part or if there is really a problem in the service.

• Steps to reproduce

Current lignes in my Dockerfile on main branch

FROM ***.jfrog.io/dotnet/sdk:6.0 AS BuildEnv
WORKDIR /app
RUN dotnet new webapp
RUN dotnet publish -c Release -o output
FROM ***.jfrog.io/dotnet/runtime:6.0-alpine3.17
WORKDIR /app
COPY --from=BuildEnv /app/output .
EXPOSE 8080
ENTRYPOINT [ "dotnet" , "app.dll" ]

New incoming lignes in my Dockerfile in Pull Request

FROM ***.jfrog.io/dotnet/sdk:6.0 AS BuildEnv
WORKDIR /app

# Noncompliant
RUN ssh-keygen -N "passphrase" -t rsa -b 2048 -f /etc/ssh/rsa_key
RUN /example.sh --ssh /etc/ssh/rsa_key

RUN dotnet new webapp
RUN dotnet publish -c Release -o output
FROM ***.jfrog.io/dotnet/runtime:6.0-alpine3.17
WORKDIR /app
COPY --from=BuildEnv /app/output .
EXPOSE 8080
ENTRYPOINT [ "dotnet" , "app.dll" ]

Yaml Pipeline

trigger: none

pool:
  vmImage: ubuntu-latest

steps:
- checkout: self 
  fetchDepth: 0
  
- task: SonarCloudPrepare@1
  inputs:
    SonarCloud: '***'
    organization: '***'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: '***'
    cliProjectName: '***'
    cliSources: 'SonarCloud/sonar-docker'
    extraProperties: |
      sonar.verbose=true

- task: SonarCloudAnalyze@1
  displayName: 'Run SonarCloud analysis'

- task: SonarCloudPublish@1
  displayName: 'Publish results on build summary'

Thank you very much for your help

[jonas.wielage]

Hello @juanfer007

thanks for raising this topic and adding the proper reproducer.

The SonarCloud analysis behaves correctly in this case, as the Dockerfile you provided should not raise an issue on the ssh-keygen command.

In S6437 we only consider raising issues in the last image of a Dockerfile, as it’s the only image that gets published.
Using this ssh-keygen command in the first (and not last image) of a Dockerfile – like in your example – is safe here, as the key itself will only be set in this image and not be reused.

We changed this behavior in the current release of the Docker-Analyzer to reduce the amount of False-positives. So in older versions, this may still be detected.

Looking at rule S6437, we will adapt the rule description to explicitly state this behavior, as it can lead to confusion.

Best,
Jonas

[juanfer007 (Juan Fernando Gutierrez)]

Thanks for your reply @jonas.wielage