10 ms·

GitLab acquires Peach Tech and Fuzzit

120 points by factorialboy 6y ago

sytse 6y ago
Also on https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-toolbox/ https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-too... and https://siliconangle.com/2020/06/11/gitlab-acquires-peach-tech-fuzzit-beef-devops-security-testing-tools/ 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.
- diminish 6y ago
  Anyone has any stats on the adoption of security scanning in general for devops projects? and fuzzing in particular?
  - ddesanto 6y ago
    @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-gitlab-hosted-projects/ 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-testing/#user-pain-points-to-address 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).
oneplane 6y ago
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 6y ago
  Lol!
  - sytse 6y ago
    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 6y ago
      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 6y ago
        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.
    - oneplane 6y ago
      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.
- oneplane 6y ago
  There is a joke in all of this: One could argue that GitLab gets more and more mature but somehow still has Peach Fuzz.
joiningnow123 6y ago
@syste Are these soft landing acquisitions as described in your handbook? Also will the technology be open sourced like Gitter was?
- sytse 6y ago
  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-source-business-strategies/ https://www.heavybit.com/library/video/commercial-open-sourc... Maybe the relevant product managers have more to say about the current plans.
  - ddesanto 6y ago
    @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.
  - apple4ever 6y ago
    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).
godzillabrennus 6y ago
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.
Aeolun 6y ago
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.
- deleted 6y ago
  [deleted]
- factorialboy 6y ago
  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.
- ddesanto 6y ago
  @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.
brainless 6y ago
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
- ponker 6y ago
  Gitlab is much cheaper and for companies building closed source projects there’s no need to be using what the “community” is.
  - brainless 6y ago
    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?
- paulryanrogers 6y ago
  Tried locally hosted Gitlab once. It was so cumbersome to install I doubt I'd ever try again without containers or proven installers.
  - LennyWhiteJr 6y ago
    The Omnibus package is literally a one line install.
    - stevekemp 6y ago
      Historically their upgrades cause issues; I remember the time I upgraded our self-hosted installation and LDAP logins were broken, for example.
ojosilva 6y ago
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.
- factorialboy 6y ago
  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)
- teruakohatu 6y ago
  > 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.

120 points by factorialboy 6y ago

Also on https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-toolbox/ https://devops.com/gitlab-adds-fuzz-testing-to-devsecops-too... and https://siliconangle.com/2020/06/11/gitlab-acquires-peach-tech-fuzzit-beef-devops-security-testing-tools/ 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.

diminish 6y ago
Anyone has any stats on the adoption of security scanning in general for devops projects? and fuzzing in particular?
- ddesanto 6y ago
  @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-gitlab-hosted-projects/ 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-testing/#user-pain-points-to-address 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).

oneplane 6y ago

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 6y ago
Lol!
- sytse 6y ago
  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 6y ago
    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 6y ago
      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.
  - oneplane 6y ago
    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.
oneplane 6y ago
There is a joke in all of this: One could argue that GitLab gets more and more mature but somehow still has Peach Fuzz.

joiningnow123 6y ago

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

sytse 6y ago
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-source-business-strategies/ https://www.heavybit.com/library/video/commercial-open-sourc... Maybe the relevant product managers have more to say about the current plans.
- ddesanto 6y ago
  @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.
- apple4ever 6y ago
  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).

godzillabrennus 6y ago

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.

Aeolun 6y ago

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.

deleted 6y ago
[deleted]
factorialboy 6y ago
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.
ddesanto 6y ago
@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.

brainless 6y ago

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

ponker 6y ago
Gitlab is much cheaper and for companies building closed source projects there’s no need to be using what the “community” is.
- brainless 6y ago
  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?
paulryanrogers 6y ago
Tried locally hosted Gitlab once. It was so cumbersome to install I doubt I'd ever try again without containers or proven installers.
- LennyWhiteJr 6y ago
  The Omnibus package is literally a one line install.
  - stevekemp 6y ago
    Historically their upgrades cause issues; I remember the time I upgraded our self-hosted installation and LDAP logins were broken, for example.

ojosilva 6y ago

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.

factorialboy 6y ago
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)
teruakohatu 6y ago
> 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.