-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci(CodeQL): Add vulnerability scanning using CodeQL #89
ci(CodeQL): Add vulnerability scanning using CodeQL #89
Conversation
This is a first attempt at setting up vulnerability scanning using the CodeQL workflow. Signed-off-by: Cassandra "ZZ Cat" Robinson <[email protected]>
…nable-code-scanning-with-CodeQL
The Quality Control will only build-check the Defect Detector instead of build-checking all compatible development boards. This temporary speeds up development of CodeQL integration.
This explicitly uses the Defect Detector environment. This is HIGHLY EXPERIMENTAL and is likely to be broken. Further refeinemnts and fixes are on the way.
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. |
Right-oh. By rights, that should be it for this Pull Request. =^/.^= I will re-name the |
codeql.yml
Okay, as it turns out, CodeQL is still returning errors, but thar "silently failing" instead of showing up here. But, for now, after I reinstate build-checking on all compatible targets, this Pull Request is getting merged. |
Overview
This is a first attempt at setting up vulnerability scanning using the CodeQL workflow.
This is currently a work-in-progress, and it's a very new concept to me. So, it may take some time for this to be fully operational. Any releases that I have planned are blocked until this is complete.
Update 2024-4-20
I have discovered that it's entirely possible to port my embedded development projects to Rust via this repository.
This is fantastic news for me. However, this MAY NOT happen for a while. But, when it does, it will appear in one of the next
MAJOR
releases (EG Version 2.x.x, 3.x.x etc) and it will depend on where my priorities are at, at the time.When the time to "pull the trigger" gets closer, I will write a post in my Discussions tab about porting to Rust and discontinuing support for C++.
For the time being, I am still writing this Pull Request, and enforcing security practices that are already present in C++. In fact, that reminds me: I need to write up a security policy for CRSF for Arduino.
Update 2024-4-19
Xzutils backdoor incident has prompted re-prioritising this Pull Request
This Pull Request is now my top priority in the wake of the xzutils backdoor incident, which was a supply chain attack.
This has made me realise that I, as a developer, and a singular maintainer of a project (that's starting to gain popularity), that I am equal parts as vulnerable as well as my project CRSF for Arduino.
My last three Pull Requests #115, #116 and #117 were a part of me laying down some of the foundations for this Pull Request.
I now have enough information that states C++ is not memory safe.
So, what am I to do? I could go ahead and port this over to Rust. However, this project targets Arduino-compatible development boards and projects. Which means that the status quo is C++, and it will stay that way due to the inertia of that status quo. Not my call to make, unfortunately. If Arduino and PlatformIO themselves were to both switch to a memory safe language (such as Rust), I'd embrace it in a heartbeat.
Crikey, if I had my way, I'd be using Rust and Python by default, because both languages also appeal to my love for being on the bleeding edge.
The best thing I can do moving forward is to do my due diligence and take all precautions necessary to minimise the risk of vulnerabilities cropping up in CRSF for Arduino.
One thing in particular is with the entire design of the library itself. One-or-two eagle-eyed folks has commented on my library and it's no mistake that it doesn't resemble a traditional "Arduino Library", no.
That's because for the most part, I am not even using Arduino's "language" at all. I am using C++ itself, and CRSF for Arduino's layout is based on C++ core guidelines as well as some information I have taken from their "coding standards" section of their FAQ.
Plus, I am also constantly researching ways to improve my code in favour of balancing performance with stability and (more recently) making my code more secure (and way less vulnerable).
Why am I doing this
"Why are you doing this?"
That's not what the question should be.
What you should be asking yourself is "why aren't more firmware developers taking the vulnerabilities in their code-bases more seriously... especially in the maker community and the wider open hardware community?"
Because that is what I am constantly asking myself, nearly every time I turn my head in this community.
The norm is to not bother with it "because it doesn't affect me".
Well, I don't conform to the norm, for a start.
Outside of firmware development, I take security and privacy very seriously.
This Pull Request is me extending my attitude towards security to my development space. The more steps I can take to reduce vulnerabilities in CRSF for Arduino's code-base, the better it will become. I say that, because minimising vulnerabilities has the flow-on effect of significantly reducing the chances of bugs in the code-base as well.
Details
GitHub's definition of CodeQL states...
This implies that CodeQL is a part of GitHub's own built-in code scanning feature, which they define as...
I am creating and enabling CodeQL to improve on the existing quality control that is already in place.
Doing this may increase the reliability of CRSF for Arduino and provide peace-of-mind to my user-base, where what you see is what you get, and the philosophy of "it just works".
Speculation: This could have an added benefit of making CRSF for Arduino more secure.
As far as I am aware, there is not a lot of Arduino libraries out there that have this feature enabled, let alone anything RC-centric. Thus, CRSF for Arduino could be the first of its kind to have this.
Given what I know about C++ (from my own experiences and through extensive research into the language itself, since 2014), the language is inherently vulnerable. The fact that it isn't "memory safe" speaks for itself.
Therefore, this presents a need to have vulnerability scanning enabled, so my contributors and I can catch these vulnerabilities and deploy patches as and when the need to do so arises.
Additional
During the development of Version 1.0.0, I hinted at the possibility of performing unit testing.
As far as I am aware, PlatformIO is the only one that supports unit testing.
Given the vast range of devices that CRSF for Arduino is compatible with these days, unit testing literally every device in the Compatibility Table may not be realistically possible for one individual to accomplish.
Therefore, I may put this up to my user-base at large, to provide me with unit tests of the hardware CRSF for Arduino supports. I am able to get the ball rolling on some SAMD21 and SAMD51 targets, because these are what I currently have available on hand.