Tag: compliance-as-code

  • Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    As DevOps has matured and more organizations have adopted an infrastructure as code methodology, alongside an increased importance of security, we are seeing compliance as code and policy as code being adopted by many organizations. Progress Software’s Chef products are helping lead this trend. The video is below followed by a transcript of the conversation.

    Alan: Hey, everyone. Thanks for joining us on another TechStrong TV interview. I’m really happy to have – well, it’s the first time I’ve interviewed him here on TechStrong TV, but Charlene has had the pleasure of having Prashanth on before. Let me introduce you and I’m gonna do my best on his name, I apologize. Prashanth Nanjundappa. Is that close, Prashanth?

    Prashanth: Yes. Prashanth Nanjundappa. That’s close. 

    Alan: All right. Prashanth is with Progress Software, where he’s a VP of product, isn’t it? 

    Prashanth: That’s correct. 

    Alan: And we’re going to talk a little bit about today, we’re gonna talk a little bit about, you know, compliance’s code, you know, in this shift left kind of mode, but also the whole maturation of the DevOps space, etcetera. But you know what, Prashanth, as we spoke about off camera, this is your story to tell. Right? This is your kind of thing. Let’s, you know, talk about things that are important to you. Why don’t we, you know, tell us what what’s kind of important to you these days? 

    Prashanth: First of all, let me thank you. Thank you, Alan and TechStrong TV. This is a great opportunity to actually talk to many of the people who are using our products. Right? I am currently leading the head of product management for one of the business units in Progress, which is managing Chef line of business. We acquired Chef on board about 1.5 years ago. And this is my first foray into managing or building DevOps and SecOps tools. And that was a disadvantage, and also an advantage. 

    I got to talk to about 150-odd customers because I didn’t know much about this space. So the best way to learn about it is talking to our customers and talking to people who are experts in this domain. And that kind of got me really, really knowing about how these large enterprises are even tech companies are investing a lot in automating their day-to-day needs and adopting DevOps and their SecOps as technology practices, bringing those practices in their organization, and using tools like Chef to make just not their teams efficient, but also to increase time-to-market and reduce the risks of their business. 

    And the reason I’m talking on this, I think your target audience are the people who listen to this stuff. Your videos are the kind of practice notes that I talk day and day out all the time. They give the feedback which has helped us graph out the roadmap for years to come with Chef product line. 

    Alan: Absolutely. And you’re right. That is our audience. Right? Quite frankly, you know, when I launched DevOps dot-com eight years ago, Chef was one of the giants in the – you know, pioneer in the DevOps space, and that was our audience. But you know, over the years, we’ve seen this shift, if you want to call it shift left. It’s not necessarily a shift left, but we’ve seen an increased emphasis on security. And, you know, security’s partner in crime in many ways is compliance. 

    But as we’ve automated more, as we’ve gone faster and try to be better, faster and better, right, we’ve recognized the same way we’ve automate in DevOps deployment, we need to automate more when it comes to security and compliance. Right? And that’s been painful at times quite frankly. It’s not necessarily easy. 

    Prashanth: Oh yeah.

    Alan: Let’s talk about, you know, where the kind of hard parts are and how companies like Progress are helping us overcome that. 

    Prashanth: You’re spot on. It’s hard. It’s unnecessary evil as some people say but I think that is changing. So before that, taking a step back, why is security and compliance required? I think the need of security is well understood, but compliance data has been historically three primary reasons. Either they are regulated bodies who keep looking out who is complaint, who is not complaint. Every few months or ever few years, they publish a new set of standards, which give a perception to companies or tech companies that they need to adhere to that. 

    And that then get complemented by either the regulated sectors like banking and financial, credit card, or hospitality, healthcare, where security, privacy, all these things that are of most concern. And they look back at these regulatory bodies who have been publishing these specifications. These two kind of go hand-in-hand. And I tell you, there is a third-dimension, who are the customers who are using the products. They look at these regulatory bodies who turn out the specifications and also the regulatory. They say if I want to buy a product from you, I want it be certified. I want it to be compliant to this. 

    So these complaint as a need to operate in such industries. But I think it is moving a little from the basic necessity of, you know, being compliant to making sure that my development is fast-paced. Today, if you look at every – there are so many companies, Uber or something, Airbnb, or something, Yelp or something, and this used to be in the consumer sector, but it also coming into regular segments like banking, financials like that, Robinhood like companies have normalized trading, and they have made sure that anyone can launch a product. 

    So even tech chains, they have to adapt to this fast-paced market and bring their products not just fast into the market, but also adhere to the compliance standards, compliance specification, and make sure that whatever they launch is secure. And that is where automation comes. And that is where as a code paradigm came. You’re quite familiar with the evolution of how infrastructure as code and DevOps involved. There the codification of infrastructures have involved because they wanted to make sure that whatever gets developed is automated, and they test well in advance. 

    I think the same mindset is coming here because are there different bodies, developers, Ops team, and security teams. All of them generally speak in completely different languages, but if you want them to bring together to actuate the time-to-market, they need to speak one code, one language, and code seems to the most common, most acceptable language. And once they make a code, it falls into the DevOps sector. You can test it. You can repeat it. You can make sure there are checks and balance to make sure you flag, you audit everything. 

    But I think that mindset, and also DevOps has made compliance as code acceptable. And we are seeing more and more option. And that is ability of success for the traditional organizations to move in a fast pace. And new companies, they don’t even see other options as options. They take it as default option because this helps them past development. I don’t know if it makes sense. 

    Alan: No, it makes perfect sense. I mean it’s also a life a lot of our people are living day-to-day right now. Right? So the security person in me, and Prashanth, I was in security infosec, as we called it before, cyber sec, whenever I worry about compliance, I hear about compliance, I immediately start thinking, you know, am I dumbing down my security for compliance sake? Right? Because sometimes when we do compliance, it’s kind of, you know, I could call it least common denominator security. It’s like the lowest bar. Right? 

    Prashanth: Right.

    Alan: And a lot of people say, “Okay. I’m compliant. I must be secure too.” But they’re not. Just because you’re compliant doesn’t necessarily mean you’re secure, whether you’ve, you know. Compliance, as they say in Las Vegas, it’s a fine beginning. Right? But it’s not the mean to the end. So how do you, you know, as a compliance’s code type of provider, how do you make sure that your customers understand, okay, since you’ve done step one, but you still need to do step two and three. 

    Prashanth: Exactly. This is a very important distinction we also took a while to realize. Right? So there are three pillars: infrastructure, compliance, and security. So infrastructure is basically – I mean we can argue what is foundational, but you build your application and that’s where automation is required of infrastructure. Right? And then if you want to operate in regular tech sectors, if you want to be – not lose the competitive advantage with other players, you need to be compliant. 

    But security is something, which is fundamental. Right? You don’t realize until there is a breach, or until there is an impact on business. But, you know, these days, unfortunately, that is not very uncommon. We are seeing so many companies being exploited because of very, very basic mistakes like opening their port 80. Right? Exposing a port 80, or leaving their S3 buckets unencrypted. Right? 

    So many of these things are misconfigurations, or many of these things would have been covered or not happened if they had held to some of these standards. Two such bodies which offered a large specifications of best practices. Of course the primary takers of that is compliance. But those act as a foundation to security infrastructure. So we help our customers in obviously infrastructure and compliance, but we have started helping them in secure infrastructure as well. 

    Well, they have to look at infrastructure whenever an application passes through the CI/CD pipeline at each point in sort of just checking for the functionality using the right tools, some of the tools that we built, and some of the tools are available in their ecosystem. They can secure it. It can harden an image. For example, within Progress, there are teams which are using our Chef software to make sure that every image that gets into Artifactory, the Docker container gets into Artifactory isCIS specification, and other qualities that are specific. They don’t let it get into Artifactory without going through this. 

    So I think that is very much possible, and that is the education that we are giving and helping our customers, and that’s a two-way process. Right? Because we maturing in security. So as we engage with our customers, we are learning some of the shortcomings and the tools, and we are bringing back in the quality as code approach that we have been working in 2021 is based off this exchange, information exchange. 

    And also working with our customers, we realized that we’ve gotta go beyond infrastructure as well. Compliance and code, but two qualities a code where we help organizations define their government’s police, which is heterogenous and across organizations, sub organizations. But codify them and help them automate that process. 

    Alan: Exactly. So here’s an interesting thing from where I sit. Right? Sitting here running DevOps dot-com seven-eight years now. We can’t even have this discussion. We couldn’t have this discussion until we reached a certain level of maturity in the way we approach. Let’s forget compliance for the moment, but infrastructure as a code. 

    Prashanth: Yeah. 

    Alan: Right? Because you can’t start talking about compliance as code, and policy as code, and security as code until you got that infrastructure kind of down pat. Right? And so the fact that we are even having these discussions, right, and thinking about it, and implementing tools around it, you know, it was almost the proof on its face. Right? “Prima facie” as they say in law in school. Prima facie. That we are, we have matured, right, in the way we’re deploying our infrastructure, the way we’re automating infrastructure. So I’m calling infrastructure as code. Right? 

    Prashanth: Okay. 

    Alan: What do you think as we look ahead to 2022 and 2023, that continued maturity, what does it mean for policy as code? What’s next in other words? 

    Prashanth: I think a slight deviation from that is you said that is that you said about infrastructure expanded to DevOps methodology. Because I think that is the mindset shift that needed to happen for people to actually add up infrastructure as code, and then subsequently compliance and other paradigms, which would help them in automation. I think that is the foundation and we are seeing more and more companies seeing this as tables takes. 

    And again, they’re also – it has been a – there is a mindset shift that from where I see, it used to be a play for cost or optimization because of their bottom line. They wanted to reduce their development cost. They wanted to reduce the cost of having a breach. They wanted to reduce cost of finding a defect late in the cycle. But these days, I think is fight for spotlight because every – there is so much competition that is emerging, and there is no choice but to make your product available to your end consumer as soon as you can. 

    If you don’t do that, someone else is going to grab that opportunity for you. This makes it very, very important for organizations to take this learning that we talked about, which is a testimony that we are talking about compliance and security, but take the previous learning into their foundation. So that is what’s happening. Every new start-up that I talk about, I tell them in DevOps, these are something that they don’t even think as non-optional. Right? These are table stakes. 

    And from that point, they go on beyond, okay, I got my deployment automation. But hey, I have the security issue. I operate in a finance market. I operate in a banking sector. I operate in a hotel business. I operate in healthcare business. How can I make sure that I stay competitive? I make my data secure? This mindset of having faster time to market is making them add on these things very natural. And policy as code, whatever we are seeing, I think this is one of the common factors day one to stay competitive. 

    Alan: Got it. Excellent. All right. Prashanth, unfortunately we’re closer to 20 minutes now than we were to 15 that I told you we would do. Hey, we could continue this conversation though, but I think we’re in the right place. I think it’s something that resonates with the audience. For people wanting to get more information on Chef and Progress around this, where do they go? 

    Prashanth: Of course, we have a very vibrant community for Chef. So Chef community can be found on Slack. That is where us and other practitioners also hang out. And of course many of us are super active on LinkedIn as well. So these are the two places I think we can engage faster, and communities like this is probably the fastest to engage in Chef product, and engineering folks. 

    Alan: Okay. Hey, thanks for coming on TechStrong TV today. We’ll see you again soon. Best of luck to all the folks across Progress and Chef. 

    Prashanth: Thank you. Thanks for having me. 

    Alan: Okay. Bye-bye. All right. We’re gonna take a break. We’ll be right back. 

  • Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).

    Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.

    In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.

    The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.

    OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.

    However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.

    The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.

    There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.

    Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.

  • Managing Endpoint Compliance-as-Code

    Managing Endpoint Compliance-as-Code

    The rapid pace of modern software delivery and increasing fleet sizes have transformed how organizations see and handle security strategies. Compliance-as-code is required for today’s organizations that need security as a fundamental part of business processes. It is no longer possible to manually manage compliance with dedicated security teams.

    Balancing security with growing infrastructure needs means IT security and compliance are non-negotiable. There is no room for more uncomfortable trade-offs between risk and an organization’s ability to deliver market-ready solutions quickly and efficiently.

    Complying with growing security and compliance regulations in today’s world of rapid innovation is a constant challenge that affects all organizations, large and small. Organizations are implementing automated solutions to eliminate reliance on traditional, slow, error-prone manual processes because of tighter regulations in the industry and greater risks associated with security attacks and compliance violations.

    What is Managing Endpoint Compliance-as-Code?

    Compliance-as-code is the codification of compliance controls to automate their adherence, application and remediation. It includes the tools and practices that enable DevOps and developer teams to incorporate the three key compliance activities:

    1. Detect: Discovering non-compliance through automated estate scanning and notifying stakeholders when offending infrastructure is discovered.
    2. Remediate: Correcting non-compliance by implementing immediate infrastructure changes to ensure the highest level of compliance at scale.
    3. Automate: Avoid non-compliance by automatically verifying that planned changes comply.

    There are many important use cases for managing the compliance of endpoint state as-code including confidential data protection, detecting shadow IT resources, network security, data exposed to public access and code licensing compliance.

    The Importance of Compliance-As-Code

    Most organizations still struggle to stay secure and comply with regulatory standards. Many organizations lack visibility across heterogeneous infrastructure and applications. They also possess inconsistent language for communicating requirements between development, security and operations (dev, sec and ops) teams and are unable to remediate findings.

    Compliance-as-code enforces a comprehensive compliance strategy that involves a robust set of controls; for example, managing data storage locations and access control management.

    Ensuring that these are followed at scale is critical to the success of a digital business as more organizations shift to the cloud, there are more possibilities of non-compliance. Reports suggest that a regulatory compliance violation can cost businesses $15 million on average.

    This violation is avoidable if DevOps, development and DevSecOps teams can automate compliance by adopting a different mindset and writing understandable code. The adoption of the “as-code” strategy led to infrastructure-as-code (IaC) which is one of the success factors in DevOps teams. Audits are streamlined and allow individuals to focus on higher-value activities.

    The Challenges of Managing a Fleet Through Compliance-as-Code

    Managing a fleet through compliance-as-code is not without its challenges. First, teams must bridge the talent gap as endpoint compliance is typically managed by IT admins, who are not inherently comfortable with an as-code approach.

    Typically, compliance requirements are dense and difficult to comprehend by other stakeholders. Understanding the compliance requirements of the organization and collaborating with other stakeholders to convert them to as-code is the biggest hurdle to getting started.

    Developer teams must find the right set of tools and integrate them into DevOps and DevSecOps workflows. This is not just a process change but a culture change. A boil the ocean approach will not just be painful but success will be close to impossible. Taking small steps and continuously improving is the mindset one has to adopt.

    Visibility Throughout the Ecosystem

    Whether you are talking about end-user devices like desktops, laptops or mobile devices or non-server edge devices like point of sale (POS) or IoT devices, endpoint devices are extremely vulnerable to exploitation from bad actors. Thus, it is necessary for organizations to bring them under the organization’s security policy and governance requirements just like server-side devices.

    There are a number of advantages to adopting an endpoint compliance-as-code approach:

    • Users can easily understand what is going on across the organization in terms of compliance status at any time.
    • The organization can keep an audit log of everything that occurred throughout the development life cycle and calculate an appropriate risk acknowledgment rating.
    • Organizations can evaluate any deviations from fundamental compliance requirements.

    The Continued Prioritization of Compliance-as-Code

    Managing diverse IT infrastructure fleets through compliance-as-code ensures that endpoint devices meet a variety of security standards. The IT team is empowered to create rules that can enforce compliance and establish security baseline standards within the organization. Compliance checks are validated and more visible at each stage of the software development life cycle.

    This guarantees detailed visibility and thorough compliance standards throughout the IT ecosystem.

  • Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet has added collaboration capabilities to its security and compliance platform that automatically groups related notifications, routes them to the right stakeholders and integrates with existing workflows and collaboration tools.

    The Stacklet platform is based on Cloud Custodian, an open source project that provides access to a domain-specific language that enables an IT team to employ YAML files to manage compliance-as-code.

    Stacklet CEO Travis Stanfield said that approach makes it simpler for organizations that have embraced DevSecOps best practices to comply with a wide range of mandates by shifting responsibility for achieving compliance further left toward DevOps teams.

    The latest version of the Stacklet Platform adds communications capabilities that leverage cloud resource configuration and policy metadata to automatically route notifications and escalations. Customizable notification templates add context for teams to collaborate either via email or integrations with Slack, Microsoft Teams and Symphony instant messaging. The Stacklet Platform can also trigger external workflows in tools such as Jira and ServiceNow to track issue resolution and generate reports.

    Ultimately, the goal is to make it simpler for IT teams to prioritize their compliance remediation efforts by keeping everyone involved continuously updated, said Stanfield.

    The number of compliance and security issues that organizations are experiencing in cloud computing environments is especially problematic. Developers often employ infrastructure-as-code (IaC) tools to provision cloud infrastructure. Unfortunately, they typically lack security and compliance expertise, which then results in large numbers of misconfigurations.

    The Stacklet platform is designed to give DevOps teams a way to prevent compliance and security issues using a compliance-as-code framework that spans multiple cloud platforms rather than requiring DevOps teams to employ a different set of compliance tools for each cloud platform on which applications are deployed.

    It’s not clear yet how far left responsibility for compliance will shift. In theory, organizations could avoid penalties if compliance issues are addressed before an application is deployed in a production environment. However, the teams that manage compliance in larger enterprises today are even further removed from DevOps teams than their cybersecurity counterparts. It may be several years before the cultural divide between these teams is bridged. In the meantime, many DevOps teams are taking it upon themselves to manage compliance as code to prevent unexpected issues from arising at the last minute before deployment.

    Overall, the goal is to enable DevOps teams to enforce compliance policies without slowing down the rate at which applications are built and deployed. The hope is that the adoption of compliance-as-code and DevSecOps best practices will address that issue. In fact, as the pace at which applications are deployed continues to accelerate to support digital business transformation initiatives, the number of potential compliance issues steadily increases. More troubling still, the greater the number of compliance issues there are, the more likely it becomes that cybercriminals will find a vulnerability to exploit.

  • CloudBees Acquires Neuralprints to Shift Compliance Left

    CloudBees Acquires Neuralprints to Shift Compliance Left

    At the online DevOps World 2021 conference today, CloudBees revealed it has acquired Neuralprints to provide the core technology for CloudBees Compliance, a real-time compliance and risk analysis platform that it will roll out in the first quarter of 2022.

    At the same time, CloudBees has enhanced the feature management capabilities of its namesake continuous integration/continuous delivery (CI/CD) platform to provide greater visibility into and control over feature flags that are now widely used to add new capabilities to applications.

    Prakash Sethuraman, chief information security officer (CISO) for CloudBees, said CloudBees Compliance will make it possible for DevOps teams to continuously enforce compliance policies as part of an effort to better secure their software supply chains. Those DevOps teams will be able to enforce compliance across code, binary artifacts, data, identity and infrastructure environments in a way that provides developers and IT operations teams with instant actionable feedback to enable issues to be addressed long before an application is deployed in a production environment.

    CloudBees Compliance is based on a mix of open source and proprietary technologies developed by Neuralprints and will be made available for on-premises IT environments as well as via a software-as-a-service (SaaS) application. The goal is to enable organizations to manage compliance as code as part of any effort to shift more responsibility for application security further left toward DevOps teams, said Sethuraman.

    CloudBees Compliance

    A survey of 500 C-level executives published today found nearly half (45%) admit that initiatives to secure their software supply chains are halfway or less-than-halfway complete. Nevertheless, 95% claimed their software supply chains are secure (95%), with more than half (55%) posting they are very secure.

    A full 93% said they are prepared to deal with an issue such as ransomware or a cyberattack on their supply chain. However, nearly two-thirds (64%) admitted they are not sure who they would turn to first if their supply chain was attacked; with 58% admitting that, if they experienced an attack, they have no idea what their company would do. An equal percentage (64%) said it would take more than four days to fix the problem if they did experience an issue.

    Almost all C-level executives (95%) said they think more about securing the supply chain now than they did just two years ago, and 92% said a security issue would impact their brand. A total of 83% said security issues cause their developers to drop everything to review code, with 82% noting that caused the organization to spend less time on innovation.

    On the plus side, 95% of executives said container images are checked for high or critical vulnerabilities, while an equal number said automation access keys are set to expire automatically. A total of 92% said their company only accepts commits signed with a developer GPG key, while 90% said dependencies to trusted registries are limited at their organization, while 89% said administrative access to CI/CD tools is restricted (89%).

    Of course, what C-level executives believe and what actually occurs inside an organization are not always one and the same. A series of high-profile software supply chain breaches resulted in a number of organizations reviewing their software supply chains. At the same time, the Biden administration has issued an executive order requiring all federal agencies to conduct similar reviews.

    One way or another, most organizations will soon find themselves embracing a wider range of DevSecOps best practices to ensure the integrity of software supply chains no matter how secure they may think their software development platforms are today.

  • Relyance AI Shifts Compliance Left Using ML Algorithms

    Relyance AI Shifts Compliance Left Using ML Algorithms

    Relyance AI emerged from stealth this week to unveil a namesake platform for managing privacy and data governance in real-time within the context of a larger DevOps workflow.

    Fresh off raising $30 million in seed capital, Relyance AI co-CEO Leila Golchehreh said organizations can now quickly and accurately answer essential privacy questions and ensure compliance and governance by mapping requirements directly to their codebase. The platform provides transparency and visibility all the way down to the source code in real-time using machine learning algorithms, she added.

    Relyance AI co-CEO Abhi Sharma also noted most legal and data protection teams today have limited visibility into digital operations. Developers and data scientists are constantly creating and updating applications. By the time compliance teams gather the data required, it’s obsolete, said Sharma.

    The Relyance AI platform analyzes contractual requirements against the operational reality as determined by data processing in real-time. Compliance teams can then address privacy issues as they arise, added Sharma.

    At the core of the Relyance AI platform are five integrated components that first inventory assets by connecting to application programming interfaces (APIs); generate universal records of processing activities (ROPAs) by scanning code and understanding how data is being processed; share alerts when issues are detected; provide views into data life cycles to highlight data subject access request (DSAR) exceptions and extensions and address vendor life cycle management to ensure third-parties are complying with policies.

    Relyance AI

    Sharma said compliance, much like security, is shifting further left toward application development as organizations look to eliminate issues before they arise in a production environment. The Relyance AI platform is designed to be integrated with continuous integration/continuous delivery (CI/CD) platforms that are the core of modern software development life cycle processes, he added.

    Undoubtedly, as the worlds of compliance and application development collide, there will be cultural challenges similar to what is now occurring with the rest of DevSecOps best practices that require more collaboration between developers and security teams. The challenge is compliance officers tend to be even further removed from application development than their IT security counterparts.

    However, it’s now only a matter of time before compliance becomes code. Modern applications already make use of the Open Policy Agent, for example, to embed compliance rules in applications. AI platforms should make it simpler to identify compliance issues as they arise so that they can be addressed before any infraction ever occurs.

    DevOps teams, of course, have a vested interest in managing compliance as code. It’s not uncommon for DevOps teams to race to build and deploy an application only to encounter a wave of compliance issues that need to be addressed by recoding elements of the application. Not surprisingly, those compliance issues often result in application delivery deadlines being missed. Machine learning algorithms provide an alternative to the current raft of documents that compliance officers create, but not enough other members of the IT team read those, much less understand them.

  • CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    The Cloud Native Computing Foundation (CNCF) announced this week that the Open Policy Agent (OPA) project, which many IT teams are employing to manage compliance as code, has officially graduated.

    Torin Sandall, co-founder of the OPA project and vice president of open source at Styra, whose compliance management platform is based on OPA, said formal recognition of OPA alongside other CNCF projects, such as Kubernetes, should help further adoption of the open source project that first took shape in 2016.

    Now being advanced under the auspices of the CNCF, the open source agent created by the OPA project is increasingly being incorporated into a wider range of compliance and security platforms. At the same time, more developers are starting to manage compliance as code across a wider range of applications. The ultimate goal is to make it easier to meet compliance requirements using a declarative framework so that responsibility for implementing compliance policies shifts further left toward developers.

    OPA uses a general purpose engine for enforcing policies that uses a set of rules that developers embed within applications using the Rego language. OPA has gained traction among cloud native application developers because it provides a means to enforce policies across a wide range of microservices.

    Sandall said going forward, the primary focus of the OPA project should be to develop and share as many integrations as possible. There are many instances where a use case for OPA has been created, but development teams simply don’t know that use case exists. As a result, many IT teams are attempting to employ compliance as code to address an issue that others have already solved, Sandall said.

    During its time as an incubation project managed by the CNCF, the security special interest group (SIG) within the CNCF conducted two external OPA security audits. The OPA project has also defined a security vulnerability disclosure process and a security response team.

    It’s not clear whether chief compliance officers within enterprise IT organizations have developed an appreciation for OPA. In theory, many compliance issues could be avoided if organizations mandated using OPA – or another approach to managing compliance as code – within their applications. Those compliance issues, of course, are multiplying as the number of compliance mandates expand globally. The challenge is that most compliance teams don’t have much visibility into the application development process.

    In the meantime, as DevSecOps processes continue to mature, it seems almost inevitable they would expand to include compliance mandates, most of which only exist to ensure some base level of security is present. Of course, developers may not want to be responsible for compliance mandates. However, the sooner compliance issues are addressed in the development process, the less likely they are to become DevOps’ problem when deployed in a production environment.