PSScriptAnalyzer doesn't seem to be using the SuppressMessageAttribute ctor fields as intended.

So here is an example of how PSScriptAnalyzer is using this attribute to target a parameter:

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSProvideDefaultParameterValue", "b")]
[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSProvideDefaultParameterValue", "a")]
Param([string]$a, [int]$b)

But the intent of the first two parameters of the SuppressMessageAttribute constructor are to uniquely identify the suppressed rule, and to apply to a parameter would use the MessageId property e.g.:

[SuppressMessage("Microsoft.Performance", "CA1801:ReviewUnusedParameters", MessageId = "isChecked")]
[SuppressMessage("Microsoft.Performance", "CA1804:RemoveUnusedLocals", MessageId = "fileIdentifier")]
static void FileNode(string name, bool isChecked)

So I would expect that every PowerShell suppression of a built-in rule would start like this:

[Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.PowerShell", "PSAvoidUsingCmdletAliases")]

This identifies the rule as a built-in rule. I could imagine custom rules would use their module/assembly name in the first field (category).

Suppression of a parameter should look like:

[Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.PowerShell", "PSProvideDefaultParameterValue", MessageId="b")]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.PowerShell", "PSProvideDefaultParameterValue", MessageId="a")]
Param([string]$a, [int]$b)

Note that MessageId is the field that is supposed to be used if Scope/Target aren't sufficiently precise.

Start by locating the PSScriptAnalyzer code that interprets SuppressMessageAttribute and tracing how its constructor arguments and MessageId are handled. Compare parameter-targeted suppressions with the attribute semantics shown in the issue; done means built-in rule suppressions use the category and rule fields, while parameter-specific targets use MessageId.