Free software version of static scanner widely known/used:
Note: free version can be downloaded locally
Or we can be integrated it into github and/or gitlab side as well but a request need to be filled:
Coverity is static code scanner which can be integrated in github:
Note: the integration free of cost, but the software is proprietary (but since its only added on github side i think its safe?)
Inspiration:
@arraybolt3 Ever tried any? what do you think about them?
I haven’t tried any of these tools personally. I don’t have anything against them, in theory they sound like a great idea, depending on how the scanning is done. (I.e., if SonarQube’s Python scanner expects your Python projects to be well-structured packages intended for PyPI, it’s going to choke on basically every Python project we have here, since we use a Debian-packaging-focused approach to Python packaging that doesn’t involve Python’s package management at all.)
Looking at Coverity in particular, I do not like the following part of its terms of service:
You agree that You will not post the images of the Software or the results of the analysis provided by the use of the Software.
What the heck?! I can use Coverity to find problems in my software, but I can’t show other people what it found, not even after I fix the issues it finds? This runs directly counter to our goals of transparency. Certainly we don’t want to publish any results until after the issues have been fixed, but I’d be very interested in publicizing the results once the corresponding issues were fixed. Also, how deep does this restriction run? Are we just not allowed to export a report and share it with the world, or would it be against the rules to make a writeup about a vulnerability Coverity found, how the vuln worked, and how we resolved it?
Also, what’s with this secrecy about what their software looks like? Are they trying to prevent people from making a tool that looks like Coverity, either to gain a competitive advantage or as a form of security by obscurity? It’s not that there aren’t good justifications for this, but it’s a strange requirement.
I’m also not thrilled with this (from their FAQ, not the terms of use):
…Black Duck may set planned publication dates for the full analysis results of a project.
I can see there’s a strong argument for this kind of a provision since projects shouldn’t be knowingly distributing unsafe code, but it also means that if someone’s going to use Coverity, they need to be ready to dedicate time to fixing whatever it finds or documenting why what it finds isn’t a vulnerability. I’m also slightly ticked off that I’m not allowed to publish the results of a scan, I only get to fix what it shows me, but they’re allowed to show the results of the scan, which may include details of vulnerabilities in my code, whenever they want.
Finally, the tools used for actually uploading things to the service are closed-source. Again, I don’t have anything against using closed-source tools, but given the weird, borderline-shady issues I see from a quick glance, I’m not sure I trust running a tool like this on a machine that has write access to my repositories. At the very least I’d want it sequestered into its own qube.
Ultimately, I can see this being useful, but it’s concerning to me in a few spots. The only thing that really worries me is that I’m not allowed to share analysis results. If anything, I’d want to talk to the people behind Coverity and get some clarity on what is and isn’t allowed and why before telling it to scan our product code, lest some legal term make it so we’re not legally able to fix a vulnerability or something ridiculous like that.
SonarQube doesn’t have support for C in the open-source version, and the majority of our “dangerous” code is in C. This makes it of somewhat limited use IMO.
Neither Coverity nor SonarQube can handle Bash code, which is a bit disappointing but it is what it is. For Bash specifically, I have a license for a (sadly closed-source) Bash linting tool called BashSupport Pro, which runs as a plugin for JetBrains IDEs. I use it quite a bit during Kicksecure-related work, it’s found several issues like global variables that shouldn’t be global, variables that aren’t in use, bad or misleading syntax, and the like, it’s basically ShellCheck on steroids. It’s about as good at scanning Bash as MyPy + pylint is at scanning Python, which… is decent, but it doesn’t sound like the kind of thing Coverity does, so I don’t really know if this counts.
tl;dr: of all the above - SonarQube doesn’t look particularly useful. Coverity does but it scares me, I’d want to talk to them before using it. I wish one of these tools supported Bash and shell script analysis.
Thank you for the insight.
True not clear what do they mean by what they said, doesnt harm asking about it.
It’s worth noting both GCC and Clang have built-in static analysis features. GCC’s is particularly easy to add, simply add -fanalyzer to the list of compiler flags. We should probably be using that where appropriate (it can’t be enabled on all builds since it will have false-positives, but we could probably add a build mode that uses it to some of our C code).
I think this part where coverity gonna be useful, because it will mach the code issues VS their database rather than just random thrown errors, but it needs a test to confirm that.
Also it has Python analysis.