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.
As a former product manager from one of the vaulted companies we had tons of video around business benefits and use cases, but very little on the implementation part. Look for the curated video channels for the big vendor players.
Bryan is a smart funny guy, but he's an opinionated asshole that represents everything wrong with silicon valley engineer "rockstar" culture.
I didn't rewatch the video, but have seen it and met him dozens of times back in the OpenSolaris then Joyent days. He seems to simplify things to portray cause and effect that do not exist due to the complexity of real life.
I trust his ability to engineer a brilliant product, but I don't trust his ability to create a lovable product - it's all about the engineering goodness to him, and not solving the real world problems. Joyent's financials and yearly change of directions will probably back that up...
Oracle is Oracle - there are good things and bad things about a process driven company with 2000 products, but understand there is massive bias in Bryan's video - he didn't get his way and he wants people to know it.
With only a quick glance at the checks/code, this will suggest stupid things on Solaris. Solaris 11 has configuration compliance checker that is far more complete (and uses the correct interfaces) than this.
On solaris 11.2+ man compliance, and follow one set of the vendor recommendations (normal, high assurance, pci-dss).
The SCAP ecosystem exists, I see no need in this day and age to use shell scripts for configuration parsing.