False Negative - YAML Parser Stops Reading After First String Value/Does Not Read Lists of Strings

[RobertRosca]

• I'm submitting a ...

  • [x] bug report
  • [ ] feature request

• What is the current behavior?

Secrets are not detected in (docker compose) yaml files when a top-level entry for a string is present.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

This will not detect any secrets:

version: "3.8"

services:
  foo:
    environment:
      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

But changing the first line to version: 3.8 will:

version: 3.8

services:
  foo:
    environment:
      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

ERROR: Potential secrets about to be committed to git repo!

Secret Type: Secret Keyword
Location:    ./foo.yaml:6

edit: actually, it's a bit more complex, when removing the version value secrets are detected:

services:
  foo:
    environment:
      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

Unless you add in something else which is not a mapping to a string:

services:
  foo:
    build: .
    environment:
      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

Changing environment from a list of strings to a mapping fixes the issue though:

services:
  foo:
    build: .
    environment:
      SECRET_KEY: k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

But then you're no longer able to use docker compose interpolation within the environment variables, which can be a problem if it's being done for some other variables, e.g the following only works when environment is a list of strings, if it's a mapping you can't do this anymore:

services:
  foo:
    environment:
      - SOMETHING_${FOO}=${BAR}
      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM

• What is the expected behavior?

Secrets to be detected when a string entry is present before some nested structure.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • detect-secrets Version: 1.4.0
  • Python Version: 3.11.7
  • OS Version: Arch
  • File type (if applicable): yaml

• Other information

Problem seems to be with the yaml parser, for the buggy case of version: "3.8" the lines variable in detect_secrets.scan:269 is:

['version: "3.8"']

So nothing was parsed after that value, which is why the secret isn't found. For the working case of version: 3.8 it is:

[
  'version: 3.8\n',
  '\n', 'services:\n',
  '  foo:\n',
  '    environment:\n',
  '      - SECRET_KEY=k0l7eDvHl2PhniP0Z146aCOeiw86LGJh5hS2i4LJM\n'
]