Add CodeQL Scan

[BramVWS]

Changes

Add a security check by enabling CodeQL, this provides more insight into the security quality of the code.

Issue link

Closes #4077

Demo

QA notes

Make a Pull and it will be shown in the tasks overview.

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue.
• I have written unit tests for the changes or fixes I made.
• I have checked the documentation and made changes where necessary.
• I have performed a self-review of my code and refactored it to the best of my abilities.

• Tickets have been created for newly discovered issues.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[CLAassistant]

All committers have signed the CLA.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[ammar92]

Nice work 👍 Thanks for extending the documentation about this topic. I only have a few tiny remarks and suggestions, let me know what you think.

Also for a next time, let's keep the scope smaller. The other workflow suggestions seem to be not relevant for CodeQL. From a DevSecOps view I can see why you'd pin the actions like this, but imo it seems quite inconvenient to apply it like this. We use common GitHub Actions in our workflow and Dependabot keeps an eye for vulnerabilities.

Perhaps we could pin on specific release tags, this is easier to read and update for us as maintainers and also compatible with Dependabot? What do you think @underdarknl @dekkers

I do like the permissions suggestions, this enhances security and prevents mistakes

[ammar92]

Suggested change

	The OpenKAT project uses a variety of tools to ensure the security of the coWdebase. These include:
	The OpenKAT project uses a variety of tools to ensure the security of the codebase. These include:

[ammar92]

Suggested change

	- Github Actions
	- GitHub Actions

[ammar92]

Suggested change

	To scan for vulnerabilities in our code base we use the built-in tool from Github, Dependabot.
	To scan for vulnerabilities in our code base and keep dependencies up to date, we use Dependabot, a tool for automated dependency updates built into GitHub.

[ammar92]

I think code smell is not the correct term for this. Code smells are traces in the code that indicate a deeper problem that should be addressed or refactored. They are not necessarily errors or bugs but rather violations of design principles and best practices (aka bad code) which can lead to maintainability issues.

CodeQL focuses on discovering vulnerabilities in the codebase, whereas linters are more commonly used to detect code smells.

(You could use CodeQL to detect code smells by querying AST trees to find specific patterns, but this requires writing intricate queries and is not the primary focus of CodeQL.)

[BramVWS]

Nice work 👍 Thanks for extending the documentation about this topic. I only have a few tiny remarks and suggestions, let me know what you think.

Also for a next time, let's keep the scope smaller. The other workflow suggestions seem to be not relevant for CodeQL. From a DevSecOps view I can see why you'd pin the actions like this, but imo it seems quite inconvenient to apply it like this. We use common GitHub Actions in our workflow and Dependabot keeps an eye for vulnerabilities.

Perhaps we could pin on specific release tags, this is easier to read and update for us as maintainers and also compatible with Dependabot? What do you think @underdarknl @dekkers

I do like the permissions suggestions, this enhances security and prevents mistakes

@ammar92 thanks for the review. The addition of the hashes is because these are finding from CodeQL. In this article it's nicely explained why you would want this: https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash.

Also Dependabot supports this syntax: dependabot/dependabot-core#4691 so updating should not be an issue. But let's do an open discussion because I do understand your concerns.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud