SonarQube cloud cannot find plantet bug

[JeppeSondergaard]

I am using sonarqube cloud on my python code via github actions. I am using the Sonar-way profile.

I have plantet this insecure code:

# Vulnerable code: hardcoded credentials
def connect_to_database():
    # whaaaart
    username = "admin"  # Hardcoded username
    password = "secretpassword"  # Hardcoded password
    print(f"Connecting with {username} and {password}")
    # Code to connect to the database goes here...

# Example function call
connect_to_database()

I am expecting this to show up in sonarqube cloud as a security issue.

SonarQube is not catching this at all. Can someone help me? Is this the expected behavior?

It does find Reliability and Maintainability issues in the same file, which leads to believe that the file with the plantet insecurity is being scanned.

Below I have added two screenshots from the code. First screenshot showing where it does not find the plantet bug and the second screenshot, where it caught a datetime bug in the same file.

[gabin.laigle]

Hey Jeppe, welcome to the community, and thanks for raising this issue with us!

This is an expected behavior, as the code snippet lacks the actual connection to the database. Our code analyzers rely on these “sensitive calls” to detect the passwords. For example, this snippet would raise an issue:

import psycopg2cffi

def connect_to_database():
    username = "admin"
    password = "secretpassword"
    psycopg2cffi.connect(
        dbname="my_database",
        user=username,
        password=password,
        host="127.0.0.1",
        port="5432"
    )

connect_to_database()

In SonarQube Cloud:

Also, note that we’re currently working on supporting more of these Python packages, the detection improvements should be released on SonarQube Cloud in a few weeks.

Thanks for your investment in our products, and if you have more questions let us know!

[Hendrik_Buchwald]

Also worth noting, there is a hotspot S2068 to detect hard-coded passwords simply by looking at the variable name. As this is prone to false positives, we added certain counter measures to keep the number of false positives lower: it will not raise an issue if the sensitive keyword is also part of the hard-coded string (“password”). So if you change your code to something like password = "supersecret" a hotspot will be raised as well.