Consider a unique naming scheme for advanced-security queries to highlight alerts vs codeql built in

[felickz]

When using the packs here, I find myself scratching my head when looking at a list of alerts trying to understand where the results came from ... the CodeQL built-in query vs an advanced-security query.

Since we are bound to the UX that is provided to code scanning, we might consider using a built in mechanism like a specific path in the query metadata

When looking at the list of alerts in code scanning, the ID's are not visible unless using the filter .. here some indicator in the description might help?

 * @id cs/as/hardcoded-credentials-symmetricsecuritykey
 * @name (AS) Hard-coded credentials
 * @description Credentials are hard coded in the source code of the application.

This will also help in the scenario where we are naming our queries the exact same id as an existing query - just slightly enhanced

Maybe overkill and just the id would help.. this requires you filter or look at the individual alert (you can see some indication here as there is no hyperlink to the Query "view source").
A moniker such as advanced-security or field or as (shorter) in the path

• ex:

 * @id csharp/as/weak-sensitive-data-hashing

[aegilops]

Nice to see my queries in the example 😁

It's not a bad thought at all. It'd be great if the pack was reflected in the UI somehow, but until then we can overload the ID or the description.

If we do put anything in the description I'd put it at the end vs the start, since developers will just want to act on alerts, and aren't focussed on the origin of the rule.

Given that most users of alerts won't be focussed on the origin, I'd say putting it in the ID is best, and something like csharp/as/... is a decent compromise, but it does mean that we can't easily filter by just as rules in the results.

Do I need to fix my IDs to csharp/... instead of cs/...? Didn't notice I'd done that!