 I want to start this presentation with a story. It was 2016, and I developed my first Kubernetes application. And I mean, as I passed the last integration test and I committed the last piece of code and infrastructure to my repository, I was super excited. And my face was growing like the emoji that you see here on the screen. As I turned out to the office the next day, I found that my inbox was full of emails from our American ITOD department raising all sorts of concern about our application ability to meet all the internal and customer compliance needs. So well, my face turned from this to, well, that. And I mean, as the meeting with the internals took all the rest piled up, and the days turned into weeks, and well, the weeks turned into months, sadly my super cool new application never got deployed. I was working for the government. And while this story doesn't have an happy ending, I shortly realized that just like you cannot fit a square peg in a round old, you need a new approach if you actually want to use newer technology and decentralized infrastructure fit in a very old company. So while a lot have changed, I mean, in the past six years, adopting distributed infrastructure in regulated environments and regulated industry still leads to a certain sell story like mine. So I'm a similar Nagori. I am a security product manager here at Canonical. And today we are going to discuss how compliance programs should change to accommodate for the use of containers and containerized application. I want to clarify that I am a developer. I am not an auditor. But I wanted to take a step back and take a perspective of a key stakeholder in our industries that we never get to fill in their shoes. And basically, I wanted to know and discuss about potential changes that you should suggest to your compliance department or to the compliance auditor or your prospective clients to better pitch your new application idea or your new piece of infrastructure that you would like to purchase. So the agenda for today I want to begin by just explaining the what and why of compliance and why does it matter, especially in open source, progressing to what I think is like the broken promise of container. If you've been to past Cubicons, especially in 2008 and 2018, like it seemed that containers were the hottest thing that ever happened to compliance. But I mean, reality is a bit different. And finally, just sharing my ideas about how you should reframe that story in order to actually get it accepted and fit within the realm of your organization. So let's start with the key question. What is compliance? Simple one. In an interesting turn of events, I ended up joining the audit firm PWC in a certain stage of my career. And there, they actually gave me the audit handbook. And according to that, compliance is what you see on the screen. An important thing that I would like to note here is the fact that it doesn't mention anywhere like endless checklist and forms and endless list of things that you need to take on the paperwork. But it actually speaks about requirements, which are things that we should be familiar of because of our day-to-day job and our interaction with our internal stakeholders and clients. And why is it important? Well, I mean, since I joined Canonical, I got the opportunity to practice the answer to this question over and over again. And I think that the best one is basically this phrase that is provided by Simon Sinek in the Start With Why book. Compliance, we shouldn't see it as the factory of the know, but I think it's an essential piece of open source because of primarily three reasons. The first one is, I mean, we see as Canonical as part of our duty to our community and our stakeholders. But then I think it's an essential tool, especially for organization, to build and maintain the sort of trust with others and their parties. And finally, I mean, on a more practical terms, I think that those sorts of bounds and checks actually help us enhance consistency and reduce errors that we might potentially make as we develop our apps. I wanted to just do a little parenthesis over what actually compliance is. So as developers, we only see the kind of light blue box at the very bottom of this picture. But how do our organization actually get to that point? So first of all, I mean, every organization is subject right now to a wide set of regulatory requirements. Again, I've picked some of the famous security ones here in the US. But I'm sure that there are a lot of sector-specific ones if you're in banking, automotive, and so far and so forth. So for each one of those, the organization needs to create a set of policies, which are generally kind of like established by the corporate leadership. And they should represent the management intent for a certain topic, so cyber security, data protection, and basically everything that is necessary to support the organizational strategy and mission. Going one level down, there are the control objectives. I mean, as you can see in the picture, they kind of like relate to the individual controls of the framework. And they have this sort of many-to-one relationship. And they actually identify, let's say, the technical, the administrative, and physical protections that are tied to each one of the specific law regulations that are into each one of these frameworks. Within that, again, going one level below, I mean, we have the standards, which are organization-specific requirements that we should satisfy when we build our application. And again, while they are like relatively a level, the guidelines are the sort of like the guidance that we should follow, so the principles that we should adhere to when we're building our application. And finally, we get to the procedures, which are the real sort of like living documents into this big puzzle or like sort of like combination of Lego bricks, which establish the kind of like defined set of practices steps that need to be performed to actually implement all of the things that you see above. So while we actually only see that in our day-to-day job, it is important to recognize that they are part of a bigger, much more modular set of bounds and requirements. Now, into all this framework, I mean, wanted to emphasize that, like, why are we doing this? Why is this important? So processes and controls, the management cares, the processes and controls, they are documented, they are repeatable, and that we have evidence to support the fact that they have been successfully implemented. And I mean, this is an important point, because like container, because of their kind of like, their characteristics, they represent, ideally represent like a very key component for that in actually achieving that. So we are taking a modular framework. Container allows modularity, and so again, they should be theoretically a perfect match. I want to like, you know, the three main characteristics of container as it relates to the kind of like fitting inside the compliance framework. So the minimal part, if you think about it, like the more stuff you need to assess, the more difficult it becomes to do it accurately. And so on the one point, again, like containers are great for that. The declarative aspect is also important, because it kind of like, if you compare it to a VM, it's like relatively easy to see what's in there. So you can kind of like have compliance, in theory, compliance automation at scale. And then, you know, final on the projectability part, it kind of like should allow you to shift the kind of, the model from understanding, like not understanding how an application works to actually being able to model normal activity and basically kind of like ensure that your application is predictable from start to kill. I spoke about Q-Com, I attended a few of those and like I was like very interested to hear about, you know, the sort of like the security compliance talks that were in there. And there was, again, if you go back four years, there was a lot of excitement about that, primarily because of the kind of like, the element that you see at the bottom. So shared compliance ownership was the big value proposition here. And, you know, throughout the life cycle, you can have your obscene defined rules and you can have your, you know, Jenkins server enforces them. And that ideally kind of like, in theory, like would have allowed to remove all the hideous like human activities that are actually performed by, you know, all like army of people, like pressing, you know, buttons on the laptop as part of their day-to-day job. There were like, you know, two additional side benefits that were often quoted as it pertain to like vulnerability management because, you know, theoretically you could integrate vulnerability scanning right from, you know, start to finish, like in a very continuous way and not just rely on, I've deployed it in production, that's where it monitored. And there is no way for me to know anything, you know, when I'm actually developing the application. And then on the threat protection side, I mean, I spoke about that the paradigm shift, but it would have allowed for, you know, shifting to a widely spaced approach because you know how the application behaves. You could know in theory what normal looks like and then kind of like what, at least, everything based on that. But, you know, just like Antoine Lavois here theorized in 1789 with the law of conservation of mass, I mean, the same applies to technology. So if a problem is hard, like compliance, it means that there isn't a silver bullet to actually fix it. And so as it was the case for like in many other areas, you know, complexity, like it's never destroyed, it's just like shifted around. And if you look at, you know, current, especially like AV compliance programs day, there was a moment of reckoning and the rapid introduction of container alongside traditional legacy technologies. I think that it kind of like led to these three key problems. And I think that the most important one to recognize is the fact that the teams have to move from security and auditing the production environment to actually security and auditing the entire pipeline. And so you see that there was like a massive, actually increase in scope. Of course, like as many of you know, I mean, there is an element that auditors never really understand the technology, but I mean, I don't think that that's the key point. But the containers actually from delivering like a benefit into what are the areas where all the organization have the highest number of deficiencies like configuration management and threat protection, they actually ended up like making the problem, you know, even worse. So on the vulnerability management side, I'm sure you've heard in many talks this week that containers often use open source images that can contain vulnerabilities. That is a known fact. And it still happens to this day and like it's very hard problem to fix. There is a problem about, you know, network security and like user access controls where the fact that we have way more artifact and a way bigger surface, it makes it like a lot harder to track because suddenly everything is connected to everything. And so, you know, traditional activities are relatively hard to perform. And lastly, I want to mention about the element about like data protection, which is a byproduct of like all these three like points combined, whereby, you know, decentralization means that it's harder to get, you know, real time visibility and like insight over, or like even an audit trail about what is happening and where. So, how do control framework and policies kind of like need to change to accommodate containers? I mean, I wanted to present a couple of actionable items here and so that containers are not an obstacle to compliance but I mean, they can be, I'm not gonna say that they can be an asset but like if the challenges are understood, I mean, they can actually be an integral component and we can have actually auditors love them as well. But, I mean, I didn't really, so what are those practices? So, this comes back to the point that, you know, containerization doesn't automatically solve all of your compliance challenges but there are, you know, some concrete steps that need to be taken. The first point I want to discuss is the, you know, focusing on provenance. I mean, we've heard that in many, you know, talks this week like primarily in the space of supply change security but as it relates to compliance, if you make the parallel with VMs, in VMs you have a tighter control over your application. So, where do you get the binary is and, you know, usually they are not ephemeral. So, like the same workload like runs for a certain number of days or weeks or months and again, so the workloads are long lived. So, it is important to, I mean, to consider like source integrity and to make source integrity part of the compliance framework. In a sense that there are like a whole lot of controls that could actually be achieved by modifying the framework to actually make sure that we make that an integral part of our policies and procedures. So, the key facts of that, I mean, as you probably know, like we did the study in 2021 and like 96% of like our container images like contained non-variabilities and so the focusing on provenance part, it is a key element for security but it's also a key element for an effective compliance strategies. And if you, you know, just go one step below, I mean stuff that might not necessarily make it to the policies and procedures but we need to consider is, you know, making sure that we have like a declarative approach and so we actually put and track exactly what we have inside our containers and we scan it. We are a big fan of, you know, using minimal containers like whenever we can and so like only packaging what's needed to run. Sure, I mean, there is a lot like big initiatives about SBOM and we should be knowing what's in there but again, we all know the workloads are not static, they are dynamic and like over time the nature of an application like changes a lot. Another like element I'm gonna talk more about the later but I mean, having, I mean focusing on trusted projects or let me just say companies where like open source is actually funded and not relying on that one fork of the projects that we like that might solve the sort of like point in time problem but not necessarily have, you know, be as long lived as our, you know, workload, our oil and gas pipeline or our, you know, core banking infrastructure. And I mean, finally just having like some sort of like, and this is important for compliance just insisting that we have this sort of like centralized like repository that the trucks like everything like all the packages that we have that we need for our application. There will always be something that is outside but, you know, by just compiling an inventory and then like slowly adding that that can actually add that goes a long way in actually improving and like giving confidence to the auditor that we are not kind of like overstepping the boundaries there. So the second point is like making the supply. So the supply chain is like, as I said, like it's an important element and we can actually use that as an asset so that many of the controls that we need to meet especially as it relates to configuration management to the protection they actually point to an automated build process. This is important for the company in like kind of like two, for two reasons. As I said, it's not just about meeting the control it's actually being able to provide an audit trade for it. If we have a repeatable automated process it means that we ideally like also have logs and we also have a ton of evidence that we can show to our communities to our stakeholders to make sure that the controls are successfully implemented. And the second point is that from a configuration management perspective those are the sort of controls that have the highest rate of failure after access controls in like third party external audit of companies. And so we would potentially resolve one of the major headaches that internal audit teams or like financial teams or like your CFO actually has every year when it needs to like prepare like it's annual report or like renew its own the sort of like compliance certification for the company. I wanted to quickly show a simplified picture of how we do it in Canonical because we are the user zero of like everything that we kind of like put together. I'm sure you've seen like way more detailed picture than this one in the past couple of days but just to say that we do recognize and we own the fact that you know that the binary is the kind of like everything that we use comes from a variety of different sources. There isn't one single place where we actually take our software from but as long as we have a declarative approach and we actually clearly specify in our tool I mean Rockraft is the tool that we use internally kind of like what is in there and whether there is an S-bomb or whether you know we can actually ensure traceability. I think that we can like increase the assurance that we have over that. So the second point is about like thinking about downstream provenance. I've said it about before I mean and that does not only relate to our build system but also what our internal users and our community members actually use. While it is at least for us you know relatively impossible to keep track of everything because of the open nature of our projects. Again we try you know by using this tool by using automation to at least like put the gate and like restrict what we are doing there. And I mean and finally a key element to manage the fact that organization never lived with one single version of every given software but there is always gonna be legacy and there always gonna be the legacy legacy and the legacy legacy legacy. So it is important to actually have or at least like what we try to do we try to like build a very flexible release channel system so that you know we can kind of like account for the fact that you know we like we need to support system for like 10 plus years right. So like a lock can change and a lot of like different version can change within that and so at any given time we can kind of like replicate what I mean what we are doing and like a certain specific version of the tool. There will be you know further announcement about that. I mean like the wider ability about this tool but you know generally speaking this is kind of like the principle that we try to abide to as we develop our tools and our infrastructure. And the final point which was made I think like several points in this week is about I mean it is very hard for companies to actually staff a team that is able not only to understand but keep track of all of these dependencies and make sure that they actually fit within you know the different compliance framework and ensure that there is ability and make sure that this is maintained. So I think you know we are at a time where it's safe to shift left with sort of the activities to partner that actually not only do that but they like to do that and I think they are good at doing that. You know whether it is us whether it is like other partners I mean it doesn't really matter but like either way there are a lot of like folks out there and I see like a lot of open source companies that do realize the importance of compliance frameworks and are trying to make like an active effort to map all the controls that they are implemented and like either in their build process or in their products to all the major frameworks which might be relevant for your industry and for you know the country that you're living in. So you know again mapping certain controls to the NIST framework or like other ones which again are high level in nature but kind of like demanding the sort of explanation of how a certain configuration piece contributes to to actually meeting that control. I mean we have seen a lot of violin doing that we keep doing that with our long term container images whether it be for again regulated industry or the US government like with the Iron Bank it's an exercise that I mean we keep on doing both for us and for the peace of mind of the people that are our clients. So yeah I mean I hope you enjoyed the presentation. I think we have five minutes left on the clock so we'll open it up for question if anyone here from you know internet as a question about the presentation. All right please go ahead. So I think that there are two elements for that right. So the first is there is a talent element to you know the shifting left part and like why it is essential. It is difficult to find people you know whether it is you know security or whether it is even compliance professionals. You know if any of you has like ever like tried to recruit for that I mean you will know like how painful it is. But then there is another element that it's not just about finding the people but like once even once you have the people how can you do that at scale. You know just like you know Suze or like us in this case we are the owner of a specific part of the infrastructure and like we have the knowledge we have the intrinsic knowledge of like how it works and we should have the knowledge of the difference compliance frameworks because it's not just about doing the right thing and like standing by it but it's like doing the right thing in relation to what other people believe is the right thing. And so that's how we like we try and do it. I mean we try and like offer the sort of you know like mapping for you to consume and so that you know the burden is just making sure that what we are saying is right and then eventually just taking that you know access spreadsheet or whatever it is and like you know importing it into your control framework. Okay all right well thanks a lot and have a great rest of your Friday.