Home
Contribute Contact Us Browse all meetings
Home Contribute Contact Us Browse all meetings
GitLab / Secure Stage / 12 Mar 2020
GitLab / Secure Stage / 12 Mar 2020
Previous Meeting Next Meeting
⏯
Add meeting Rate page Subscribe
youtube image
►
From YouTube: Secure UX iteration review: license compliance, displaying policy violations

Description

00:00 - 03:20 context, current UX, and problem to solve
03:20 - 04:42 latest iteration solution overview
04:42 - 06:08 issue feedback, next steps, and conclusion

Issue (license compliance): https://gitlab.com/gitlab-org/gitlab/-/issues/33870
Related issue (dependency list UI polish): https://gitlab.com/gitlab-org/gitlab/-/issues/195928

A

Hi I'm kyle from the secure UX team today I want to review our latest iteration from our efforts in license compliant at the project level. First, let me just jump into a little bit of context about where we're currently at so our most recent iterations that we we just shipped if you come to the project level and you come to the security and compliance tab and then license compliance well, now see the results of the license scanning the license scanner.

A

In terms of now we're looking at the actual licenses detected in the project from those additionally, a maintainer will be able to add policies whether denied or allowed licenses directly from this UI in this section now this was previously migrated from the settings cid CD section and one of the upsides is- is that these are now together and the other upside is that developers can also come to the screen and see what policies have been added to this project, whereas previously it wasn't visible.

A

So now, there's further awareness to all developers on a project about what policies are created. The problem that we're solving is we don't know, though. It's we're not communicating yet, when licenses are detected in projects that are possibly out of compliance, so we're only showing policies and then detected in project and not, for example, if this bsd license was deemed denied in the project. There wouldn't be any awareness about that now in the merge request, we do show this for only newly detected licenses.

A

So if I configured license scanning yesterday and then I made some commits with with two new licenses that we see here and let's say that I deemed new BSD a denied license if I, if we make gave it that classification, it would show up here now it's just taking a second to look at this. It's not clear what is exactly being communicated here. There is also a site, a separate issue.

A

That's looking to clean this up to clarify what these policies mean: we're using headers here to clearly state that these are denied, and not just relying on icons to do that communication and also, additionally, having tooltips to explain what exactly these results mean.

A

Okay, so going back to this, if you click this as a maintainer I'll, be able to allow or deny it directly from here, but if it was a developer, it would just be this modal, this information modal, if, when available, so this goes back to the problem at the general project level, we want to count for also licenses that are existing in the project, not just newly detected and match them with policies to make sure that they're, an ER or, if they're out of policy, for example, with our classification being denied okay.

A

So that's what this issue is looking at and the latest iteration that's ready for development will be this. The user will land on the license compliance page and this banner will communicate to them. That detected licenses licenses have been detected that are out of compliance with the project's assigned policies. This is to help explain, what's happening on this page and visually coordinated with the labeling here, which is policy violation denied the sorting of the detected licenses is alphabetical.

A

However, if it's, if there's a policy violation in this case with denied those will be surfaced to the top. No, there is a column here. It won't be visible, we'll hide that, but there could down the road it could offer us. A placement for additional classifications, as those are added for now right now denied is, is the only one that would be deemed out of compliance, but there could be other cases of similar matches. For example, you know an approval pending and other classifications that may come, but for now we're surfacing them.

A

This way wanted us take a look at some other considerations that we had during the design process and some feedback that we had. One thing we want to start taking a closer look at is the actual like audit log. So where did these license come from, for example, when did they happen? Who introduced them? What was the merge request that they came in? That's that's what this issue is looking at. How can we better communicate that so when they land on this page?

A

So when the user lands here they have more tools to start jumping into removing and removing these out of compliance licenses. They do have the component and then they can start seeing the dependencies that are affiliated with it. But it would also help to have an understanding of where and when it came from.

A

And just see, if there's anything else here, yeah, that's pretty much it. The other aspect that we're we're coordinating is some visual alignment with the dependency list of how vulnerabilities are displayed. There's a separate issue for that I will link it in the description but anyway. That concludes our latest iteration review here. Please drop us a note in in the issue. If there's any thoughts that you have things that we should be thinking about or or anything, yeah thanks for watching.