GitLab Secure Stage, 8 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2019.07.08 - Weekly Secure::Static and Dynamic Analysis team meeting

Description

Weekly team meeting from 8 July, 2019.

A

All righty good morning or good day, everybody happy Monday. It is currently at time. So let's go ahead and get started. Let's see who is here.

A

Lucas, you've got the first item, so please go ahead and kick us off hey.

B

Everybody my Internet's not great today, so if I cut out just continue reading the agenda, so um I opened an issue on providing a generic analyzer for our custom security scans. This is kind of been an ongoing issue. That's come up a couple times in conversations and I wanted to get some feedback on this idea. So, instead of having to update our analyzers and change or support any language, every time I use case comes up.

B

I think that we should consider a more generic solution, so basically a more generic kind of just a regex engine and laser. So um certain customers can provide like a regex rule set and just run their since these are custom analyzer to run their own stands for any patterns they detect so like I was kind of an interesting idea and something that would be worth exploring. So I encourage people to take a look at that one and Olivier you of the next point. If you're here.

C

Yeah thanks: this is not 100%, clear right now, I think the documentation is being improved on this. But if you use some topic, labels like SAS that defense is getting sketchy, rot, etc. There are some automation today to help improving the leveling and, if you just add the set, for example, if you just add the SAS double new issue or match request, the bot will pass under on this issue and will add some group level and stage level based on that.

C

So there are some really nice automation and if you don't do that, the issue might be leveled within the wrong group. It's not a big issue, but if we just be more accurate and we improve the leveling, so please think about using Zeus and again it's not super clear right now. So I think there will be some incoming improvement to make it clear what are the topic labels?

C

Because if you, for example, adding something like get LeBonheur, because you think you are discussing something that will be impacting the mid laner, this might actually trigger the bud to add the stage label from a different team, because it's based on that table. So it we need to make a better job at making clear what what is implied by adding some labels.

C

So next one is Victor.

D

Okay, so we have already discussed one spike: I just expanded it here. So my concern is about our SP plorts channel, which has gotten pretty noisy and I, feel that we don't pay much attention to it, because I couldn't know that these pipelines constantly failing on expectations that are not updated on test projects and some other cases on the weekend. I spotted my main maven I. Guess it failed because of some version mismatch. Do the installation of the dependencies installation step so I suggest us to deal with it somehow.

D

I mean from the organizational perspective to because if we consider it not so critical where, when, when we get a new message in this channel, we should like downscale the importance of this chain or change the maintenance routine for this. But if we considered critical, we should have. Maybe our rotation for the maintenance of this channel I also agree with Olivier that this is a recurrent topic of leveraging the multi project pipelines for triggering builds in these test projects.

D

When the upstream analyzer project resonated I have not investigated yet on the status of multi project pipelines. I plan to do this after after this meeting, but still feel free to express your thoughts and your suggestions on this, and maybe I, am the one who believes this is a problem that we don't pay much attention to this channel right now,.

C

Just to mention that shine is actually currently working on this. We have an issue to set up to automatically triggers pipeline from the main project. I need to review the merge request, but we have a port to whether you so muchi project pipeline or something more in-house like what we've done for license management.

C

So we need to figure out what's the best approach, but this should help avoiding zuv states of having stale QA test projects, because this is mainly the issue which am the the main project, and we don't go to all the test projects of that expectation, and so next time something is running there it's broken. Instead, we should be a cure that we always maintain them.

C

So as soon as we are putting changes in the main project, we need to run the pipeline on all the test project and make sure the expectation are today there by automating this. It will be more straightforward.

C

And another annoying thing, but I don't think we can configure it that we are getting notification in the SPL channel for all branches, which is a bit annoying, because when you're working and adding a new and changing card- and you need new expectation- this will trigger your pipeline and we trigger failure. When you have to have that expectation, and if you have some testing there, you will trigger several notification where else it's not relevant, because it's not an alert or C.

C

So we maybe need to find a way if we can tweak the identification system to only one on the master branch and all the freeze branches.

C

Again. I think we're missing time to address those issues.

C

Chinese working on this as part of the iteration, because it was part of his onboarding issues. But maybe we should push more as engineering manager for those more maintenance tasks to be part of the iteration I. Like.

D

The idea of investigating the possible reduction of the amount of the alert to only master branch and freed branches, I guess it could be like a good start for an embassy to deal with this problem.

D

Speaking about the duties of a release, manager I feel that you guys already burdened with too many responsibilities, and this task will be another test on your plate. So I believe it should be automated as much as possible.

D

So, okay, too build some consensus here. I will add a to do on myself to investigate on your suggestion about limiting the alerts to master and trees branches.

D

A

Guess we don't have any new any more items, real, quick, because I'm a little bit confused, it sounds like we got two people chasing the same problem, so Chan's working this part of this and and Victor you've got another part of this. So are we do we have two people chasing a solution to the same problem or are they orthogonal or related? Not.

C

Just related, but it's not the same issue: Shan is working on making sure we run the pipeline on the test project each time we are putting chin genes in them in the main project. That's this. This won't have any impact on notifications which worked. Vito will be really looking closely at how we can tune the notification so, whatever the way we're triggering the pipeline's when they fail, we just want to notify the channel for some specific branches. Okay,.

A

Victor, do you happen to have an issue with what you're working up on working on? What do you mean so you're putting in a bot you've got in some notifications and now we're adding a whole lot of requirements. Is there an issue tracking what you're actually doing I see? No, it's not I will create one. Please do that way. We know what's gone in and that way we can because there's a lot of discussion here.

A

Let's I want to make sure that we're not losing it and that we know what's going in and can track it later.

B

And just to be very, very quick and what this is for people who are unfamiliar at the speeler? It's. It is a slack channel where you notify, when the build fails on a number of our test projects. This channel currently exists and there's probably like eight people in it and when we see a failure in the build that we go fix it.

B

The issue is that we don't always do that, because we all suffer warning fatigue from regular, build failures and that's what we're working on solving but feel free to jump in and check it out. If you want Espie alerts.

A

Love more alert, all right, yeah, all righty, okay, any other conversation on this and I see Ross's added a last-minute addition to the agenda, but before we move to Ross any more conversation on this topic.

C

Yeah there is also some skid align currently, so you might see some others popping up on the Qian, even if nobody asked for changes or of triggering any pipeline on their own. We should also I think there is an issue. I would check for that. To make sure there is a schedule pipeline, a daily schedule pipeline on all the test project to regularly check nothing is broken because we can have updates from the outside that could trigger changes in our pipeline.

C

So this is why sometimes it's failing, but again it should be a very, very specific case, like we just added a new vulnerability in the database. So it's adding a new runner between the project, which is a real life example of neutral RBT being reported. So this is a use case where nobody is specifically assigned to update the cure test project, we're just popping them into Channel, and someone is sticking up as a part and updating things, but it's one edge case. Let's say.

A

Ross you're up.

E

I think it's been brought up before, but in the project drop-down on the security dashboard. If you're, like you're, gonna, filter out my project, you might see multiple Community, Edition or Enterprise editions in trees. Is there? Is there a ticket for that uh-huh and that okay? That was that was? That was what I was wondering if there fork so should they be? Should the fork show up is a fault question, because we do have an open issue for changing how we pull in those projects so that.

E

Would be good to know it like it pulling? Those Forks is the correct behavior.

B

Okay, guys, um if you've worked a project into the same group, then it's just a project within the group. If you four get into a separate namespace, then I don't believe it would show up. Currently, okay, they go be a bit too smart to exclude a fork that was in the same group. So maybe we just need to incur Steven stop forking into that group for virgins, get Alexi Irie.

E

Okay, that that answers that question I'll note that in the ticket, so whoever picks it up isn't confused by that Thanks the end all.

A

Right last call anything any any other, any other item people would like to discuss. Since we have a few minutes left.

A

Silence being interpreted as nothing no.

F

Okay, sorry I thought you forgot about that. Sorry, yeah.

C

We're going to break up again people I'm sorry now this has been raised over time, it's time to do that and we will break the channel. It's just like channel down into subgroups.

C

I should have done that the last week yeah, but there was a lot of people away and me too so I, don't I prefer to learn that in the wiki before changing the group's so raise your hand if you'll get that, but it's been longer discussed, and maybe we just have to tweak the naming I try to come up with something that best address everybody's needs, so we're gonna. We are likely to keep one section level chant for secure and then we will have one specific channel for each group.

C

C

Two groups or three groups: here's a question.

A

My argument is: go ahead and split it to three yeah.

C

A

Let's do it once and be done with it all right? Does anybody have a preference on what the timing of this during this week.

A

Okay, so when Olivier wants to hit the button on the timer and blow everything up, he can all right. Okay, yeah.

C

I will just be a chai I, try, I love it archiving archiving. This channel, sorry I will probably just rename it to s, secure and create new ones for each group, and the good thing is that as s my stand for section of stage, people will be confused. We don't care because in sexual section we only have sexual stage but I guess we don't have stage channels. Oh, do we mmm I think the ones where, as a Korean right line, was no stage channel, but mmm is my chance we are I mean we're in iterating.

C

We just we are testing with that. We'll see how it goes, but we agree that we need a commonplace cross group to discussing that. In fact, the wall stage or section yeah.

G

But it should be a much quieter one that only contains that type of stuff yeah.

C

Okay, so probably easiest afternoon of tour tomorrow for me, so this will happen soon.

A

Ready all right so with me, one final request: backlog grooming- please everybody make this a priority this week, or please say on top of it: let's, let's continue to help ourselves. There are quite a number of items that are slated for 12-2 that have no weight associated with them. Let's, let's try to do. Let's try to make that a part of our weekly workflow.

A

That is my plea: um it'll, become something that will become more attentive to in the coming weeks so and with that, and with that request, I'll go ahead and close out this conversation. So thank you, everybody for your time and your attention and well may the force be with us always and we'll we'll talk again later this week, yeah.

H