applies_to_file_regex tag doesn't work propertly

[ganchix]

Describe the bug

The following regex in applies_to_file_regex doesn't work properly:

^(?!\/.configuration$)\/.+\/.configuration$

The regex search .configuration files in folders or subfolders but not in the root, using the following rule:

 {
    "name": "DES",
    "id": "DES1",
    "description": "This is a description",
    "applies_to_file_regex": [
      "^(?!\\/.configuration$)\\/.+\\/.configuration$"
    ],
    "tags": [
      "Configuration"
    ],
    "severity": "critical",
    "patterns": [
      {
        "pattern": "^",
        "type": "regex",
        "scopes": [
          "all"
        ],
        "modifiers": [],
        "confidence": "high"
      }
    ]
  }

Inspector detects the root file:

I tested the regex using an online regex tester and seems to be ok:

To Reproduce

1. Create rule and folder with .configuration file
2. Run inspector with analyze with HTML output

Expected behavior

The root file won't be detected by Inspector using the regex expression.

Operating Environment (please complete the following information):

• Application Inspector Version: 1.9.22
• OS: MacOS 14.5 using docker image mcr.microsoft.com/dotnet/sdk:8.0

[gfs]

Hi @ganchix, Sorry you're having trouble but I'm unable to reproduce this.

[ganchix]

Hi @gfs

To reproduce use the following command

appinspector analyze -s /project -r /rules

In the folder project add the following structure:

• project/.configuration
• project/testDir/.configuration

In the rules folder, add the rule.

The output should be 1 match, but it is 2.

The difference is that the whole project folder is analyzed using the two structures.

Thank you!

[gfs]

Hi @ganchix,

Sorry, I'm still unable to reproduce this, here's what I tried.

I tried with the command you recommend above but it results in 0 matches due to missing the -u argument for scanning unknown file types. When debugging custom rules I find it's also useful to include -i to exclude the default rules, and -S to force single threaded behavior to isolate if the issue is related to a threading bug - though that does not appear to be the case here.

Once adding -u I got the results I sent the screenshot of in my previous reply - as expected by the regex the file at /.configuration is ignored but the file at /testDir/.configuration is not.

Based on the regex you provided, a file at /project/.configuration should not be skipped, because it is not at the root of the filesystem (also as seen in the regex screenshot from your report). The file regex is performed against the full file path, not the relative path from the scan folder (unless the scan folder is specified as a relative path, more on this below*).

If I modify your regular expression to include the full path to the .configuration file in the project root as you indicated you're attempting in your second message it still seems to be working fine to me. Something like this:

Here are two runs, first using your original regex, and second using a regex which excludes the .configuration file in the project folder root. Before each run in the screenshot, I cat out the contents of the rule being used. You can see with your provided regex run it finds two matches from the two .configuration files, but with my modification it only finds one match:

I'm using the same file structure you mention in your follow-up message:

If you want to ignore files located at /some/path/to/project/.configuration without using the full absolute path you could try something like ^(?!(/.+)?/project/.configuration$)/.+/.configuration$. Note that /.configuration in the absolute file root still isn't matched because of the /.+/ in the second part of the regex, Its up to you if that's your intention for the regex.

I also see the same behavior if the rules are loaded from a folder containing the rule json rather than the explicit path to the rules.

Please let me know if that helps or if you still believe there is an issue I'm missing here.

• I do believe I've identified one issue here, if you specify the scan path as a relative path, the paths used to check the file regex will be relative paths (that include that initial provided directory) rather than absolute paths. Though that issue doesn't seem to result in the behavior you've seen with your regex, since the paths will then also be missing a leading /, resulting in no matches in your case.