Rules do not set severity to severity tag

[aldenbe]

I would like to be able to use the severity tag for specific rules in a ruleset.xml file to be able to better filter output and handle issues in stages, example:

<rule ref="Security.BadFunctions.FilesystemFunctions">
        <severity>1</severity>
</rule>

This phpcs functionality does not appear to be working with phpcs-security-audit rules.

[jmarcil]

I confirm this issue. Took me a while to figure out what was the problem.

Currently we have a namespace issue that breaks the way PHPCS is working.

PR #14 seem to have caused it. I asked the author to validate and update.

[jmarcil]

When this bug is fixed, we should be able to change severity on those different levels:

<rule ref="Security">
<severity>8</severity>
</rule>

<rule ref="Security.BadFunctions">
<severity>8</severity>
</rule>

<rule ref="Security.BadFunctions.EasyXSS">
<severity>8</severity>
</rule>

<rule ref="Security.BadFunctions.EasyXSS.EasyXSSwarn">
<severity>8</severity>
</rule>

[b-roberts]

I agree, the severity levels do not work. This appears to be caused by the namespacing implemented in #14.

The severity is ultimately referenced by this line in PHPCS:
$listenerCode = Util\Common::getSniffCode($this->activeListener);
which is based off of the fully qualified class name of the sniff, for example: PHPCS_SecurityAudit.BadFunctions.NoEvals

In order to fix this the entire project would need to be refactored to the Security namespace or the Security Folder would need to be renamed to PHPCS_SecurityAudit

Either fix would almost certainly break compatibility with any existing integrations.

[jrfnl]

Please consider my proposal in issue #47. What I'm proposing there would/should - aside from removing the symlink hack and updating the install instructions - have no impact on existing integrations. Rulesets referencing the sniffs in this standard would still work or rather, will start working again.