For the past two days I've been back and forth between the OSBC event and the office. I've been particularly interested in the sessions on governance and legal challenges related to open source adoption. What's fascinating about these talks isn't so much what's in the content, but what's missing. There is a lot of talk, still, about open source licensing issues but very few lawyers made the connection between due diligence in security and legal issues for the organization. Possibly this is because there is not yet a wealth of case law pitting customers against their vendors for failing to ensure the security of the application. Bugs are one thing, and their acceptable existence after a lengthy QA process is also open to debate. Unpatched security flaws that enable the theft of hundreds of thousands of patient records is quite another. But I digress...
Sitting in a roomful of lawyers discussing open source license complexities can be a heady experience. I'll be the first to admit that I do not know what constitutes a derivative work. Thank god for the legal team in that instance!
I rather enjoyed Lawrence Rosen's session "Getting Open Source through Legal" and was intrigued by his characterization of open source risks as, "really small". He also mentioned that lawsuits [related to open source licenses] aren't that big of a deal and went on to ask, how many open source settlements do we hear about really?
He was a lovely speaker by the way, but his talk was (self-admittedly) tinged by his own personal beliefs and his involvement with the Apache Software Foundation. He downplayed the necessity of database code audits, but at the same time he had a slide in which he called out "Trust but Verify" as part of the due diligence process. When I asked directly how one would "verify" using manual means, he clarified that companies should "verify only if you're uncomfortable or if you're passing it along to your customers". I was left wondering how one clarifies the word "uncomfortable". It seemed that Larry's reticence in mentioning code scanning as a part of best business practices is more about his genuine belief in the "goodness" of open source than his fear of audits.
During the Q&A portion, indemnification was a big topic. Someone said he had lost a sale because he couldn't promise there was no open source in his company's applications. In my mind, this was a perfect example of a company that lost a sale because they couldn't provide a very basic bill of materials on their code base contents - something we do for companies each day. Instead of recommending this sort of saving grace service to this gentleman, Lawrence asked why anyone would want indemnification. I didn't see how that helped the gentleman to secure further business deals but then again, I'm not a lawyer.
On Day Two I caught Heather Meeker's session, "Jumping into the Pool: A Legal Guide to Engineering Your Open Source Code Release", which was a very in-depth primer on the complexities of licensing issues and remediation. What I loved about Heather's talk was a section she titled, "Commando Due Diligence", in which she talks about the challenges of trying to find out which software assets a company has without using code scanning. However, when she touched on M&A, she did say, "You must have someone go in and independently vet the target code and objectively look at it." She was discussing creative ways in which lawyers might apply common sense to find out if they were actually missing important software disclosures, but in my mind, this is assuming that the legal team has as deep of a technical aptitude as Heather has (which is deep) and it's also assuming that they apply "common sense" in the same ways in which she means them to, i.e., if your engineering team discloses that they are using an API for browsing, would they know to ask after browser software if it weren't listed?
I asked her how legal could be sure they found everything and was happy that she said, "Without code scanning it is extremely difficult to tell if software was left out of disclosure. Code scanning is going to find things that manual audits can not." Heather Meeker is sharp. If I were in any doubt about my open source use and needed legal representation, I'd call her.
I also attended the panel, "Open Source Governance: Recognizing & Dealing with the Unique Risks Associated with Free Software." The session really covered a lot of ground but in a very fortuitous instant, the moderator, Sara Harrington gave the best sound byte of the day when she said, "In the same way that people are waking up to open source software, they're waking up to security." Right on point with where Palamida is in bridging the gap between security and legal.
In our minds, security is a legal issue just as much as IP is a legal issue. If you didn't do your due diligence in producing secure code and you sell it to a customer whose database is breached, can they sue you? Can they slander you? Can your reputation be ruined? It's something the legal team should be talking about with the security guys down the hall.
Virginia Badenhope openly discussed the need for a line of communication between the engineering teams and legal. She outlined the need for what we always call the "Golden Vault" of vetted and approved open source projects from which developers could draw. All admitted that the closer one gets to go to market day, the less that sw development will do in line with outlined policies. Not because they're malicious, but because they've got a product to get out.
Further in the panel discussion we got on the topic of just how much is missed without some sort of automated audit solution. I was able to leverage last year's impressive code audit data (we looked at over 500 million lines of code) to illustrate that in different situation we've seen anywhere from 1/3 to 100% undocumented code. Therefore, it is unable to be patched, made compliant, etc. This stat is sobering.
What I found the most exciting was that after the session, I spoke with quite a few people from different fields, trading white paper info and statistical data and gathering business cards to share thoughts down the road. This is what makes events like OSBC so worthwhile to me. The opportunity to shed some light on the corners of OSS management that people may not be aware of or even know how to approach. By making OSS management part of an overall application security process it makes open source so much more valuable and easy to adopt, understand and utilize. People sharing information is good. People sharing knowledge is better.
--Melisa LaBancz-Bleasdale
