Hacker News new | past | comments | ask | show | jobs | submit login
GitLab acquires Peach Tech and Fuzzit (about.gitlab.com)
120 points by factorialboy 8 months ago | hide | past | favorite | 53 comments



Also on https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-too... and https://siliconangle.com/2020/06/11/gitlab-acquires-peach-te...

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


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


@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-...). 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-...). 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).


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.


It might be a fallacy to compare GitLab with Salesforce or SAP. The user base is so different. Developers / engineers are a unique class of users who have high expectations but in their own distinct way.

However GitLab's overall strategy and roadmap is being validated by every step GitHub takes off late. Quite an amazing reversal of roles. Back in the day, GitLab was the "open source copy" of GitHub. Now GitHub is following GitLab's footsteps with their Actions (pipelines) offering, and everything that comes with that (code analyzers, security, deployments etc.) GitHub still has much catching up to do though in some areas.

Long term, competition is good for everyone.

(Disclaimer: GitLab employee)


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


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

https://gitlab.com/gitlab-org/gitlab/-/issues/6883


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


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.


You nailed it. I am personally guilty of creating all kinds of helper tools over GitLab CI/CD madness.

This is exactly what is the problem with GitLab - too many features and high complexity and on the other hand, missing some fairly basic and important stuff.

And then there is that kubernates fetish... :S

I wonder every several weeks what is keeping me on it - is it just sunken cost of my team or there is something more...


What are the top 3 basic and important things that GitLab could add?


1. running CI locally

2. issue relations in core

3. getting a repository file via curl easily (yeah, seriously)


3.1. Get a sane link to a build artifact (something like latest `master`). This can be worked around if you just publish them on Gitlab Pages, a nice solution now that they even have authentication.


1. It does take some effort to get the gitlab-runner to run locally but it is possible to use the shell runner. This does require that you connect the gitlab-runner to an instance of GitLab. If I understand correctly, I think you're asking for the ability to take a `.gitlab-ci.yml` file and run the job(s) locally from your shell without requiring it go through the gitlab-runner and connecting to a GitLab instance. Please correct me if I'm off. 2. I'm not sure I understand what this means. 3. I think this is already possible. E.g. `curl https://gitlab.com/gitlab-org/security-products/license-mana.... Can you elaborate with a few more details on this?


1. a lot of effort and I never want to repeat that, ever

2. issue relations is when you connect issues to other issues (for example, Redmine has both sub-issues and related issues)

3. Can you try that when repo is authorized and let me know how it went ?


1. Yes, I agree. This is something that I personally would like to improved. 2. Oh, I see. I don't have much experience with this one. 3. Got ya. So cURLing a raw file from a private repo. How would you like that to work?


3. I have a link to a file already (in a browser URL bar), let me use it with token or something easy (for example the way most RSS with auth are constructed so that you don't need to set up credentials when 'subscribing') instead of looking for project IDs and constructing path that GitLab can swallow as a query parameter, fighting all kind of nonsence in the process.

FYI, nobody I know did that in a minute (and minute is much for such task) and everybody was like _fuck this shit, I'll just clone entire repo to use a single file_, 15 minutes later.


Thanks, those are clear and concrete. Some quick thoughts (can’t get detailed ones since GitLab is having a friends and family day):

1. This works but not nearly with all functionality.

2. Maybe an options to have related in core and more detailed relations like blocking in a paid version.

3. I’m surprised this isn’t possible already. Is this easy to contribute for anyone?


> 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.

IMO acquiring a small business does not shift focus away from other parts of the product. Peach Tech and Fuzzit now have the support of the rest of GitLab and that benefits everyone. I don't know the headcount of the two companies that were acquired but I would think this would be equivalent to spinning off a small team to focus on an area (fuzzing) that could add value to the greater software community.

The idea that these companies were acquired to check a checkbox is disrespectful to the work that they were doing before the acquisition.

When GitLab decided to give the `.gitlab-ci.yml` a try it was a risk. It seems to have paid off because others started to copy them. Introducing fuzzing to be part of the devops life cycle could be thought of the same way.

> 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.

It sounds like you have some amazing ideas. Contribute them https://gitlab.com/gitlab-org/gitlab/-/issues/new. The issue tracker isn't the equivalent of `/dev/null`. Community contribution is the core of GitLab. Everyone can contribute.

GitHub might host a lot of open source but GitLab is open source.


> Gitlab looks more and more like SAP these days. That's not necessarily a bad thing

Unless you are talking about revenue or profit, then I don't think could you could give a worse insult

> they need tech that covers the most ground with the easiest budget allocation

I think this is the sales pitch of every software product. SAP does not come cheap, in terms of both software and the total cost of moving to SAP. Two classic examples of Lidl pouring 500 Euros into SAP and then walking away and Nike pouring $400 million into a SAP project that was such a disaster they lost $100 million in sales.


Look, you're right, it wasn't meant as an insult but does sound like one since people perceive SAP as a mostly a bad thing even though it's a wildly successful company that has been solving serious ERP problems for 1000s of clients worldwide. I've actually met more people that say "thank god we finally got SAP in here" than people who not. It doesn't mean it's not a dreaded beast, but, think about it, it actually does do a thing or two for a lot of people.

But, OTOH, this is what Gitlab pitches at their website: "A complete toolchain in one application". And "end-to-end platform", and, yes, "thousands of features" (it's literally on their front-page like it's a good thing!).

> I think this is the sales pitch of every software product.

Like SAP, but obviously on a different scale, Gitlab has invested heavy money in Gartner and Forrester analysts. And I've counted at least 40 logos they claim to replace in their huge feature tables. Only SAP/Salesforce-muscle apps typically claim ample and ambitious replacement targets, which are meant to mean "more bang for the buck" but typically mean "less bang and more buck". This heavy display of self-confidence is unprecedented in the DevOps space, where no single app is pitching to replace so many tools given the heterogeneous nature of dev and ops environments. So, I mean, this is very, very cocky marketing on their part, so maybe they do deserve to be called an SAP as in "SAP-the-big-bad-thing" adjective.

So yes, they do look more and more like the SAP-equivalent in DevOps. Gitlab is NOT an ERP, so the size of implementations are in very different scales and orders of magnitude. However Gitlab is more of an enterprise software company than a cloud one and they probably have very high-growth targets as they have raised some serious money from serious investors, which means they probably need to follow a similar path to other platformy enterprise sw behemoths if they are true to the marketing on their front page.


Thanks for your thoughtful comment.

“building a solid platform for dev and ops taking code to production” => great, that is a big focus for us!

We already have invested a lot to make this easier, including environments, feature flags, and more. Our direction is on https://about.gitlab.com/direction/ops/#release

What is the top feature you would like to see?


Hi Sid, there are 2 users already making their points on this thread on the precise core issue I've raised: they have to automate around Gitlab instead of from within. This is what real platforms are about, they give users the tools to customize and make the platform behave the way their org needs it.

The great late Robert Stroud, ex Forrester analyst, was very adamant on how a DevOps platform should focus on weaving the so-called value chain, not replacing it.


> 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.

I will posit that Gitlab knows their own strategy better than you and that they don't acquire companies randomly. They didn't get where they are by randomly throwing darts at the board.

It's not an either/or situation anyway. They most likely already have ressources allocated to the app/api testing part of their business. That's an avenue they have been pursuing for a long time. They must have a fairly solid idea of what their growth potential is there.


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.


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.


@Aeolun - The acquisitions, once integrated, will work just like the other Secure scanners (e.g., SAST, DAST). They will be launched via CI runners within their own containers. As such, Kubernetes isn’t needed. @factorialboy is correct.


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.


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


Biggest features of GitLab has been the integrated CI and the Omnibus docker image.

Those two things are pretty much what makes it better than other self hosted solutions.


Gitlab is much cheaper and for companies building closed source projects there’s no need to be using what the “community” is.


What is "much" with respect to companies?

If company X is paying 10 x (even low) salaries of USD 100K annual, do they want to save say $5K annual if developers do not want?


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


Off topic anecdote on installing GitLab.

My university asked me to install GitLab on a 32bit Dell Server made circa ~2002 while I was a teaching assistant, because we were conducting a hands-on class of reimplementing TCP/IP and IT wanted everything we were doing airgapped off the school network.

Unfortunately the omnibus package is 64bit-only so I had to build from source... which was pretty hard. But I was only able to do that after figuring out how to upgrade from Ubuntu 8.04 to 16.04 with the only input being a CD (not even DVD) drive. I don’t remember why OTA upgrade was failing, I think the version was too old. Managed to get Ubuntu 12.04 or something thinned down enough to fit on a CD. From which network upgrade worked.

Whole process took ~20 hours over a few days. Craziest install I’ve ever had to do... University would have saved a bunch of money if they had just bought us a new small 64Bit server. Ah well.


The Omnibus package is literally a one line install.


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


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


I installed it within 5 minutes locally. If anything, Gitlab is perfect to quickly set up code repositories in environments where on-prem is a hard requirement.


Perhaps it has gotten better. My experience was a few years ago.


> This matters a lot because community is great power, whoever holds it, holds key to future mindshare.

Bitbucket and atlassian are still surviving despite not having any community presence on them. As long as bitbucket offers value(self hosting, CI, etc) and enterprises use them I think it'll be fine.


You see the today, but you miss the tomorrow. If you venture out on the Internet you will see people complaining against them fairly religiously.

Every large enterprise that fell, stood once.


Most companies that I see using Bitbucket do so not because it's a good product but because it's usually cheap when you are already paying for JIRA and Confluence and because of the tight integration with those tools.


@syste

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


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/

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... Maybe the relevant product managers have more to say about the current plans.


@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.


The biggest disadvantage of the buyer based open core model is can completely ignore what the buyer wants (ex: reporters not to be charged the same as developers, because that makes no sense).


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.


There is a joke in all of this:

One could argue that GitLab gets more and more mature but somehow still has Peach Fuzz.


Lol!


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.’


Haha yeah, I know ;-) I had HN open in two tabs and somehow managed to create a mental race-condition and posted my posts in the wrong order.


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? :)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: