Start scanning each GitLab release with a vulnerability scanner

More often, customers are sending us vulnerability scan results and asking us to validate and fix or explain why they're false positives. As part of each release, or even as part of CI, can we start running a vulnerability scan suite? This way we can fix XSS, or explain false positives up front and avoid rushed work when customers contact us. I suspect these types of requests will only increase with time.

cc/ @DouweM @JobV @balameb @stanhu

How good are these scanners anyway, and do they generate lots of false positives? I'd like to avoid creating noise in our test results.

If they're effective, it might be worth it to fold this into our end-to-end or browser testing.

@stanhu Sure, they have false positives, especially in the beginning. But generally you can mark a thing as FP and it won't pop up again. I'm not saying we need to run this as part of CI, but as part of our release process maybe. Almost all enterprises that handle customer data/payments will have a compliance scan requirement in their organization. We'll see more and more of these types of requests as time goes on.

@dblessing Did you have a recommended tool in mind for vulnerability scans? Are there any particular that customers seem to use consistently?

@stanhu, @dblessing: What I'd like to do is get this integrated with the release cycle -- automated and without impacting delivery. I can get a VM or an instance set up to clone all new releases and kick off an automated scan.

@stanhu: You're right, these scans will be full of false positives. But IMHO that's OK so long as the admins and developers never have to see them. Only me/us.

@briann Sounds good.

@briann Love it! Thanks.

We should run this against a stock Omnibus install, too. Some of the reported issues will be something like Nginx SSL/TLS settings, ciphers, etc. We don't necessarily need to modify the defaults in all cases, but at least we can create some documentation that says, "If a scan popped on ciphers, try this setting and rescan". Things like that will be a major win for support.

@briann is it correct that your recent additions to rubocop address this (old) issue?

@ernstvn No. This would be setting up a dynamic web app scanner like Arachni and scanning each release. I think we could dedicate a system to this and just have it scan itself every week using the latest release.

OK; if it is in the Risk Assessment then it will automatically float into the top 10 at some point :-) Is it there?

No, I think this is another one of those "It's number 5 on a list of things to do and we did numbers 1 and/or 2".

So the risk is in the assessment, but in terms of actions there are ~ 5, that type of thing?

This would affect a lot of risks. It helps prevent SQLi, XSS, authorization vulnerabilities, detects vulnerable libraries, service misconfigurations, weak ciphers, etc. There are probably 10 risks in the Risk Assessment that this could be an action for.

Excellent :-) So it sounds like we should update the risk assessment with this. Will remind in a while.

moved to gitlab#4915

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue