Closed b4yuan closed 1 year ago
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.
Hello @b4yuan. Thanks for this valuable contribution. I do, however, have a few questions:
Because oil and the examples are already built in our current workflow and to do it again here would be to duplicate existing work.
Could you modify the PR to remove unneeded step if any ?
Best regards
Regarding 1 and 2, we built as many examples as possible in an attempt to cover as much of the codebase as possible in the analysis. We agree, duplicate build instructions are annoying.
If you are concerned about duplicating the lines of code for building: Ideally, one copy of build commands can be used by both existing workflow and our CodeQL WF.
If you are concerned about duplicating the build process, where the existing WF and the new WF need to build twice, this is necessary as CodeQL requires the code to be built before analyzing.
Regarding what 'needs' to be built... ultimately this is up to the developers of the repository to decide what parts of the repository/examples warrant a security analysis. We would push for more coverage, but this is just a matter of configuration.
The cron in codeql.yml
is there so that the workflow runs nightly.
The workflow is not executed on a push to master currently, but it's executed on every PR and it's also executed nightly. Should you want to modify it to run on every push to master, this can be done.
Let me know your thoughts!
To follow up: https://github.com/TrampolineRTOS/trampoline/issues/125, https://github.com/TrampolineRTOS/trampoline/issues/126, and https://github.com/TrampolineRTOS/trampoline/issues/127 were bugs that we found using CodeQL.
If I understand well, the code must be compiled for CodeQL to be able to check the code generated by GOIL. In that case, maybe we can integrate this PR (maybe removing the cron and adding the workflow triggering on master branch push before). Later on, we can think of a way for the current build CI to share the built directories with the CodeQL workflow. The advantage of the current build CI is that it builds all examples in parallel to save time, so this would be nice to keep.
@RICCIARDI-Adrien This is correct, the code must be compiled. As always, the CodeQL documentation is here: https://codeql.github.com/docs/
Summary
This pull request introduces a CodeQL workflow to enhance the security analysis of this repository.
What is CodeQL
CodeQL is a static analysis tool that helps identify and mitigate security vulnerabilities. It is primarily intra-function but does provide some support for inter-function analysis. By integrating CodeQL into a GitHub Actions workflow, it can proactively identify and address potential issues before they become security threats.
For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
What this PR does
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
Validation
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Using the workflow results
If this pull request is merged, the CodeQL workflow will be automatically run on every push to the main branch and on every pull request to the main branch. To view the results of these code scans, follow these steps:
Is this a good idea?
We are researchers at Purdue University in the USA. We are studying the potential benefits and costs of using CodeQL on open-source repositories of embedded software.
We wrote up a report of our findings so far. The TL;DR is “CodeQL outperforms the other freely-available static analysis tools, with fairly low false positive rates and lots of real defects”. You can read about the report here: https://arxiv.org/abs/2310.00205
Review of engineering hazards
License: see the license at https://github.com/github/codeql-cli-binaries/blob/main/LICENSE.md:
False positives: We find that around 20% of errors are false positives, but that these FPs are polarized and only a few rules contribute to most FPs. We find that the top rules contributing to FPs are: cpp/uninitialized-local, cpp/missing-check-scanf, cpp/suspicious-pointer-scaling, cpp/unbounded-write, cpp/constant-comparison, and cpp/inconsistent-null-check. Adding a filter to filter out certain rules that contribute to a high FP rate can be done simply in the workflow file.