 Welcome to my session. In my session, I'll talk about how to build a secure, efficient, complex, full supply chain at scale. Please enjoy my session. First, I'll introduce myself a little bit. My name is Tang Dong Yi. You can call me Jerry. I'm a program manager of Baidu Open Source Program Office. I have worked in the open source community for over 20 years. I'm a commuter of Mozilla Glow and Apache Foundation. I'm an advocate of open source in China, and also one of the founders of Open Chain China Working Group. Here's my agenda. First, I'll talk about what is full supply chain? Any risks for it and a challenge for my company? Then I'll talk about solutions for it and my practice. Next, I will summarize. First, what is full supply chain? Full supply chain means the operation of consuming false effort free open software within a company when running daily businesses. The challenging is just like any supply chain within a company. How do I trust my own open source supply chain? Is it safe to use a risk alone? Is it efficient? Of course I know. Why? Because today, people don't like software false cross. Instead, they assemble them. Here's one picture from Lin's Foundation. It says that in today's modern software, we use 90% of code in open source code. Here's one example. Engineers start an open source framework, then write its customers' code, then combine it with open source library to solve the real-world problems. You can see that the customer code is only 10%. The 90% are open source code, so it's very, very important for companies. False is free to use, and it has also risks. It may have security code, it may have bath, cold arms, hands, memory links. It may also have complex issues, GPL-related and patents-related. Here are some cases. The first case is a very famous case, security holes cause business losses. You may heard it before. The input fares bridge and online appartments cause more than $400 million and affect 140 million people. It's crazy. And here are two cases caused by software biotics, cause business is outages. It's really cases in my company. Case one. One online tech service broken due to a CPU humpback when using an old version of FastJSON, which costs $500,000 RMB revenues. FastJSON is an open source library very popular in China. It's a Java library to pass JSON data. Here is another case. One advertisement service failed due to one normal box into a keeper software, losing 7 million RMB revenues. And some cases about complex issues, such as GPL violations and the pattern terms. I'm not an expert on legal. So you can Google, Nix says WRT, file 4G and reacted pattern issues on Google. You can get more information there. So the whole picture of first supply chain management. Here is inside the company. We collaborate on a code. But we inbound free open software ABC from our stream. And then outbound we release it to our customer. We can release to as an online service and then release as a software and then released with hardware. The status in my company previously are not good. It's not very complex because nobody care about IP issues when importing OSS code and releasing their own. It's not very secure. Many usage of open source software with no high-risk CVE box. The fixing process is quite slow and not guaranteed and it's not very efficient. The huge duplicates open source code in our internal code measurements system. And updating process is quite painful. Here's one case. When a hand bath founded in first season 1.2.51 caused revenue loss in one product we want to avoid other similar problems also. What do we do? We notified with emails and pushed all in here to check by themselves and fix them by hand. But after three months the status was still unknown. My manager told me that no one was assigned to work on this issue. Why? Because this method was not efficient and did not work well. If we were forced to fix it by hand there's a huge work and it's not going to scale at all. So the real problem for open source for supply chain measurement is to how to build a secure efficient complex for supply chain and scale. Thanks for OpenChain project. It provides us a great framework. OpenChain is a standard to describe what organization could and should do to address the first complex in fashion. It identified key recommended process and required keeping requirements for effective force measurement. And it's not only complex you can check out openchainproject.org for more information. It defines the whole process. We need training, we need policy and we need process. It boils idea from Damien. This picture is from Derek Wicks on OSCOM 2017. It says that from Damien's idea supply chain need to use fewer and better component suppliers. Use only the highest quality components part and continuously track when and where components are used. So, as the idea practice encloses when you found open source software engineers ensure to use high quality ones and limited ones from trusted suppliers. Keep a record when consuming them. Know the lessons and pattern invitation of them before using it. And when outbound engineers ensure to keep a software bone when releasing. Fulfill the IP obligation of this force. Update periodically when being notified by security, SIE and legal teams. Talk achieved. But how to implement? There are many challenges. The real challenges for my company is that they are massive force supply and demand around the world and there are so many engineers and reports in my company. The engineers' habits are bad and we lack resources. The first challenge they are massive force supply and demand according to the report of THONATAC, there are 3.7 million unique packages in Central Madden repository. The download is increased dramatically and for JavaScript, there are 800 key unique packages in Central NPM repository. The download rate is increased even bigger. So on average developers have access to more than 21,000 new open source software components released every day since 2018. The second challenge is that there are so many engineers and reports inside my company. My company has over 15k engineers that are working on over 100k reports every day and the 3 million commits last year and 400 million code changes last year. Here is the third challenge. The engineers' bad developing habits. The engineers are not aware of force release so we choose whatever code they like to use. The engineers are not willing to update force software version if they have already finished integrating. And some engineers like to commit force resource code into their product report together with their own codes and when lack of resources the tool engineer resources legal resources and security engineer resources are all very limited. How to handle? So the only solution is automation. I have to use tools automatically as much as possible and I need to teamwork with legal security tools teams and we might need to be angel this region with small step set priorities and focuses on the highest one. So what I do? I set up a logic team including guys from legal security and tools and line up our goals and priorities we set up our action plan interstate steps for the last three years. Here is our action plan three steps for the last three years. First, record OSS usage automatically to locate and fix high risks quickly. Second, generate software for some core product team the last one is to complete the whole chain measurement and get open chain certificate to approve that we have done it very well. And the first step is focus on here in the right circle. Release is online service is our highest priority. The task list for our first step is that we set up an internal Maven server and NPM server first force engineer to use them and then all convince in the report if contents OSS code source code we define policy we use training and we enhance tools then we index every report and says prominent.srml or package.json.files to build force dependency data with a survey bar founded located this effective reports send security tickets to push engineer to fix them ASAP Why we choose this? Because Baidu is an internet company most of our business is online service and the risk of lessons complex is low we cannot leave without open source now we can bear one case of OSS fault but we cannot tolerate duplicate cases of OSS fault and slow phasing process we select jar and jar script first because they are more popular in Baidu Actual policies we define measures metrics cleaning metrics data before action then we allow the open source policy and train all our engineers we plan to developing scenarios for new created codes and for existing old codes training is very really important we must indicate our engineers to do sense correctly so we organize several offline training in several sites Beijing office, Shanghai office and Shenzhen office to tell our engineers how to use open source software then we provide online video training for every engineer then we accepted online design with video training for every engineer so every engineer is required to finish the video training and then pass the online design and for new created code we allow the policy company wide AGPR-LSS code are not permitted to check in some high secretive OSS code are not permitted, next just two we also end screen in code submit hook if the patch is AGPR or related with OSS risk OSS commit will be failed if the patch contains OSS source code commit will be failed too in this way we can make sure that no new OSS code will be ended into the code reportory illegally then we index every reports and collecting data we indexed POM.SML or GRANDER.SML for JAR program we indexed patch.json.log for JAR's greater projects then we build a dependency map and a policy then is API after each we can setup our open-source software security ticket system we set security fixing process and allow it then we get affected report data how many reports and who are the owners from the API we get already when assembly bus reported we can file service ticket to report owner to push them to fix it here is one case scale fast json we need to update fast json to version 1.2.66 to avoid a newly founded high-risk bus then we identify that over 300 reports are affected then we send out 300 more security tickets to these owners to push them to fix it in one week we check with the tickets and check with the reports status all are clear and are verified that's great it's only the first step we need to move on with more language support Go, PHP, cnc plapas we need to scan every report to force it near to migrate we use main and npm instead if they haven't used it before but building fast supply chain fast supply chain is a long journey it's more than complex it should be integrated with every activity of daily work for engineers and project managers we will keep going to make it more secure more efficient and more complex last, I recommend we can take a look to work with open chain it's a standard it's a collection of best practices in the industry it's also a community many engineers, lawyers and program managers are working together to share their practices please check out openchainproject.org for more information okay, that's all any questions? sex