devopsy.kinsta.cloud

Tag: compliance

  • Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra is now making the enterprise edition of the Open Policy Agent (OPA) available under a source license that enables IT teams to modify or change the underlying code as they see fit when integrating it with other applications.

    Enterprise OPA is a drop-in replacement for OPA, agent software for implementing policy-as-code that is already available under an open source license. Styra’s enterprise edition provides access to a version that provides better performance, native integrations for a suite of data sources and additional capabilities such as policy decision analysis.

    Previously, Enterprise OPA was only available in either a binary or container format. While these formats enable Enterprise OPA to be widely used, they limited it from being built directly into applications for performance optimization because no access was provided to source code.

    Chris Hendrix, director of product management for Styra, said the source license also provides organizations with an assurance that they will be able to continue to modify Enterprise OPA in much the same way as they modify the open source edition.

    It’s not clear how many DevOps teams are managing policy-as-code within their pipelines, but as application security regulations become more stringent, it’s only a matter of time before most of them do so in one way or another. Styra’s approach relies on a Rego programming language that some DevOps teams have found challenging, however. To make it simpler, the company is working on a low-code approach that would help make Enterprise OPA more accessible, said Hendrix.

    In addition to encouraging more DevOps teams to use Enterprise OPA under a source license, Syra is clearly moving to make it more attractive to replace existing instances of OPA with a more robust implementation licensed from the company. No one knows how many instances of the open source edition of OPA advanced under the auspices of the Cloud Native Computing Foundation (CNCF) are running in production environments. But as those applications become more complex, the need for deeper levels of integration enabled by a faster version of OPA becomes more apparent.

    OPA enables developers to programmatically embed compliance controls without waiting for a compliance team to make them available. That ultimately makes it simpler to ensure that the proper controls have been implemented before an application is deployed in an on-premises IT environment. That capability also makes it easier to document which controls have been applied to make any audit less time-consuming.

    Shifting responsibility for compliance controls to the left also enables DevOps teams to better understand which controls address specific regulatory mandates incorporated into most applications versus which controls might be specific to a specific regulation. Armed with those insights, it then becomes simpler to incorporate policy-as-code within a DevSecOps workflow.

    Hopefully, more applications running in production environments will soon be secure by default. Naturally, one of the first places to start is by making sure the compliance controls needed to achieve a baseline level of security have been pervasively implemented.

  • Declarative Compliance With Policy-as-Code and GitOps

    Declarative Compliance With Policy-as-Code and GitOps

    In recent times, the quest for greater agility, faster releases, enhanced scalability, security and performance brought forth the advent of several automation tools, technologies and frameworks. Software development has evolved considerably over the years to mitigate these challenges.

    Monoliths have been split into microservices for improved scalability, maintenance and faster releases. Since DevOps is adept at bridging the gap between development and operations teams, now these two teams can work together to improve productivity and speed up release cycles.

    The Need for Compliance

    One of the critical strategies for business success is to stay compliant since processes are always improving and evolving. Compliance ensures that your DevOps processes and practices are consistent and meet regulations or regulatory standards.

    An organization with a compliance-driven DevOps culture can cut down on operational costs, improve efficiency and reduce risks considerably.

    What is Declarative Compliance?

    Declarative compliance is defined as the process of managing and enforcing compliance in which policies are defined using code, and the system’s desired state is declared rather than explicitly programmed. To enforce compliance policies, you don’t write scripts or programs; instead, you use a high-level language or configuration file.

    Declarative Compliance provides several benefits:

    • Increased efficiency
    • Better managed compliance
    • Minimized risk of human errors
    • Enhanced security
    • Faster deployment
    • Better collaboration

    With declarative compliance tools, the system’s state is defined as a set of policies, and the tool makes sure it matches the desired state. The tool will automatically fix anything out of compliance, bringing the system back into compliance if there’s a deviation.

    Tools for Declarative Compliance

    Some of the popular declarative compliance tools are:

    • Open Policy Agent (OPA)
    • Terraform
    • Kubernetes Policy Controller
    • Chef Compliance
    • AWS Config

    Declarative Compliance for Infrastructure and Application Deployment

    Often, declarative compliance is used in infrastructure management and application deployment, where policies are written as code and enforced across multiple environments. In addition to managing compliance at scale, declarative compliance tools ensure that the system’s desired state stays consistent across multiple systems and applications over time.

    With declarative compliance, organizations can manage compliance more efficiently, effectively and securely since they can define policies as code and enforce them automatically. In addition to reducing errors, downtime and security breaches, this approach enables organizations to stay compliant and maintain their system consistently.

    Introduction to Policy-as-Code

    A policy-as-code approach allows you to write programs that govern security, compliance and rules throughout your application’s life cycle. It entails defining and applying code to manage and automate policies. It shares the same ideas as infrastructure-as-code (IaC) and other DevOps practices like continuous integration and continuous delivery (CI/CD).

    A policy enforces constraints and restrictions to prevent unauthorized access to resources such as databases, storage, services, etc. By codifying policies, you can enforce rules and constraints throughout the development life cycle to prevent non-conforming resources from being deployed by integrating these policies into the software development life cycle.

    compliance policy-as-code

    Figure 1: Policy-as-Code at work!

    Why Policy-as-Code?

    Typically, businesses have the required processes, tools and procedures to guarantee the deliverable’s quality. Performance, scalability, ease of use and accuracy are typical quantifiable quality metrics used to ascertain the quality.

    You can examine the quality of your application using these metrics, but a manual procedure will take time and is prone to mistakes. A better alternative is to leverage policy-as-code.

    The traditional policy enforcement processes have certain drawbacks. It is challenging to perceive that your policies would be entirely adhered to, i.e., they will not be broken. It is cumbersome to check against a list of policies manually.

    Moreover, the traditional policy enforcement method cannot scale in today’s agile world, where organizations have been growing continuously with more and more employees, services and teams.

    Here are the key benefits of policy-as-code at a glance:

    • Faster and more efficient deployments
    • Automated governance, approvals and policy enforcement
    • More reliable and secure applications
    • Centralized policy management
    • Leverages version control
    • Better visibility of policies
    • Enhanced collaboration

    How Does it Work?

    Policy-as-code involves three key elements:

    1. The policy itself, which contains the required code to model the decision-making process
    2. The data and information about the environment, service or application
    3. The query that is responsible for triggering the decision-making process

    Here’s how policy-as-code works:

    1. Policies are defined as code in a human-readable format
    2. These policies are then translated into machine-readable code using Rego or HCL
    3. The policies are integrated with the IaC pipeline
    4. A policy engine evaluates the infrastructure and the application resources against these policies
    5. The policy engine accepts the policies as input, processes them and then produces a query result
    6. The policy engine reports violations (if any) to the respective stakeholders, such as the development or security teams
    7. If violations are reported, the necessary remediation is performed automatically or manually

    Types of Policies

    • Security policies: Security is enforcing adequate technological controls to safeguard company assets.
    • Compliance policies: Compliance policies are designed to help organizations adhere to governance standards. Typical examples include PCI DSS, GDPR, HIPPA, etc.
    • Operational excellence: This encompasses policies pertaining to service degradation or interruption.

    What is GitOps? How can GitOps Help With Compliance?

    GitOps is a subset or extension of DevOps encompassing a collection of practices that can simplify deployments using Git. It is an operating model for cloud-native applications that leverages Git as a single source of truth for declarative applications and infrastructure. Using GitOps, you can implement a standardized policy-as-code approach across your CI/CD and GitOps pipelines.

    The key principles of GitOps are:

    • The state of the system is captured and stored in a Git repository
    • The entire system is configured declaratively
    • Automated deployment

    You can create policies in Git and store them in a particular repository, which is essential since Git offers sophisticated change management tools like version control. Only the compliance team would have admin access to the repository.

    It’s easy to enforce policies with Git, and you can apply them to any execution engine, like CI or CD. With GitOps, you can audit and document every action that affects data consumption.

    You can expose system changes, optimize deployment and use a version-controlled infrastructure. By managing compliance with GitOps, you can make sure that the changes are visible, verifiable and auditable.

    GitOps

    Figure 2: GitOps at work!

    Using GitOps as the Execution Engine in a GitOps Process

    There are several benefits to using GitOps as a process execution engine, including:

    • Increased automation: GitOps automates software delivery, reducing manual intervention and increasing deployment accuracy and speed.
    • Better transparency: GitOps records all changes to the system in a transparent and auditable way so that you can track compliance easily.
    • Maintaining consistency: GitOps keeps the system in the desired state defined in the Git repository, reducing non-compliance risk.
    • Fosters collaboration: All changes to the system are made through the Git repository, so GitOps encourages collaboration across teams.

    Using Policy-as-Code and GitOps: Policy-Based Compliance

    By using GitOps and policy-as-code, teams can manage compliance-as-code in an auditable, declarative way and enforce it via GitOps, ensuring that the desired state is always maintained. This can help your teams to codify compliance requirements as code, store them in version control and automatically enforce them through GitOps.

    Organizations can improve the consistency and reliability of their systems by defining and enforcing compliance requirements using policy-as-code and managing their deployment processes with GitOps. While this can minimize compliance violations, it can also maximize efficiency.

    By following policy-based compliance declaratively, businesses can define policies as code and enforce them automatically and repeatedly. By adopting such an approach to compliance management, you can better manage compliance in complex systems in a consistent, scalable, agile, transparent and collaborative manner.

    For example, you can leverage policy-as-code to define policies for infrastructure provisioning and configuration management to ensure that the infrastructure complies with organizational policies and industry standards. Typical examples are defining policies for network configuration, access control and resource allocation.

    Use Cases: Using Policy-as-Code and GitOps in a Production Environment

    Infrastructure Provisioning

    Open Policy Agent (OPA) can define policies for infrastructure resources like AWS Elastic Compute Cloud (EC2) servers. You can use GitOps to manage the deployment of infrastructure resources by storing IaC files in a Git directory. When the IaC files are changed, GitOps is adept at automatically deploying the changes while OPA checks for policy compliance.

    Deployment

    You can use policy-as-code tools such as OPA to create application deployment policies requiring specific security settings, while GitOps manages the application deployment by storing manifests.

    Manage Kubernetes Clusters

    You can leverage policy-as-code to better manage your Kubernetes clusters. So, you can write your code to define policies to manage Kubernetes resources, such as nodes, pods, clusters, etc., declaratively.

    Compliance Management

    You can use policy-as-code to establish and implement rules and regulations, such as those pertaining to security, to help businesses ensure that their systems comply with industry regulations and standards.

    OPA can be used to set compliance policies, like restricting access to sensitive data to authorized users only. You can use GitOps to manage the deployment of compliance policies seamlessly.

    Trusted Delivery: Policy-as-Code Integrated With GitOps Workflows

    Trusted application delivery is a software delivery approach emphasizing security and trust in the software supply chain. This ensures that any software delivered to the clients is devoid of security flaws, malicious code and other attacks.

    This approach prioritizes security and trust at the development, testing, packaging and deployment stages and integrates security and compliance checks into the GitOps pipelines. This quality check reassures clients about the product’s quality and ensures that any modifications adhere to predetermined rules and principles.

    Trusted application delivery allows for quick deployment while securing apps with automated guardrails. These guardrails are implemented using policy-as-code. By enforcing these guardrails, you encourage frequent deployments while ensuring that the reliability and security of the application are not compromised.

    Conclusion

    Declarative compliance with policy-as-code and GitOps is a best practice for achieving greater compliance, reliability and agility in software development and deployment processes. You can simplify defining and enforcing compliance policies using declarative configuration files and automation tools. Using Git as the single source of truth for all configuration changes, an organization can achieve greater efficiency, visibility and auditability in the compliance process.

  • Why Backups and Compliance Go Hand-in-Hand

    Why Backups and Compliance Go Hand-in-Hand

    It’s hard to run a business. Besides the numerous challenges you have to deal with daily, ensuring the security of your business and customer information is essential for operating smoothly. In order to mitigate information security risks that would affect companies and their users, a number of security regulations have been created, including a set of best practices that companies must follow.

    Compliance with these regulations will allow you to:

    ● Reduce security and privacy risks
    ● Strengthen control of key processes
    ● Align cybersecurity requirements with business processes
    ● Better understand cybersecurity goals and how to handle business security challenges
    ● Maintain effective cybersecurity programs
    ● Build customer trust and improve company reputation

    One critical requirement to achieve compliance is backups. Organizations back up information that’s vulnerable to threats like software or hardware failures, cyberattacks or human error. Any one of these problems could potentially lead to data loss, system malfunctions, financial losses and reputational damages. In this post, you’ll learn more about why data backups are an important part of compliance and about the benefits of having a robust backup strategy.

    Why are Backups Important for Compliance?

    Regulations like GDPR, PCI-DSS and HIPAA, along with others, were created to ensure that organizations implement the most reliable methods to secure all types of sensitive data from infrastructure failures and malicious attacks.
    Compliance can’t be achieved unless an organization handles data in a way that adheres to the outlined regulations.

    Certifications like ISO 27001 and SOC 2 are considered the most thorough audits an organization can go through to prove they have taken all the necessary steps to protect business and user data. Unlike the regulations mentioned above, ISO 27001 and SOC 2 aren’t legal requirements, but they’re especially beneficial to SaaS companies, data centers and organizations that deal with sensitive information. They make it very clear that the company takes data security very seriously and considers it a top priority. By properly implementing the data and privacy controls required, you can increase reliability and user trust as well as gain a competitive advantage over other companies.

    To be able to obtain such certifications and comply with regulations and different standards in general, you’ll have to maintain robust, up-to-date backup processes that ensure data is always protected but also available to users—even in cases of unexpected events like natural disasters, cyberattacks, data losses and human error. In other words, to comply with regulations, your backup processes must match your business continuity plan and the data backup tools you are using should be able to handle your backup processes.

    Backups, of course, do more than enhance business continuity, as mentioned above. Although they can’t prevent an attack or a data loss from happening, they’re an integral part of your overall security strategy since they allow you to restore lost or corrupted information, mitigating the consequences of such an event.

    There’s no fixed rule for how frequently you should back up. Still, ideally, to secure valuable information, you should implement a combination of full and partial backups as often as possible. Fortunately, great data backup solutions can efficiently handle this complex but crucial task.

    The Difference Between Backups and Compliance

    Backups and data availability are just one of the many requirements for a company to comply with any regulation. It’s an important part, but it’s not enough on its own. Obtaining a security certification isn’t a quick and easy process that you can decide to do and then finish a month later. It’s a time-consuming process that will require buy-in from every member of your team and will ultimately involve in-depth tests and evaluations of how you secure data.

    Although each certification is slightly different, all of them require a company to implement a wide range of security procedures. For example:

    ● Structure your organization in a way that allows optimal management of your services.
    ● Have a strong disaster recovery plan.
    ● Communicate in detail with users about how your system works, your security policies and your processes.
    ● Perform risk assessments regularly to identify risks, measure their impact and create a plan to address them quickly and effectively.
    ● Continuously monitor your security controls to verify they’re operating as expected.
    ● Make adjustments as needed to stay ahead of the latest security threats.
    ● Control physical access to your devices and prevent unauthorized access to your systems.
    ● Integrate best practice security procedures into your day-to-day workflows.
    ● Optimize system operations to detect vulnerabilities early and deal with security incidents.
    ● Clearly describe how you handle changes in your infrastructure to ensure that they won’t affect your business operations.

    The above is far from an exhaustive list, nor will it guarantee regulatory compliance. There are numerous criteria you need to fulfill. Although compliance might seem a huge undertaking, the benefits surpass the difficulties.

    As the security risks in the technology world are constantly changing and becoming more sophisticated, organizations must be able to deal with them or face the consequences. For businesses that want to protect their customers and themselves, following security standards has become necessary. But security compliance isn’t an easy task, and it’s made more complicated by the fact that all of the vendors you use must also be compliant.

    Having a reliable data backup strategy is a crucial step for compliance with regulations and achieving business continuity. Fortunately, there are top-notch data backup tools that can make this complex process easier. These tools allow you to back up regularly to secure your valuable data, and will often automatically run backups on a schedule of your choosing. If you wish to remain compliant and ensure your data is protected, I highly recommend installing a backup service.

  • Business Leaders Will Trade Speed for Security

    Business Leaders Will Trade Speed for Security

    A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

    As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

    Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

    Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

    CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

    Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

    The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

    As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

    Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

  • Compliance Synergy – DevOps Unbound EP 25

    Compliance Synergy – DevOps Unbound EP 25

    Achieving compliance might be challenging when embracing DevOps due to the rapid pace of development. However, the agility and automation associated with DevOps might actually simplify compliance. When integrating compliance into the SDLC, DevOps teams may have to use different tools or slightly modify part of their processes to adapt to specific requirements. In this episode,Sonya Lowrence (Tricentis), Anna Murray (Rocket Software), Dan Kirsch (Techstrong Research) and Tim Johnson (Cloudbees) join hosts Alan Shimel and Mitch Ashley to discuss how to effectively integrate compliance as part of your DevOps process and the challenges that come with it. Is it possible to deliver high-quality software at the speed of DevOps whilst ensuring security compliance? The video is below followed by a transcript of the conversation.

    Alan Shimel: Hey everyone. Welcome to another episode of DevOps Unbound. DevOps Unbound is a biweekly video series that explores all aspects of DevOps. We’ve been doing this for over a year now and it amazes me the breadth and depth of DevOps topics that we’ve had a chance to dive into here on DevOps Unbound.

    The show is sponsored by our good friends at Tricentis who have been our partners in bringing DevOps Unbound to you now as I said for more than a year and have really, in every sense of the word, partnered with us to really explore, go where no man or woman has gone before and DevOps and kind of really looked at things and take them apart. So many thanks to them for sponsoring. Welcome to our show.

    We have to sort of formats for DevOps Unbound. The every other show, every other week show is about 40 or 45 minutes of a prerecorded conversation with a panel of experts. And then around once a month we do do a live roundtable of DevOps Unbound in which the stars of the show are you, our audience. And you are invited to come on, participate in the conversation and ask questions, comment, chat with each other and it’s just – when it goes right, it’s a rip-roaring conversation of a thousand different directions. But it’s a fantastic experience. I invite you to, I think the next one might be around March 15 or something. But check it out, we’ll get the dates for you. But I do invite you to come to our next live roundtable as well.

    Anyway, let’s get on with today’s show, though. Today’s show is about DevOps and Compliance Synergy, Reality or Fiction? I have some thoughts on this but before we do, let me introduce you to today’s All-Star panel.

    On my screen, he’s on the top left. I don’t know where he is on your screen. It’s my friend Tim Johnson from CloudBees. Tim, why don’t you introduce yourself.

    Tim Johnson: Thanks, Alan and thanks for having me here. As he said, Tim Johnson. I’m in product marketing at CloudBees. I’ve been in DevOps since about 2016 and a whole lot of years in security prior to that. So happy to be here.

    Alan Shimel: Thank you, Tim. Thanks for being here. Next up I want to introduce you to Anna Murray. Anna, if you wouldn’t mind introducing yourself to the audience.

    Anna Murray: Thank you, Alan. Thanks for having me here. My name is Anna Murray and I work for Rocket Software, a recent acquisition through ASG Technologies, if you see me before. I’ve spent my career in automation. So at this point, I’m a product manager for automation technologies with Rocket Software and I’ve taken teams from Waterfall project management through Agile transformations and Agile has grown to DevOps and I am passionate about automation when it comes to all of that.

    Alan Shimel: Fantastic, Anna, thanks for joining us. Next up I want to introduce you to one of my colleagues, Dan Kirsch. Dan, if you wouldn’t mind introducing yourself and telling people a little bit about you.

    David Kirsch: Thanks, Alan. I’m managing director and one of the principal analysts and cofounder of Techstrong Research. And as a recovering attorney, compliance is certainly an issue that is near and dear to me.

    Alan Shimel: Absolutely. Our next panel member is, we’re very happy to have her, Sonya Lowrence. Sonya, welcome and maybe if you could introduce yourself to the audience.

    Sonya Lowrence: Sure, thank you, Alan. Hi, I’m Sonya Lowrence. I’m the head of compliance at Tricentis and I have been in this role and working closely with DevOps actually in a couple rules now since 2018. And before that, I was a programming manager heavily embedded with the integrations and Cloud operations for about 15 years. So I’m also very passionate about how to bring this to the dev team and streamline DevOps. So looking forward to it.

    Alan Shimel: Excellent. Last but not least, my cohost for DevOps Unbound and business partner, associate for 20 years, Mitch Ashley. Mitchell, if you wouldn’t mind saying a little bit.

    Mitch Ashley: Yeah, Alan. What a great panel. I’m excited to hear everybody chat about this topic. I’m CTO with the Techstrong Group and also work with Dan as part of Techstrong Research. So looking forward to us diving in.

    Alan Shimel: Absolutely. And thank you, Mitchell. All right. So guys, this episode is DevOps and Compliance Synergy, Reality or Fiction? Let me start it off with this.

    My background is in cybersecurity, 20+ years, Mitchell and I have worked together in it. Tim, you’ve been in cyber a long time, too. I will be really honest with you. One of my most hated subjects or aspects of security is compliance. I think compliance has done as much to hurt security as it’s done as much to help security. It’s introduced this least common denominator, lowest possible bar for security where instead of doing what we should be doing, we are doing what the minimal needs are, checking it off, check that box and we move on. And then we act surprised when stuff hits the fan.

    Now, I started devopsy.kinsta.cloud because I thought DevOps was a godsend for security. Finally, a chance to get it right. Not to be bolted on, to be built in. And where security goes, compliance follows, right? Keeping that low bar here. And the promise of DevOps, especially with compliance but even more so than security, was my God, we could automate this. If we could just automate the compliance, we don’t have to worry about it anymore and we can focus on really making secure software. Because compliance becomes sort of a byproduct of security automation in DevOps.

    Now, as we sit here today, we know that that hasn’t necessarily been the outcome. Let’s leave it at that. Maybe it has been to some of you. I’m interested to hear. Don’t let me bully you. Has DevOps been a good friend to compliance or are we barking up the wrong tree? Are we chasing our tail? I don’t know how many dog analogies I can come up with here but what is the deal with compliance and DevOps? Who wants to start us off?

    Tim Johnson: I’ll jump in, Alan. You crack me up. We’ve been hearing that for forever and the dichotomies that we have to deal with, can you be compliant and fast? Can you be projectable and flexible? It’s like yeah, come on. Knock it off. It isn’t like that.

    The way we’re seeing it is DevOps is kind of going through this evolution of can we just automate the pipeline or can we get the CI part to work? And then can we automate the testing part? So it’s kind of evolutionary. And security has kind of come along, I think about 2017, John Wallace, we did a webinar with him where he’s talking about dev sec ops and saying that the sec should be silent because if you’re doing it right, the security is there. And now we’re coming to the next evolution and the next source of friction, if you will, is compliance. Because okay, we’re going faster, we’re going secure. Somebody says can you prove that to the regulators? And the way we see it is we have a bank customer of ours has 100 people devoted full-time on a 90-day rotating basis to doing compliance work.

    Alan Shimel: Sounds automated to me.

    Tim Johnson: Companies are doing. So that’s kind of a state of where we are. So from where I am, if you can’t do an audit easily, you ain’t running DevOps. You ain’t doing DevOps right in the first place. So if you are compliant and you can prove it to the regulators, you’re doing DevOps really well. That’s my opening salvo. Back to you.

    Alan Shimel: All right. I guess someone else wanted to say something.

    Sonya Lowrence: Yeah. I’m very passionate about this definitely at Tricentis but honestly just anywhere. I feel like it’s a two-part answer right now. I think I’m finding more compliance people in my space who understand, again, I come from a heavily background so for me, it’s very native to say compliance is an afterthought. If you look at it the right way, even though it may be a low bar, it’s an input. It’s a set of basic requirements. If you can accommodate that upfront, there are very few surprises. 

    And I would even extend on that and say in the world that we are moving to in DevOps and better automated tools where your CICD pipeline takes all of this into account, both your code and your Cloud environment, I really feel like it’s going to start to deliver inherently secure code and infrastructure. It’s just that that vision and the tools that are bit lagging, right? I don’t see that there are really any surprises. Couple of example frameworks SOC 2 type 2, ISA 2701. The objectives are clear. If you wrap that in at the beginning as a requirement, then there are very few people that one, don’t get trained as they go and two, can’t deliver because it actually is not that hard or complex to deliver technically.

    So I think that part of what we are seeing, and this is in part to me having been a program manager for years, Agile took and pared it down to a very lean perspective of we’re looking at features first, customer needs and typically things like encryption and administration and users was kind of an afterthought and it’s not built-in to the traditional Agile tools. I think that along with what Tricentis is delivering for quality, many companies are starting to respond with respect to compliance and security and putting it back at the front where I think it belongs. Again, this is not technically difficult. It’s the fact that it’s basically not built in to the current CICD tools. It makes it challenging, I think, for developing teams and infrastructure teams.

    David Kirsch: Yeah, I think what Sonya said made a lot of sense. It’s also, now when we are talking about DevOps, we talk a lot about culture change and changes in process as much as technology. So if the dev team is just go, go, go, go, what new features have you added today? They are never going to think about compliance. But if the development team feels that they have a working relationship with the compliance team and they are working together and they understand what the compliance team needs and why they need it, not just oh, it’s a checkbox but it’s important and it’s important for more than just our auditor to look at. That sort of merging together of collaboration between DevOps and compliance is an important aspect.

    Sonya Lowrence: Absolutely.

    Tim Johnson: I think part of that is some of the evolution that we are seeing and thinking, at least from the dev side is a maturing from a bug is a bug but it’s matured into a security vulnerability is a bug and noncompliance is now starting to be thought of as a bug. And there really aren’t too many developers out there who aren’t passionate about writing bugless code. But the challenge is, what is compliant? And how many standards do you have to adhere to? And how does that translate into all the different environments, the runtime environments, the binaries, the code, the access to the data that you’re dealing with. How do you translate all of those mumbo-jumbo from those regulatory standards down into being compliant with this piece of code that your writing? That’s a big challenge.

    Sonya Lowrence: No, I agree. And especially to that point, when I am evaluating alongside our dev teams and our product teams tools that help augment and fill these gaps, I’m definitely very aware and making sure that we’re starting from the rate baselines. There are baselines that if you work from it is kind of that magic decoder ring so all the different frameworks you need to apply going forward from a compliance standpoint. And once that’s in place, again, it just streamlines all of this for all of the teams. So it’s a really important consideration in tool selection.

    Anna Murray: And I’m going to finally jump into the fray here. I think that’s also been part of the challenge that we’ve seen among people we are talking to is that there are so many tools in place. How do you get that report so you can see what’s happened and you can reply to your auditor? And so we’ve really been talking to people a lot more about making sure that you have a plan that surrounds all of this because not only do you have a lot of tools, you might be replacing one or two of them every year because there’s better technology. And so you need good, planned workflows that are going to work for you no matter what you put in play into that workflow. And it’s not an easy answer to get from here to there and as somebody said, it is a journey for every company. And so it really does behoove the leadership to make that culture change as Dan talked about. But it isn’t just about adopting DevOps. It’s about having an end to end plan or making sure that you are delivering that value on a consistent basis as things change around us all the time.

    Alan Shimel: Agreed. To me, I’m going to be just the devil’s advocate today, I’m sorry. But I almost hear us saying hey, you know what’s great about us this DevOps thing? We are going to make compliance the developer’s problem, not the security person’s problem. Right? Developers, they’re well-paid, what the heck. But they have enough on their plate. I don’t need my developer necessarily to be my tester as I think the folks at Tricentis will clearly tell you. I don’t need my developer to be my security person. I need them to be security conscious, security aware. But I don’t need them necessarily to be a compliance expert. So therefore, if we can’t develop the tools that can automate compliance as almost a byproduct of the process and instead throw it onto the shoulders, put another straw on the camel’s back of the developer, I don’t know if it’s successful. If it can be successful.

    Tim Johnson: Agreed, agreed. The shift security left thing just really bugs the bejeebers out of me on a couple of levels. 

    [Laughter]

    Tim Johnson: One, like you talked about Alan, just the burden that it puts on the developers to know more stuff. But there’s also kind of the implication if we do all the shift to all the left, all the rest of the stuff to the right of that magically takes care of itself. Environments can be changed. Credentials can be mucked about with and stuff once the process has started. So there’s two levels here. Your pipeline, defined pipeline should have that level of governance and guardrails and gates and everything else that goes along. But you still beyond that have to look at all of the other moving parts around there and attest that everybody did what they are supposed to do. Because at the end of the day, it’s folks like Sonya or maybe Sonya’s boss who have to sign the paper that said this meets our risk profile and we can go forward. That still has to be a separate thing. But you need that visibility outside of the pipeline itself to be able to see it and control that.

    Sonya Lowrence: Yeah. And to speak to that, I feel like again I’m going to come back to people aspect of this challenge. One of my biggest partners in any company that I work at, especially when you start looking at the program and platform level, future state, making this inherent in the design are architects or I know that that’s not a role that’s very frequently filled at smaller companies, the group or team of leaders in the engineering org that fill that role of architect. If I can work with the architects upfront, again, it becomes inherent in the design. I agree, Alan, I do think it’s exorbitantly way too much data or knowledge for one engineer to consume. But if you can plan your builds for containers or images and get things like that in place with the right team leads, a lot of this comes together as an affect where they are working within a very specific, still flexible. You can still achieve the future and growth with customers that you need. But at least the infrastructure around them is really secure. 

    And a quick data point that I have because I’ve been through I think two or three SOC that I’ve looked at the secure control framework, 70 percent to 75 percent of SOC 2 audits are about the infrastructure controls. It actually doesn’t directly deal with the codes that the developers are producing for the actual app. And I feel like within the industry, if that understanding were more common and the DevOps team really supported and they had the right tools for secured builds and really making sure they could see things before going to production that were insecure at that layer around the perimeter and with user access, I feel like most of these issues around certification and compliance, there are baselines, would actually be met more consistently.

    So I feel like there’s also kind of a challenge right now of a lot of people look at those product engineers as that’s the source. Those are the people with the root cause answer. They are the ones coating the solution. But the truth is, it’s your infrastructure team in the Cloud. And that’s really something that I’ve seen on premise a little bit different. But it’s still the same statement. You’ve still got networks and IP and ports and perimeters to control. So I just feel like the infrastructure piece of this is typically left out and then it becomes, unfortunately for many companies, the tech debt when they start looking. 

    And I’ve coined this phrase recently, I’m calling it, it’s not a moment of realization. It’s becoming a moment of terror because when you do get the right tools and you can see it, everyone steps back and says I had no idea this is what we had built. And it takes a lot of fortitude to walk through that backlog, that tech debt.

    Alan Shimel: Does anybody want to comment on that?

    David Kirsch: Well, yeah. I had the same feeling that you do, Alan, about dev sec ops and we are going to have these amazing – there are a lot of amazing developers, developers who know everything there is about security. Everything there is about operations. Everything there is about compliance. It’s not realistic.

    So instead, part of it is, I think, building guardrails. So I’m sure Sonya is working on that. What sort of data are you going to allow your developers to put into the Cloud, for instance. Because at the end of the day, we’re talking about data often times in terms of compliance. So what kind of data are you going to allow in the Cloud or out of a certain region? When you’re testing applications, are you going to allow the testers to see all of the data? Probably. Probably not, I don’t think you want them to see all of your production data. What sort of role-based controls do you have in place? So setting those foundational guardrails, I think, is really important to keep the whole DevOps process clean and compliant.

    Alan Shimel: Okay. Go ahead.

    Tim Johnson: I would take that a little bit further back to the first principles of the – and this gets into culture, this gets into cooperation, this gets into silos, this gets into doing it all right is starting with a description. Can you describe your software delivery process? If you want to call it a value stream mapping exercise, call it that. But you get everybody in the room to describe how this software moves through the system then agree that’s how it’s done. And then agree on how to measure that. And then the final piece of the puzzle that I see overlooked way too often is that everybody’s compensation plans or bonus structures or measurements have to be aligned on that description of what that is. Because I’ve seen companies where the three different groups, we are all in on DevOps but the engineers are doing things differently and the security folks are doing differently and the DevOps teams are doing differently because they are measured differently. They agree in principle to doing DevOps but because they are compensated this way and they are measured over here by something else and something else, they are never going to be as successful as they are. So if you want to make this whole process as friction-free as possible, get everybody to agree and one of the things we’ve always seen in these value stream mapping exercises is somebody says and this happens and then somebody else immediately jumps in and says actually, no, that’s not how it works. And you have to get those out of the way because that’s going to come back to compliance. Well, it doesn’t work that way. Well, then how can we be compliant and so forth. Anna, I think you wanted to jump in on that.

    Anna Murray: There’s so many things to talk about but when you guys talked, first Dan and then you, it comes back to culture. It comes back to leadership. And I think it reminds me of when we were making our transition from Waterfall to Agile. It’s this go faster, go faster, go faster. And there’s more emphasis on go more faster. Go faster, go faster. Wait, slow down. We actually go slower if we don’t do the right planning. And so there’s absolute proof that if you plan well, you will actually go faster. And part of that planning must include your security and your compliance. The plan is, you can go back to your Agile definition of done. This is done when. And part of the when is your security rules. It will pass these tests. It will go through these scanning tools. Whatever your definition of done is, that’s how you make DevOps help you with compliance is you first start with the right plan. And that only happens if you have cultural leadership. And like Tim said, you get everybody in the room and you agree.

    And so it is a big challenge and I think more than anything it comes back to leadership because the people who built software love building software. They love writing code. They love delivering bug free software. That’s how they get their value for themselves of what I do every day in my life. If I deliver code that gets hacked, that puts my company on the news, I’m not very happy with myself.

    So when you think about it, leadership can put things in place and help teams go where they need to go while leaving the guard rails in. But if the leaders are not on board, you end up with this fracturing that Tim is describing.

    Alan Shimel: So to me what we are describing here, though, is quality. No one wants to produce shoddy work whether it’s secure, insecure compliance, really, we’ve really strove in security to make security synonymous with quality. If you are delivering a quality product, and whether that’s software or a guitar or whatever it is you’re selling, you want to deliver quality.

    For many – and I’m going to put forth this. For many developers and even testers, quite frankly, and folks, other folks in the software development lifecycle, security and certainly compliance are not quite synonymous with quality. Security is other to them and compliance is other’s little brother. But it’s not quality. It’s not quality. And I think that again, that’s one of the promises of DevOps is making that quality.

    I’ll throw just something else out here because it’s at the heart of DevOps and kind of this whole way of looking at things. Infrastructure is code. You know Sonya, you made an excellent point that if you set your infrastructure up right, compliance almost does become automated and easy because so much of your compliance is based on that infrastructure.

    But in the world where infrastructure is code, is code, not as code, is code, that can be changed, that can be duplicated, that can be cloned. When I first started devopsy.kinsta.cloud, puppet and chef ruled, Britannia ruled the waves because you can create that same instance over and over, that same configuration, that gold config that was rigid, it was secure, gave me compliance. That was one of the big benefits here.

    Sonya Lowrence: Absolutely. I feel like that’s why it ties back in now, like at this point in the conversation, naturally to a tenant of a privacy that is becoming more and more standard in many countries. That’s security by design is the expectation. In the world of Cloud, some of that challenges, you’ve got a lot of options and not everyone understands on that front how to build it securely. There is still a lot of base designs out there that don’t necessarily have the configuration controls that maybe they could or should. That’s debatable. But I feel like that’s the challenge here is there’s a huge explosion of growth in Cloud environments and the engineers who understand the secure tenants, architects who know how to build it consistently to those standards are lagging a bit. They are learning, too, as we go. 

    So I feel like again that’s why these tools, and going back to the understanding that if you were to look at that process like you mentioned, Tim, it’s really important to understand the SDLC. And I recently did this just for a dec. A very simple here’s how many times you have to touch code or infrastructure if you put this up at the front in a beautiful DevOps environment and approach, it’s one hand off and then your security team, ideally, is watching for vulnerabilities. But the truth is, I think most companies end up touching code or infrastructure 10 to 12 times before they see the vulnerabilities to deal with them. 

    So I feel like the more we can find the right tools to actually put this up front or working with the architects or leads to really build out that future state environment and build these automation points, we will continue to see this challenge. And it is very, very challenging for any one developer to account for all of that. These are many layers of expertise that we are touching on today.

    Alan Shimel: Absolutely.

    Tim Johnson: One of the things, Alan, I saw a statistic last week and I apologize, I can’t remember the source. But to your comment about infrastructure is code and repeatability and we can get into the concept of immutable objects and the pipeline and all that other stuff. There is a potential fallacy or vulnerability there because yes, you were starting with that. You are using this approved component and its repeatable. But the statistics said that only half of the controls from a regulatory standpoint actually covered infrastructure is code. So there were other things that were happening that your IAC solution or methodology or component wasn’t going to see. So that’s – okay, you started well. Did you continue well and did you end well is kind of the thing that you have to kind of keep along and keep in mind as you go through that.

    Alan Shimel: I don’t disagree. Mitchell, you’ve been letting people talk today. I’m interested in your thoughts.

    Mitch Ashley: Absolutely. You’ve got a great panel. It was just thinking about several things. One thing Anna said was talking about culture and leadership. And I’ve learned the hard way. Automation does not fix culture. One of the toughest things –

    Alan Shimel: You can’t automate culture?

    Mitch Ashley: No. I mean, automation doesn’t solve your culture problem. And one of the hardest things to do is to try to automate across silos. That’s something nearly impossible and you’ll end up with a mess. And so I think we kind of have to shed a little bit of the paradigms of thinking of these as fixed objects. Compliance is not fixed. It’s constantly changing more quickly. Tim and I know this from some of our research together. DevOps is speeding up things, Agile is speeding up things. We are changing our toolchain. So it’s almost like instead of thinking about we are building a highway, it’s like we are trying to do compliance for something that’s constantly in motion, that is flowing by like a river. And so we have to be really good at things like understanding the changes that are happening and understanding the data that might be helpful. Maybe it’s not the panacea that solves all of our problems. The data that we are already throwing off or can capture as part of our software development process. And understanding the tool changes and I think configurations are going to change that whether it’s infrastructure’s code or we plug in a different tool. And that’s kind of the mindset we need to adopt whether it’s compliance, security or DevOps and software.

    Alan Shimel: Yeah. Might very well be. Let me defend the common man developer, common man or woman developer. As a security person, I fancy myself a security person. I am bewildered and befuddled by the amount of compliance regulations that are out there, depending where I am, who I’m talking to and what I’m doing. How can we honestly, earnestly, expect the developer to untangle this mess?

    I’m reminded when politicians hold up those big – these are the regulations we cut this year. And they slam down this big fat book of regulations. The regulations never go away. How is a developer supposed to make heads or tails of this, though? Or maybe they shouldn’t and that’s DevOps job?

    David Kirsch: Yeah, I mean that’s really the job of different tools and platforms because you have to codify those compliance, those huge documents that what are the 1500 actual requirements? What is Regulation 43BC Subsection R? What does that actually mean? And that means you’ve got to check this little thing of code. And so that’s got to be automated into the platforms to make it easier because it’s just unrealistic to expect developers to understand it but they are not paid to care about it. They are paid to put out really high quality software. And that’s what you’re paying them for.

    Tim Johnson: A lot of money.

    David Kirsch: You’re paying people like Sonya to figure out the compliance problems and you want the developers to put out often software.

    Alan Shimel: But you know what? Anna, Tim, that sounds like your job. You guys got to be making products that do that. How do you do it?

    Tim Johnson: I’m very difficultly avoiding a commercial for the products I’m associated with right now.

    [Laughter] 

    Tim Johnson: There’s other aspects to this which you haven’t really talked about is the context of it, of whatever issue that you find. And just what the heck is the programmer or developer supposed to do about it? So there’s any number of securities scanning tools, stass, yast, blast, bast, cast, whatever. And they all come back with this storm of alerts. There’s scary things happening. Developers are what the heck do I do about it? The compliance officer, like my colleague here, Sonya, says what the heck does this mean? Because it’s just as challenging for the compliance officers and security people as it is for the developers. And you use Bob’s software that has some AI magic that says we determined this is a threat level of 563. What does that mean? And some other Joe’s software says oh, that’s a threat level of 12. And things like that. So when you discover this, what does it mean and what does the context of what it is that we are doing? So you look at things like where is this in the lifecycle? Yeah, it’s an open connection to the Internet but this environment is a test environment. It has no connection to the Internet whatsoever. So do we need to panic about this? No. If it’s in production, obviously, yes. But it should never get there in the first place.

    But also, you’ve got this issue, you’ve got to be able to feed it back to the developer in the tools that they want to work with in a way that they can do something with it. So they don’t necessarily have to understand you’re not compliant with this particular control of CIS 12, you can speak Urdu or Phoenician to them. You get better results. Here’s this thing, here’s what’s wrong. Here’s how you fix it. Go do it.

    Alan Shimel: Anna, what about you?

    Anna Murray: I echo what Tim says. It has to be clearly defined back to the developer where is there a hole? We recently were looking at something ourselves that we had found a problem and okay, wait. Does it affect this – doesn’t even matter? First you have to evaluate it. And it does matter, most of the time, but you have to have your architects in play. Your architects, as Sonya said, she doesn’t even meet with some titles called architect. If you don’t have somebody in that level, you don’t have anybody you can look at the whole product and say what the threat level is because of your product and what it’s meant for. And the access that can be to that software for it to cause a problem.

    So that’s where you really have to have those people that are at the architect level, whether that’s their title or not, and they are interfacing with your compliance people and understanding the things that need to be architected in and you have to have standards. You have to have them codified into your tools. And we are scanning and we choose to use this solution from CloudBees or that solution from Rocket. And we’re going to make sure that we meet this threat level that’s defined by that product and then your compliance people review it and decide whether it’s good enough or not. And if not, up your game. But automate it, give the reports back and you better hope those reports, as Tim said, tell the developer what’s going on. Because really, these things change all the time. And developers are good at writing code and making software work and they can make it work the way we wanted to given the requirements. But that comes back to giving them clear requirements. We cannot ask them to do more than that. We want them to be creative, building whatever it is that they are building and we give them requirements to fit. And if we’re not doing that from leadership and architect and compliance, then we are failing, not them.

    Sonya Lowrence: I completely agree. And I would like to add to that. For me, I have seen some organizations where compliance will walk into any design meeting and say here’s my list of 200 requirements and regulations or whatever their source is for their input. And I really would challenge any security or compliance professional, especially in a leadership role, to really think in terms of make it simple. Make it accessible. It is not hard for developers to understand. Data is what we are protecting. It’s kind of like you’re building a fortress around your gold as a dragon. And from there, think about in terms of what you are protecting. It’s the perimeter. It’s who has access to it. It’s principles of least privilege.

    And so I feel like approaching the development team to help them come up to speed and not terrify them with too many details is the right way to go. And it just changes the culture. It shifts naturally because they do understand these principles and they do want to deliver quality code that doesn’t have these types of issues both for security and for compliance. So I feel like there’s definitely a lot of improvement in this space for training, too. Really explaining as you go why it matters and then making sure you’re working at the right level, finding those leaders on the engineering side to partner with.

    Alan Shimel: Training around – I’m sorry, go ahead, Tim.

    Tim Johnson: Well, I was going to jump back in. On that standpoint, we’re talking about the developers, we’re talking about a number of people. But part of this equation is the leadership of the organization. And you talked about, Alan, you talked about quality. And is quality enough of an incentive for upper management to really get behind compliance efforts and security efforts. And I would argue that no, it’s not. Typically, it’s kind of nice to have. And I remember statistically, from a couple years ago where managers have said they’d rather go fast than secure. This was only like three or four years ago. That’s scary. I hope it’s changed.

    But one of the things in talking with some of our customers and prospects in the last six or seven months is the concept of a tax, the compliance tax. One customer actually used that phrase. And we go back to this bank that I mentioned earlier. It’s 100 people year-round devoted to doing that. What is your fully burdened cost of that labor to do zero value add work? Right? Compliance is something you have to have but it doesn’t add any value to the organization whatsoever until you don’t have it in a big way. Then it takes a lot of value on. But that’s kind of funny money because you’re going to pay them anyway.

    But if you also add in the concept of what should they be doing in terms of technical debt or the opportunity cost of them spending this time on zero value at work versus value add, so you take that fully burdened cost, what are the expected returns? So if your fully burdened cost is $100,000, I think the company wants you to generate more than $100,000 in value in a year. Maybe it’s $200,000. Maybe it’s a total revenue divided by total employees. Some figure that’s more than what you are paying them for. And you add that into the equation of these 100 people doing this work. That’s the labor costs. Then here’s what we are missing. Here’s the value to the organization we are missing from that. Then you get a much more comprehensive picture of the true cost to the organization and how to justify the efforts of changing culture, doing those meetings that nobody wants to go to and putting in different metrics and things like that because you have an measurable impact that you can have on the organization. It’s like a snapshot on day one and then six months later, you halve the people doing compliance. You’ve got a defendable metric to take to senior management and say this is what we’re doing.

    Alan Shimel: I mean, being able to actually show compliance is, it’s a little different than being able to actually show security where if you did good, no one knows because that means you didn’t have an incident. But with compliance, you can say hey, look. I’m compliant with SOC. I’m compliant with PCI, whatever it is, GDP or whatever you are compliant with. And you can hold that up.

    Anyway, team, panel. We are over time here. I knew this was going to be one of those sessions where we ran over. And for me, it’s a very volatile subject. Sonya, as the true compliance person, not making a product around compliance or anything like that but really where the rubber meets the road, I was going to give you the last word today on today’s show to leave with our audience in leaving with compliance and DevOps.

    Sonya Lowrence: Yeah, absolutely. I think just to summarize a lot of what I’ve heard here today and what I’m trying to really make sure we are influencing here at Tricentis, you know that true realization that along with leadership, compliance is an absolutely important part of the team. And when done well and when done from the right approach is whatever tools you’re working from. You start with what you have, you identify the challenges and you get better. A lot of this boils down to knowing your requirements, following a pretty classic Deming cycle: plan, do, check, act. And I feel like those tenants really have never changed. I just hope that more organizations really start to add this back in within Agile development environments that we all have. So I think it’s very achievable and the tools are catching up quickly to get us there.

    Alan Shimel: Excellent. Well, Tim, Dan, Anna, Sonya, Mitchell, thanks for being on our panel in this episode of DevOps Unbound. We’ll be back, as I mentioned, every other week so in another week or another two weeks we will be back with a fresh panel and a fresh subject and something DevOps related. But until then, many thanks to Tricentis for your sponsorship. Many thanks to you out there watching this. We appreciate your time that you set aside to watch this. And we are grateful for it.

    Until then, though, this is Alan Shimel for Techstrong TV, DevOps Unbound. Have a great day, everyone.

  • Free Dev Tools! But What’s the Catch?

    Free Dev Tools! But What’s the Catch?

    Software companies, especially young startups, are always in a development race – by definition, they are trying to maximize achievements and minimize their burn rate. That means development teams naturally face an internal tug-of-war. On one hand, they seek to use the newest dev tools that the market can offer, targeting their applications to become better (more secure, more efficient and compliant with the latest standards). On the other hand, they cannot spend money on such tools since they need to save every penny. With the current economic climate, many new investments are being delayed or, at minimum, double-checked. 

    To appeal to developers, many vendors and software development tool companies offer freemium programs. Some are driven by the spirit and the goodwill of open source and community; others are business-to-developer (B2D) companies relying on the product-led growth (PLG) mode. If developers see value in the free tools, they are more likely to become paying customers later on to get access to more features.

    Here, we’ll review the common parameters of popular free developer tools and distinguish their services between the free tier (aka the community tier), the entry-level paid tier and other paid program offerings. We’ll look at tools for observability, logging, vulnerability scanning, compliance, authentication and VPNs.

    1. Volume Threshold

    Logs are considered to be one of the three pillars of observability and are the bread and butter of troubleshooting and debugging. The more code lines you have in your product, the more loglines you collect, store and aggregate. Logs accumulation can quickly get out of hand and become very heavy on the budget. One logs aggregation vendor, Sumologic, provides a freemium offer that allows log collection up to one gigabyte per day. If you need more volume, you can move to their paid tier that allows for higher volumes or pay more for no limits at all.

    2. Transactions Threshold 

    Transactions and tests are probably the most imperative features of a freemium offer. It involves the core offering with a quantity limitation, giving you a chance to try the product through practical use, but you’ll probably have to move up quickly into the first paid tier. Snyk.io, for example, will help you scan your open source software for flaws alongside container vulnerabilities as early as code creation, with up to 200 open source tests and 100 container tests per month.

    3. Certified: Security and Compliance 

    It’s one thing to play with, say, a free AutoCAD seat that doesn’t involve sensitive data and another thing entirely to draft the next-generation design that must not leak to your competitors. Security and compliance certification is often included in the freemium tiers; more detailed reports and analysis of security and compliance are for the paying tiers only.

    4. Availability and SLA Support 

    Having a free tool is great–but if this tool is bound to a proprietary service, then you should probably demand these tools meet the same standards and SLAs that you are offering your customers. Observability platform Rookout offers 24/7 support and dedicated account managers and tools for enterprise customers in all tiers.

    5. Legal Aspects 

    One key aspect of free tiers is the legal aspect of using the tool. The dev tool may interact with sensitive data, not only in your own dev environment but also with your customers’ environments. Your customers may require your dev operations to meet specific criteria, making the free tier a potential legal issue. For example, if you use the free tier of JFrog to manage your supply chain, you won’t be able to use Artifactory to publish data to third parties; should you want to do that, you will have to move to one of the paid commercial programs.

    6. Usage Threshold

    Some free tools operate based on a usage model—you are entitled to a free tier until a certain amount of users or actions is reached. Auth0, for example, a user authentication solution (now part of Okta), provides their service free of charge for up to 7,000 users (generous!) but should you grow beyond that, you’ll need to graduate to a paid tier and be charged according to your monthly usage.

    7. Speed Threshold

    Some free and freemium offerings are tempered based on connectivity speed, bandwidth and even VPN. Today, you can even get a secure VPN for free, but only to a specific threshold. For example, ProtonVPN will provide you with a free VPN at a medium speed, if you move to the highest speed VPN, you’ll need to move to a paid tier.

    In most cases, the freemium tier will limit a dev tool’s usage according to one or a few main characteristics but will allow you to perform the basic actions and enjoy the essence of the tool. Some parameters may be trivial, like volume of tests, while others require developers and DevOps teams to carefully monitor usage. There’s a lot of value in free and freemium dev tools—but make sure you read the fine print.

  • Myth Busting: 5 Misconceptions About FinOps

    Myth Busting: 5 Misconceptions About FinOps

    Over the years, moves to the cloud have happened in several different ways and at various speeds. The reality is that today most enterprises are spending massive amounts on their cloud environments, and many teams are struggling to contend with the governance implications of this reality.

    Fundamentally, teams struggle with an either-or proposition: Either they give development and engineering teams free rein in terms of how they use cloud models, and, in the process, they leave the business exposed to a wide range of risks or they try to enforce central controls and restrictions on cloud usage and, in the process, stifle speed, flexibility and innovation.

    FinOps is a Necessary Discipline

    Teams are struggling with cloud governance in general, and one particularly vexing aspect of governance relates to cloud cost management. Quite simply, the procurement models and approaches that worked in the days of on-premises data centers simply don’t cut it today. At all.

    For these reasons, FinOps is emerging as a necessary discipline. At its root, FinOps is about establishing the people, process, and technology for establishing financial accountability in pay-as-you-go cloud environments.

    Here’s how the FinOps Foundation defines it:

    “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.”

    Recently, I started preparing for the FinOps certification, and in the process, I have had the chance to talk with quite a few practitioners. Along the way, I’ve heard several misconceptions about the discipline. I’ll list and dispel a few of the most common myths in the following sections.

    Myth: FinOps is a Buzzword, not a Discipline
    While the term may still be new to some, the need for FinOps is clear, real, and not going anywhere. Consider that in a survey of more than 800 professionals, the FinOps Foundation found FinOps team sizes grew 75% in the last 12 months, and respondents are expecting 50% more growth in the next year. Today, the FinOps Foundation has more than 5,300 members. Further, on any given day, a search on career sites for roles specifically referencing FinOps will typically yield hundreds of opportunities.

    Myth: The Sole Goal of FinOps is Saving Money
    More than just tracking and controlling spending, FinOps offers a way to optimize spending, so each dollar invested ultimately yields the most business value. Rather than simply helping save money, FinOps is about making money.
    FinOps teams should advocate and lead with value-based discussions rather than focusing on cost. For example, if additional spending on a certain cloud service increases marginal value, FinOps teams help justify that additional investment.
    FinOps helps teams reduce wasted spending, but it also enables teams to invest more in services that allow the business to innovate, adapt, and scale. Ultimately, it offers teams a way to capitalize more fully on the advantages of cloud pricing models.

    Myth: FinOps Teams are Responsible for FinOps
    To be successful, organizations need to build a central FinOps team. These teams establish guidelines and best practices and facilitate unified reporting and visibility. However, FinOps doesn’t start and end with a single team.

    Those that succeed with FinOps are the ones that effectively break down silos. Individuals from leadership, finance, operations, development, and more all have a role to play. In a FinOps-driven organization, a range of teams collaborate, and in the process, they all benefit. For example, development teams can innovate more quickly and make more intelligent, data-driven decisions around balancing speed, quality, and cost.

    Through FinOps, everyone takes ownership of cloud usage. Cross-functional teams work together to establish more effective management of cloud vendors and rates. Ultimately, rather than creating conflict, friction is reduced. The end goal is to establish alignment around business objectives.

    Myth: FinOps Teams Stifle Innovation

    With traditional procurement models, central teams retained visibility and control over expenditures. While this would add layers of time and effort to purchases, this was accepted as a worthwhile tradeoff.

    Part of the reason for FinOps has come into existence is that it enables teams to break away from the rigid, centrally controlled procurement models that used to be the norm.

    Rather than having a finance team that acts as a central gatekeeper and bottleneck, FinOps enables teams to fully leverage opportunities available for automation in the cloud. Compared to rigid, monthly, or quarterly budget cycles—and being blindsided by cost overruns long after the fact—teams move to continuous optimization.

    Real-time reporting and just-in-time processes are two of the core principles of FinOps. Fundamentally, FinOps is about removing obstacles, and the focus is on enabling development teams to speed up their ability to deliver new features and capabilities.

    In the cloud, the reality is that teams can spin up a cloud resource with the click of a mouse. FinOps is about bringing real-time visibility to teams so, along with this instant access, there can also be informed decision making and ultimately accountability—all while fostering agility.

    Myth: FinOps is Only for the Largest Enterprises With the Biggest Cloud Budgets

    Clearly, the larger the business’ cloud investments, the larger the stakes. In addition, the larger investments, the bigger the problems that silos between technology, finance, and procurement can create.

    The goal for FinOps is to establish the people, processes, and technologies that enable more intelligent decisions about cloud investments. Ultimately, FinOps enables teams to ensure that each dollar spent in the cloud is delivering the most business value. Given that context, it is clear FinOps is invaluable for any organization making investments in cloud services. This is particularly true as organizations become more reliant on more cloud vendors and service types and more internal teams begin to access services.

    Establishing a strong FinOps practice can support growth in cloud investments while equipping teams to ensure better those bigger investments will yield maximum business value.

    In my experience, it seems that most organizations take on the creation of a FinOps practice after encountering significant issues, such as massive cost overruns or major snafus that impede operations. It is far better to make this move proactively before issues and obstacles arise. Further, the sooner the move is made, the sooner the business benefits.

    Conclusion

    As organizations’ investments in cloud services continue to grow, FinOps is becoming an increasingly vital discipline. FinOps offers teams a way to make more informed cloud investments and ultimately ensure those investments yield maximum business value. Consequently, FinOps represents a key aspect of cloud governance, which also requires teams to ensure security, compliance, and operational policies are constantly adhered to.

  • 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.

  • Self-Service Helps Devs Solve Cloud Security and Compliance

    Self-Service Helps Devs Solve Cloud Security and Compliance

    Organizations that need compliance must follow a growing number of security standards—PCI, HIPAA, SOC 2 and GDPR just to name a few. Every new standard gives rise to an exhaustive list of hard-to-implement security controls.

    Cloud providers like AWS have tried to help, but there is still a lot left for developers to do to secure their infrastructure. Cloud providers give you the raw materials necessary to remain compliant, but you’ll have to learn how to use them.

    It may be easier to envision the scale of the compliance challenge by working through an example. PCI DSS is a typical security standard. When moving to the cloud, you’ll have to figure out how to take your compliant infrastructure and implement it using cloud technologies.

    PCI has several requirements regarding network architecture and firewall barriers. For example, specification 1.1.4 calls for a “firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.”

    Segmentation is the goal. Your network can’t allow traffic to move freely to wherever it wants. You need to set up rules and carefully guard sensitive areas of the system.

    In AWS, we’d suggest implementing this requirement using a mixture of services. Testing, staging and production regions of your application should each be in their own VPC. You’ll also need intelligent use of Security Groups, identity and access management (IAM) and instance profiles. Lock everything down and only open the necessary ports. A web application firewall (WAF) should protect the perimeter.

    IaaS services like RDS and Elasticsearch should be isolated via security group. Platform services like Dynamo, S3, SQS and Secrets Manager should be isolated via IAM. Lambda has one leg in the security group and another in IAM.

    PCI control 6.1 states that you must have a mechanism in place to identify security vulnerabilities within your compliant systems. How can you accomplish this in AWS?

    Automation is your best friend in application security. As the speed of development increases, security must keep up. And while there will always be a place for humans to dig into applications through penetration testing to find tricky vulnerabilities, automation will help you find the low-hanging fruit.

    AWS Inspector is an API-based service that will proactively scan and assess your application for vulnerabilities and warn you about them. This is an automatic process once it is set up, but it requires an administrator to choose what to test.

    Other tools exist to automate application security, such as Wazuh. As with AWS Inspector, there is effort involved in setting it up, initially. But once you complete the configuration, you’ll have a constant security scan running to find vulnerabilities before they reach production. And should some slip in, the scans will continue to search and find vulnerabilities before attackers exploit them.

    PCI Requirement 7 states that you must “restrict access to cardholder data by business need to know.” You’ll need to know who has access to what within your application and when they can access it.

    Restricting access in a cloud environment can be challenging because you require administrators to configure the services that your application needs to work. How can you limit access while allowing the admins to do their jobs?

    Orchestrating access control will require careful use of AWS Security Groups, IAM and federated tokens. Give your admins a token for access that expires quickly. Whitelist trusted IPs for access only to the areas of your environment that are necessary for the user’s role.

    The whitelist of IPs and the security groups will need to be kept up-to-date to make sure no holes open when personnel changes. Keep a tight grip on access control in your cloud environment.

    PCI Requirement 10 outlines the need to track and monitor all access to network resources and cardholder data. As your cloud environment grows, you’ll need more help to keep tabs on changes and user activity.

    AWS CloudTrail can be used to track user activity and API usage. But you’ll have to make sure that CloudTrail can’t be disabled without your knowledge to hide someone’s illicit activity. AWS IAM and Config services can be used to make sure CloudTrail can’t be disabled and to alert you if it is.

    CloudTrail can cover user activity, but what about infrastructure changes? You may need to bring in another tool, such as ELK, to track changes to your infrastructure. You can then marry the data from CloudTrail and ELK into a single SIEM for dashboarding.

    From this example and just these few requirements, you can see that the cloud is not a “push-button” solution.

    And this is only one example. Remaining compliant with SOC 2, HIPAA, GDPR, NIST and a host of other standards will require the same careful planning and execution.

    Planning for Compliance

    First, your team must stitch together many different software tools that help with compliance. Second, you must run periodic scans on your infrastructure and security controls after you provision your resources which essentially place Band-Aids on top of the holes you’ve created. Instead, applying controls during the provisioning process places a secure foundation under your developers’ code.

    DevOps teams try to maintain control over infrastructure and application deployment processes to avoid any mistakes from developers. Suddenly, developing software in the cloud begins to look the same as developing on-premises—delays, disappointment and frustration.

    Three things lead to successful cloud compliance:

    1. Careful planning and execution
    2. Automation to provision the necessary controls while you build your infrastructure
    3. Ongoing maintenance to adapt to changing regulations and standards

    You can help developers unlock the power and agility of cloud development while remaining compliant. But you must enable self-service for them as much as possible while maintaining security and compliance. The only way is to give them control of doing things they want while hiding low-level details that can get them in trouble.

  • 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.