What about using Google Cloud Shell (https://cloud.google.com/shell/docs/; free, open to anyone with a Google account) as a jump host to your servers? Or using GCE's ssh-in-the-browser feature (https://cloud.google.com/compute/docs/ssh-in-browser) to connect to your own GCE VM (not free, in this case) and using it as jumphost?

Both Cloud Shell and SSH-in-the-browser use an in-browser SSH client, so the connection is encrypted all the way and not MITMable.

p.s. full disclosure: I work at Google on the team that maintains both of the above.

Azure also has a similar feature (https://azure.microsoft.com/en-ca/features/cloud-shell/) with built in VS code based IDE.

Cloud shell allows Google to see what I type on the shell machine. So if I ssh from there into the target, nothing is gained and it's MITMable by Google. The only difference is that it's less likely to happen.

That's fair. Although there are pretty tight internal controls on what Google can do on your Cloud Shell, you have to put a certain level of trust into Google here. Getting your own GCE VM and using SSH-in-the-browser is arguably more secure. Last I checked an f1-micro VM would suffice and fits under the 'always free' GCE cap.

Sonar used to be just about running other open source tools, such as FindBugs, PMD, and Checkstyle. (BTW, Code Spotter runs FindBugs alongside Coverity analysis to complement the results). Sonar later added its own rule engine (Squid). More recently, I've come across SSLR - SonarSource Language Recognizer - which looks like a library for building custom coding rules.

Still, Coverity analyzer (which is what's behind Code Spotter) does deep interprocedural analysis and finds very different kinds of issues. I think the best way to see the difference is to try it out on a sample project.

You can run on a hosted continuous integration service, such as Travis CI. The documentation is a little thin right now, but we will add this to the docs soon.

Why upload the code if you can git clone it?

Only if it comes from a repo that's hosted somewhere (i.e., not behind a firewall). Code Spotter is not restricted to GitHub, git, or any other particular SCM. If the code can be built, it can be analyzed.

Sure, but if the code is already hosted on a public git, it would be more convenient if you could simply clone it.

There's a bit more to it. It's not enough to point Code Spotter / Coverity to a pile of code, it needs to observe the actual build in order to know precisely what is built and how it is built. While for some projects you can extract that information from the build files (e.g., maven poms), there are cases where this will fail. (For example, when the build generates some of the source files.) The most reliable way to understand how a project is constructed is to observe an actual build.

This is particularly true for C/C++ and C#, which are not yet supported on Code Spotter, but will be in the future. This precise understanding of a project's composition is one of the many reasons Coverity false positive rate is relatively low.

Why? It is a new product (though based on the existing technology), a new model (cloud-based vs traditional Coverity on-premise), it is in free and unlimited beta, and we are soliciting feedback. Seems like a reasonable "Show HN", no?

It is indeed a reasonable Show HN.

https://news.ycombinator.com/showhn.html.

A new feature normally wouldn't qualify. A new product is fine, as long as people are able to try it out.

Not saying it's wrong just that Show HNs aren't usually for products made by established companies.

I believe the reason he may have found it weird is that Show HN were once about weekend projects.