https://platformengineering.org logo
Join Slack
Powered by
I’m gonna drop this one here - appreciate larger a...
# general
v
I’m gonna drop this one here - appreciate larger audience’s input as well! Very specific targeted question, feel free to ignore, but I’ll be selfish here. OSS-governance is a huge topic in regulated companies. Do you have any suggestions on off-the-shelf tooling to address license compliance, internal OSS proxy-repos, SBOM management, etc?
l
Will share @Vladimir Lazarenko, but don’t think they’re taking questions anymore i’m sure you’ll get some answers through the week
v
Yeah, heard that, the reason I posted here is for the rest to maybe share some intel 🙂
I posted it in Zoom Q&A as well, no need to relay, thank you Luca!
j
We use GitLab for this. Generally happy. Also used Snyk, especially for SBOM scanning
v
@Jon Skarpeteig GitLab also for 3rd party OSS license compliance? I.e. say, people are pulling deps for nodejs or maven - their repo gets configured to mybrillianinternalrepo.myorganisation.io instead of mavencentral, once they try to pull a new artifact - it gets auto-scanned for licenses and is either allowed, held for review or rejected.
Or am I wanting too much here? 😄
j
Yes, it scans the licenses from your SBOM
If you want to limit to pre-approved libs you can configure custom rules
It won't catch some random code copy pasted into you repo though
v
I see. Makes sense. We aren’t a GitLab shop, used to be, shifted to ADO/GitHub over the years, so trying to figure out something sane. Cause what we currently have isn’t deemed sane by anyone unfortunately
For some reason I got fixated on finding a “3rd party” tool, which locked my thinking out of exploring whether ADO/GH have something for SBOM scanning already. Thank you for knocking me off my tunnel vision.
k
When you say license compliance, what do you mean? Like only allowing certain OSS license types?
j
One example for us is AGPL library inside our SaaS product is a no go
v
@Keith yes sir. I.e. GPL is a no-go in a lot of regulated enterprises.
Most companies I’ve worked with have a license “matrix”, i.e. which licenses can be used in which domain (customer-facing, back-office, internal, etc).
Very few companies (none, actually) had a good way of managing that process in such a way that it didn’t become a PITA for development teams resulting either in ignorance or eternal suffering and stagnation.
k
I’m thinking you can do this with Jfrog as well
j
v
That shameless ad is one of the prime reasons I tuned in, in fact 🙂
Looking forward to it
Shameless spoiler ask? How much of it will be GitLab centric vs being tool-agnostic? 😛
j
Agnostic 🙂
k
So it does look like there are options if Gitlab will do something similar
j
Yeah, there's a lot of vendors in this space. But whichever vendor or approach you use, you'll need to do some leg work to triage the results. No silver bullet on that
v
Oh, 100% with you there. It’s getting the results in a transparent non-burdening fashion is what I’m after at this stage.
b
Regarding GitLab, there is an upcoming “Dependency Firewall” capability that sounds similar to what JFrog offers with their JFrog Curation GitLab: https://about.gitlab.com/blog/2024/03/26/coming-soon-gitlab-dependency-firewall/ JFrog Curation: https://jfrog.com/curation/ I’m looking into both options so don’t have any hands on experience with those features yet.
k
Can this be non-burdening? I can see some approaches being easier than others, but if a dev wants to use some library or framework or tool that’s not allowed, it’s going to burden them to change it, right?
v
Good point. Let me quantify what I mean by “burden”. Burden is having a process that forces a dev to manually submit libraries through a tedious scanning process, manually checking for its feedback. 🙂
k
I would think the ideal scenario is to notify them as early as possible when it’s not going to be allowed.
v
Changing a library due to a policy violation is a “necessary evil” type of burden 🙂
k
ha, fair enough
v
notify them as early as possible
Exactly. Also, making the process “inviting” to follow. Basically - don’t waste hours coding some super duper cool prototype only to find out 3 sleepless nights later that the framework you used will never see the light of day in this company.
But rather, scaffold a project, run it through scanning, get confidence that you’re sort of “good to go”, keep scanning as much as you can as you go.
k
I would encourage them to use an artifact repository with scanning and reporting capabilities even in their dev env
v
and we do, it’s just that the scanning and reporting capabilities of the repositories we use are lacking. or we didn’t find a switch to flip to enable it just yet
k
bubbling up the results in a way that works for them could be a challenge
b
Also if a list of pre approved libraries/frameworks were visible, that may steer devs to use something already vetted unless they want to risk a new one being rejected in approval process
v
Appreciate yall’s feedback!
b
Another session from PlatformCon that is relevant here:

https://youtu.be/KwCPJ265NVU?si=aJAZMNAykrnoxLwE▾

m
Snyk has some great tooling, I would also checkout Jit, they connect a lot of OSS tools together
Open in Slack
PreviousNext
Powered by