Joe Biden’s Security Order: What it Means for DevOps

With the recent reveal of the White House’s Executive Order on cybersecurity, many developers and DevOps shops are wondering what it means for them today – and in the future. Prompted by the SolarWinds hack and other security events, the US is equating cybersecurity with national security and making bold changes to software requirements. Join DevSecOps experts in this webinar to gain insight into the order, anticipated consequences, and how a US Government focus on cybersecurity will change the global software industry.

The agenda: 

  • What the Executive Order says today
  • Anticipated further actions by the White House
  • Reasons the software bill of materials (SBOM) will become the source of truth
  • Differences between a SBOM and an “ingredients list”
  • How tools and methods will position developers for success
  • How securing and certifying processes – not just components – may be the key to future compliance

More resources: 

Video Transcription:

Hey there, how are you doing? I’m Bill Manning and I’m one of the solution architects here at JFrog. You can follow me on twitter obviously right there as William Manning and I’m here today to talk to you about the Biden administration’s executive order on improving the nation’s cyber-security. Now I’m going to give a quick word of caution on this talk: this is a generalized talk it’s really not a product pitch, there are you know there can be times where I am going to be talking about the products because I do work for JFrog but also at the same time I’m really here to kind of describe and go into detail on why it’s important to understand what this executive order means.

We’re going to discuss things around security because it’s not only important to have all the information, what’s best for you, but also it’s a way for you to go in and not only protect your company and to adhere to the guideline in addition to that but also to make sure that you know you can have the information so if something does go wrong or you do find a potential threat, it can help you and your customers or even people like personal users who might use your product. Because let’s face it – nobody wants to see the headline of a million user accounts that have been compromised or a breach has been discovered.  And while hacking is really nothing new, understanding how the software gets made is actually one way to prevent those headlines from happening and not only saving your company from unneeded expenditures for remediation but also affects your company’s reputation. Because let’s face it, no company wants to be part of that, the exploited headlining that suddenly xyz company breach has been found. So to start off what was the catalyst behind this executive mandate well there were of course like I said many hacks and many different things over time that you know really were kind of you know driving this forward over time I mean the initial talks behind this started actually in 2018 and we’ll talk a little bit about that earlier later on in the discussion, but really it was really just as a response to Solarwinds. I mean let’s face it, solarwinds was a headline that was huge in this nature, it affected over eighteen thousand customers in the spring of 2020, and over time people have estimated that it’s going to be hundreds of billions of dollars to go ahead and remediate this from all these various companies that actually had this as part of it but the thing is though is it’s more importantly is is that when you look at the way solar ones happened um it really it was really the push that everything needed to come about with this. Because if you understand the way the hack happened then you understand why the build of materials is so important. So, if we were to go ahead and look at this we got to look at it in terms of how the software is being built and utilized and how it actually affected their customers. So what the Solarwinds hack had software developers who are doing their thing, you know they’re doing their code and all their code depends on third-party transit of dependencies to build that software, and we’re to talk a lot more about that, and then when they compile their code and they get ready to ship it off what happens if something is inside right? What happens if one of those transitive dependencies is inside. In this case what it was is there’s a platform called Orion software, so the Orion software platform had a plug-in called Solarwinds Orioncore Businesslayer DLL. It was a very common library that were used amongst the entire software suite of the actual um you know Orion product, and they dumped its sunburst because actually one of the things that was very interesting about this hack was is that this library itself actually laid dormant for 14 days and then opened up a back door which actually opened up exploits for things like transferring files, executing profile information, rebooting machines, disabling security services. And what happened was that when this actual library was actually infected into the system of course it made it into the executable and thus it was actually then transferred to their customers. Now the thing is that the customers that were actually affected by this were actually affected by two offer updates and there were a lot of those – 18000 customers out there that were affected by this. In terms of the United States government the department of homeland security was affected, treasury department, defense department, commerce-state energy, and even the nuclear security administration. Now think about that this security exploit that actually has all these things I just described in it was actually released to the world. When they were released they said you know it took a while to find out it was very deep inside…


It was a time to take action on this and try to figure out a way so we understand all the software that we’re actually purchasing because this mandate is actually enabled so that if you do go to work with the US government you are going to need to supply this information to them and if you’ve learned anything over time of dealing with software you know that besides the fact that this is to work with the government, this has actually bled over into the private sector like regulated industries such as Fintech or Medtech or Aeronautics. Having this information is not only beneficial in terms of using the government but also to your customers. So of course we know that all the software that we have you know depends on other software right you know free it’s open source software you know the idea of the big joke is it’s you know free as in speech and not in beer is really one of the things that most of the software you use depends on. Even here you can see where I have a screenshot and here we go a little prodigy time I’m actually using our JFrog Xray plug-in with the IDE and it’s discovering all the third-party transit dependencies that I’m using have some sort of exploit around it and it’s my job as a software developer to go in and remediate these potential threats. Understanding the threats and remediation can save you money in the long term but the thing is that part of that is also understanding the dependency graph on how things are done and why am I talking about this part right here? Because there’s some really important information on this that is even more scary in a lot of ways than you possibly even expect. Because we take all this free and open source software for granted, right? It’s just the nature of things. I mean if you look at software best practices it’s all about software reuse, and part of that software reuse is using other people’s components, using free and open source software. And there’s some statistics that I found as I was researching, getting ready for this talk, that really made things more apparent to me. The fact that 85 to 95 percent of most software is an open source software code base that is used in your application, that alone when we talk to customers about… Like even myself personally, why do I need a solution like say JFrog artifactory for this exact reason! To provide consistency, because of all those transit dependencies because what you produce is only a small subset of actually what’s included with that software. Another thing is that 99% of the code base, right, you know, in there 75 percent of them have at least one open-source vulnerability. Think about that software you’re using to create your software to make money and revenue to give to your customers, actually is inherently flawed and understanding that really allows you to go in and take action. You want to be the best company you can be and the thing is that your software, as a software vendor, your consumers whether it’s in a b2b or a b2c capacity, they accept that level of quality. Another thing is 49% of code based analysis have some sort of high risk vulnerability. You’re exposing your customers potential threats, not only personal but monetary. Think about how many times you’ve gotten that email that says your information has been compromised or if you’re even more so a regulated industry not only your personal records have been compromised, or you might be part of an attack and then the other worst part about this is that 99% of those open source component, 90% oh sorry, of those open source components you use to build your application are out of date by four years or more and a lot of them are abandoned, meaning that you’re using code that’s basically zombie. You’re basically using stuff out there that has some sort of relation that you want to use, it’s never been updated but you’re still using it anyway. Remember dependencies have dependencies so the dependencies you count on have dependencies that they depend on and thus what it comes down to is you have things like atomic components which are single entity classes all the way down to more complex code that is made up of multiple sources. Understanding these sources really helps you understand how you’re doing things and what kind of potential threats you are giving to your customers’ code. You know to your customers themselves and then lastly 74 percent of the applications have vulnerable libraries that can be fixed just by updating the libraries. That alone is amazing. When you look at a library and you find a threat and you see something like we actually produce this information we have this displayed in our product that says hey by the way this issue you’re looking at could be resolved if you move to this version that’s a quick fix, something that actually could benefit you in the long term. The reason why I bring up all this information is because this was the call to action that really pushed things forward. It has much deeper seated roots than you know so today we’re actually going to concentrate on one section of this document. It is a vast document, there is a lot of information on there, but the part we’re going to concentrate on today is enhancing the software supply chain and more specifically the software bill of materials. It says whether it’s either by product directly published on the website or whatever you have to do you have to produce a software bill of materials and the software bill materials will, like I said, allow you to work with the government. If you’ve ever been a startup and you’ve actually had that possibly of being acquired – I’ve done this before I did this over 10 years ago when we were going through a possible acquisition I had to go through our software code base. Actually a friend of mine and I had to go through it. We worked together and we had to find all the open source info software we were using to create our software. So even back then, I mean we’re talking 12 plus years ago, this was a thing that you needed to do. If you’re a corporation and you want to instill some confidence into the customers that you’re working with this, it is a way to say “here’s the components we’re using” and if they do research into them they can see that the software we’re using does not contain this kind of level threats and vulnerabilities. Now this sounds very familiar because it is! Actually it’s funny, this has been part of the food and drug administration for decades – understanding what goes into the products you put, what you actually consume. I mentioned in the preface to this, when I sent the teaser, that I was going to talk about cake and I was not wrong because I am going to talk about cake right now because the thing is that you might look here, you know, the FDA actually for a long time has had the list of ingredients. Why was this enabled? Well this was enabled to understand not just what went into it, you know from let’s say a dietary perspective, but also as a protection. The thing is that what if you have a nut allergy, what if you’re lactose intolerant, what if you have celiac disease? These warnings, those ingredients, let you know that there’s a potential threat to your personal being inside. The funnier thing about this is the fact that when we talk about this mandate was actually starting to be constructed back in 2018 by the food and drug administration, not in terms of the software but in terms of medical devices. So this is all the way going back to 2013, and even before that, but in 2018 the FDA said “hey by the way we do this with food ingredients we also need to do this with medical devices” so any software that goes into a medical device needs to have a software bill of materials so that you know what went into it and it’s safe and secure so if this exploit is found you know… Now I mentioned cake right? Well here we go: here’s a cake, it’s delicious, it’s got stuff on it, it looks like I’m actually hungry. I probably shouldn’t have eaten before this but the thing is now when you look at it you understand that all this stuff went into it right? Eggs and flour and things like that, and understanding that allow you to make better decisions on whether or not you should consume this.

Trusted Releases Built For Speed