A security team at a fintech wants their organisation's standard CodeQL analysis to run the default security queries for each language plus three of their own internally written queries, while permanently suppressing one noisy built-in query that fires on a framework they have hardened away. They want this defined once and reused across every repository's code scanning workflow. Which artefact should they author and reference to express exactly this set of queries?
# org-standard.qls
- description: Org standard security suite
- import: codeql-suites/javascript-code-scanning.qls
from: codeql/javascript-queries
- queries: '.'
from: acme/javascript-custom
- exclude:
id: js/noisy-framework-rule- AA custom query suite definition in a .qls file that imports the language's code-scanning suite, adds the custom pack's queries, and uses an exclude filter on the unwanted query's id, then reference that .qls through the workflow's queries input. Correct
- BA single CodeQL query file that wraps the three custom queries with an import of the built-in suite and a where clause that filters out the noisy rule by its id at evaluation time.
- CA repository ruleset that lists the three custom queries as required status checks and adds a rule marking the noisy built-in query as a dismissable alert that is auto-closed across the organisation.
- DA code scanning configuration file that lists the three custom queries under a queries key and adds the noisy query's id under a paths-ignore key so that query is filtered out and never analysed.
Why A is correct: A .qls suite definition is exactly the reusable instruction set that composes existing suites with custom queries and applies include or exclude filters by metadata such as id, so importing the built-in suite, adding the custom queries, and excluding one id by metadata produces precisely the requested set. Pointing the queries input at the published .qls reuses it across every repository.
Why B is wrong: A .ql query file evaluates one query and cannot import a suite or aggregate other queries, and a where clause filters result rows within that one query rather than selecting which queries run. It confuses authoring a single query with composing a suite of many.
Why C is wrong: Rulesets govern branch and push protections and required status checks, not which CodeQL queries execute during analysis, so they cannot add custom queries or remove a built-in one from the run. It reaches for a governance control that does not shape the analysis query set.
Why D is wrong: The code scanning config file's queries key can add query packs but its paths-ignore key filters source files by path, not queries by id, so it cannot suppress one specific built-in rule. It misuses a path filter to try to drop a query.