Suggestions
Gil Yehuda
Open source governance and technology leader
Gil Yehuda is an exceptional professional with expertise in open source governance, licensing, and risk mitigation. He has a strong background in collaboration, community building, and cultural initiatives. With a technical product management focus, he excels in IT strategy and governance. Gil also has experience in corporate and educational event organization, along with leadership roles in non-profit boards and foundations.
He completed his Bachelor of Science in Artificial Intelligence, earning a Scholars degree with honors cum laude from Case Western Reserve University.
Throughout his career, Gil Yehuda has held key positions in reputable organizations, such as U.S. Bank where he served as the Head of Open Source Engineering and Technology. Previously, he was the President at Yahoo Employee Foundation, Senior Director of Technology Products at Verizon Media, and Head of Developer Services Program at Verizon Media. His professional journey includes roles as an Industry Analyst and Web Strategist, Senior Analyst, and Director of Technology Innovation at Fidelity Investments, where he also held positions as Director of Enterprise Architecture and Senior Developer/Product Manager.
Highlights
I'm beginning to review the new #FFIEC guidelines that tell banks how to run their technology operations. Their understanding of #opensource was minted in 2004 (the era before git, the cloud, and mobile apps). It was limited and problematic. For example, they confused open source with shareware, ironically the opposite of open source. But they just released a major update. Will the new guide be accurate and helpful? I'm starting to read. I'm concerned.
It starts with a classic misinterpretation of facts: "Open-source vulnerabilities may be more common [...] because the overall review process for open-source is less transparent and more difficult to validate." Ironically, open source is more transparent and easier to validate. Yet that's why the vulnerabilities are more common. Security researchers can find them in open source code more easily than in closed source code.
I'm unsure how familiar the authors are with software development, but they wrote: "If the original developer makes updates, they may not be pushed to the entity." But when would open source code be pushed to the entity? The entity should pull code updates as part of its CI/CD process. They continue "In that case, effective management would request updates from the original open-source developer to address vulnerabilities and manually deploy updates" Open source developers will laugh at the request from a non-paying bank. Sorry, but this is not "effective management" it's a misplacement of responsibility.
I hoped they'd get the legal stuff right. But no. I'll invite you to find mistakes here: https://lnkd.in/eNJ8Tff2
Sadly, banks in the US must consider this content in their policies and processes. This means banks must satisfy the examination while also doing the right thing. I'm concerned with the parts I've read so far. I have much more to read. Perhaps the rest of the guide is better.
SBOMs tell you what is in your software. There's a formal definition of SBOM that many people use. But I ran into a group that creates something they call "SBOM" but it was something else. I don't know what to call that other thing. Let me explain what I know and ask for your help as I learn more about SaaSBOMs, OBOMs, or other BOM-like lists that describe cloud services that accompany a deployed cloud application. Also, we'll talk about breakfast cereal.
