For initial import I like it to be a manual process so I can judge risk. I have some really bad python scripts that read/write excel documents that will alert me when licenses change.
My plan is to move to Black Duck or the commercial libraries.io subscription for my automation needs.
For Kubernetes I'm really impressed with Aqua Security as they do OSS license adherence and OSS security vuln alerting if you only deploy into containers. It's not a cheap product, but love how they do OSS assurance as part of build and deployment. It's a nice model that allows a central security team to use technology to enforce policies - good for "research" environments where dev/researchers don't want to do any effort for OSS packages.
There are commercial products/services out that that attempt to provide validated OSS packages and monitor when the ones you are using have vulnerabilities.
In the data science world, there is anaconda, For the enterprise, there is black duck software, myget, libraries.io and the commerical variant, and a few others.
My internal checklist:
1) Is the license OSI approved (IP indemnification and IP taint is a risk)
2) What's the community like for it (is it well used, do security incidents get tracked handled quickly)
3) What security assurance have they done (some OSS has funders who have paid for testing, what kind of test suites do they have).
4) Add security alerts for the OSS to my RSS feeds to help monitor
5) Enforce a policy to sync to upstream pretty frequently as many OSS security bugs get silently fixed
If I don't have confidence at this point, I will have some static analysis performed (lots of tools here) as a last measure sanity check. I know lots of bugs won't be uncovered by that, but it's an indicator of development goodness.
Would love to hear what others are doing as we are a small shop and use 1000+ OSS packages.
Don't have experience with hangout and zoom - but other systems that I've used setting the individual mic sensitivity was needed to fix audio issues like that.
I ran it too - could never afford MajorBBS or the successors and it was easy to scale from 1-24 nodes. I even ran the weird BBS/ISP hybrid WINS Server but wasn't good enough to be considered a real ISP.
IBM terminology might be confusing me - but looking at published security targets it appears LPAR's themselves have only ever been evaluated at EAL4 with flaw remediation (ALC 2) and PR/SM being evaluated at EAL 5 but neither to any specific protection profile. This means that IBM created their own evaluations and gave themselves a "certification".
Protection profile less CC evaluations are worthless in the eyes of most governments and CC schemes, but kudos to IBM product management and marketing for creating competitive FUD.
As of a year ago LDOM's (Oracle VM for SPARC) hasn't had a CC evaluation and I'm not seeing anything currently in evaluation. Solaris Zones have been evaluated under the Solaris OSPP EAL4 + extensions evaluation.
The biggest reason that virtualization technologies haven't had a CC evaluation with a protection profile is that no US NIAP approved protection profile existed and the draft ones that were circulated were crap.
Assurance levels (EAL) are deprecated for newest NIAP protection profiles as the higher assurance levels (EAL4) were cost and time prohibited for vendors to complete before the product was outdated. Many people wrongly think common criteria is a security evaluation (free of bugs) - it's not - it's a security architecture evaluation (is the documented behavior working correctly).
There is a schism in CC - everything is changing - anything we know today is wrong and will change.
TL;DR: Common Criteria is a joke and doesn't actual mean what you think it does.