
GitLab acquires Peach Tech and Fuzzit - factorialboy
https://about.gitlab.com/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html
======
sytse
Also on [https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-
too...](https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-toolbox/) and
[https://siliconangle.com/2020/06/11/gitlab-acquires-peach-
te...](https://siliconangle.com/2020/06/11/gitlab-acquires-peach-tech-fuzzit-
beef-devops-security-testing-tools/)

We think that Fuzzing will grow in importance as security gets more focus in
the software development process.

~~~
diminish
Anyone has any stats on the adoption of security scanning in general for
devops projects? and fuzzing in particular?

~~~
ddesanto
@diminish - We have some stats related to security scanning which we cover in
our security trends report
([https://about.gitlab.com/blog/2020/04/02/security-trends-
in-...](https://about.gitlab.com/blog/2020/04/02/security-trends-in-gitlab-
hosted-projects/)). It is a very interesting read and would like to hear your
feedback. We also did a survey of fuzzing usage the highlights are here
([https://about.gitlab.com/direction/secure/fuzz-
testing/fuzz-...](https://about.gitlab.com/direction/secure/fuzz-testing/fuzz-
testing/#user-pain-points-to-address)). We are excited about bringing Peach
Tech and Fuzzit into GitLab as we are going to be able to address a big pain
point for adoption of fuzzing (integration into CI).

------
ojosilva
Gitlab looks more and more like SAP these days. That's not necessarily a bad
thing, enterprises out there choose all-in-one solutions because they need
tech that covers the most ground with the easiest budget allocation, POC
efforts from internal buyers and streamlined consulting at the post-sale
effort. But once in, Gitlab, differently from SAP or Salesforce, is customized
from around instead of from within. Meaning, it's not a platform for DevOps,
just a bunch of moving parts that you need to tie together. This leads to very
fragmented installations, with CI/CD running partially from within repos
(gitlab.yml), containers, runner environments, scripts and other dangling
cables.

I've seen more than one company build their own, horrid adhoc internal DevOps
apps with extraneous UIs to help devs navigate different Gitlab CI/CD
configurations. That's where Gitlab should be putting their efforts, in
building a solid platform for dev and ops taking code to production instead of
acquiring middle-of-the-road in-between tech like Peach Tech and Fuzzit, that
add complexity to the core offering without checking many boxes for the
clients seriously on the lookout for app/api testing.

Focus on the platform, enabling integrated customization and implementation
robustness while orchestrating the outside moving parts and a great plugin
ecosystem. Then get that certification program going strong. Right now your
competitor Github "are belong to" Microsoft, and MS, better or worse, sure can
do the platform thing for the many sizes of businesses where the meat of your
revenue is truly coming from.

~~~
orf
I’m a Gitlab fanboy, but you’re right. We run a medium sized Gitlab instance
and wanted to automate a bunch of tasks on it - like you should as a good
adherent to DevOps principals.

But Gitlab is actively hostile to you building automations on top of it. Every
access token is tied to a Gitlab User and every user is charged X$ a month,
regardless of if it’s a bot or not.

So the end result of this is a single bot user with poorly scoped permissions
that can only be configured by an administrator. Great.

They are slowly moving forward with this epic[1] but the discussions around
pricing are ridiculous. Don’t you _want_ people to build automations around
Gitlab, as it makes it more entrenched in your org. Stop making it harder by
effectively charging hundreds of dollars a year per bot user.

Would love any comments you have on that @syste.

1\. [https://gitlab.com/groups/gitlab-
org/-/epics/3559](https://gitlab.com/groups/gitlab-org/-/epics/3559)

~~~
rifelpet
They're addressing the lack of service accounts, targeted for 13.1:

[https://gitlab.com/gitlab-
org/gitlab/-/issues/6883](https://gitlab.com/gitlab-org/gitlab/-/issues/6883)

~~~
sytse
Yep, we want to charge only for people, not bots. Sorry it took a while to
resolve this, it was complex.

~~~
orf
I’m really glad you’ve reached this decision, but I’m still not happy with
being asked “why are these automation tasks costing us $XXX” per year during
our last recent license license update.

Until this epic is completed you are charging people full-seat price for
automation users which, because of the poorly-scoped token permissions,
require multiple “user” accounts to implement securely.

An automation utility in no way delivers the same value as a full time
developer and it really shook me to know that this is how you have
historically valued bots. It runs counter to everything that you publicise.

------
Aeolun
That's cool, but I wish they'd polish the base experience a little bit first.
As well as stop this 'everything on kubernetes' thing. Right now I need
kubernetes for at least half of all Gitlab functionality, and I have no doubt
this latest acquisition will be the same thing.

~~~
factorialboy
I doubt any of the existing GitLab (sast, container scanning, dependency
scanning / gemnasium, etc.) security scans need Kubernetes cluster
integration.

They are normal containerized Jobs, for which all you need is GitLab Runner
with Docker executors.

------
godzillabrennus
Gitlab is making moves and proving it is a real player.

Glad to see the competition in the repository hosting space is strong. It’s
benefiting every developer.

------
brainless
I have a genuine curiosity about GitLab as a business:

Are they actually growing much more in the mindset of developers since GitHub
started doing some things right?

I have personally always wanted alternatives and GitLab* is a good one, but
the reason I can not say they are a great one is because somehow* their story
to me feels too much "against GitHub" than their own story.

GitHub made a lot of mess and eventually they undid some or just enough that
they still retain the lion's share of public repos/projects. This matters a
lot because community is great power, whoever holds it, holds key to future
mindshare.

I want GitLab to be a larger part of the developers mindset everywhere, but I
am not sure that is happening at the moment. Why not? If my assumptions are
wrong, that is also acceptable to me, would like to see some signals.

* typo fixed

~~~
paulryanrogers
Tried locally hosted Gitlab once. It was so cumbersome to install I doubt I'd
ever try again without containers or proven installers.

~~~
LennyWhiteJr
The Omnibus package is literally a one line install.

~~~
stevekemp
Historically their upgrades cause issues; I remember the time I upgraded our
self-hosted installation and LDAP logins were broken, for example.

~~~
dewey
I've never seen anyone complain about the updates, in my own experience you
can always update on day one without any issues.

------
joiningnow123
@syste

Are these soft landing acquisitions as described in your handbook? Also will
the technology be open sourced like Gitter was?

~~~
sytse
Thanks for asking. We don't comment on individual acquisitions beyond what is
in the OP. For everyone else there reference our handbook page about
acquisitions is on
[https://about.gitlab.com/handbook/acquisitions/](https://about.gitlab.com/handbook/acquisitions/)

We won't necessarily open source all the acquired technology like we did with
Gitter and RedHat does with every acquisition. We'll follow our buyer based
open core model [https://www.heavybit.com/library/video/commercial-open-
sourc...](https://www.heavybit.com/library/video/commercial-open-source-
business-strategies/) Maybe the relevant product managers have more to say
about the current plans.

~~~
ddesanto
@joiningnow123 - Thanks for the question. We plan to open source all the
fuzzing engines built by Fuzzit. We also plan to open source Peach Tech's
protocol fuzzer however this will be some time next year when we begin
integrating it.

------
oneplane
This seems to be similar to GitHub adding automated code analysis and
screening as well as detecting flaws in what would become the built artifacts
like external APIs. In a sense they are delivering static analysis which used
to cost a lot of money, time and dedicated manpower (i.e. HP Fortify).

It makes sense for those companies to expand beyond what they already have.
Starting with version control systems, going on to Wikis, static websites,
actions/automation, CI, artifact hosting. It will eventually contain the
entire lifecycle it seems.

~~~
sytse
Lol!

~~~
sytse
Sorry, the lol was meant as a reply to ‘ One could argue that GitLab gets more
and more mature but somehow still has Peach Fuzz.’

~~~
mcny
That’s funnier than the joke itself as I was scratching my head to understand
the joke in

> It makes sense for those companies to expand beyond what they already have.
> Starting with version control systems, going on to Wikis, static websites,
> actions/automation, CI, artifact hosting. It will eventually contain the
> entire lifecycle it seems.

Because from what I understand wasn’t this the goal from early on? :)

~~~
oneplane
On one hand yes, on the other hand there is a difference in making better
products vs. enriching the product by buying other products and integrating
them. On the other hand, there is no single 'right way' of course, and adding
knowledge, people and IP via acquisition is a functional way to do that.

But people will inevitably compare products and with GitLab vs. GitHub it's an
obvious one to make. I do get the feeling that since Microsoft bought GitHub
they are accelerating their feature releases to be more in line with GitLab's
speed.

