Tag: development workloads

  • Generative AI: The 90% Rule

    Generative AI: The 90% Rule

    There is a concept we need to solidify that I will call the 90% Rule—until someone smarter than me comes up with a better name. The 90% Rule is simple: Generative AI will be able to do 90% of the work in areas that it is good at. Right now, that would be writing, but coming up soon will be image generation and coding and, not too long after that, video generation. For those of you buried in the space who are offended, I’m not rating it as advanced as it is for specialists; the point of generative AI is not to let AI specialists do things, but to let average people in the space do so. And that list is representative of the current space.

    This is just based upon the state of things at the moment I wrote this blog, but that seems to be the immediate order. I’m only talking generative AI here—AI for things like filtering test results is a completely different beast (that might just meet that 90% rule … Hmmm). I can tell generative AI to write a story, a script or code for me, and tweak the results. The amount of tweaking certainly depends on the topic and how much time I spent zeroing it in, but 90% seems right. There are those looking far ahead to a time that will herald the arrival of our AI overlords, but for the foreseeable future, we will not be ditching authors, coders and ops people. Our jobs will just change.

    Crikey—given the last few decades, a change to our jobs that means less work is not a terrible thing. Today, writers have to be publishers and marketers, coders have to be ops and ops have to be coders and the entire group has increasingly had to be security and architecture specialists, too.

    Let’s celebrate a tool that says, “Here’s a start, make it useful in your specific situation.” I know I will. I sometimes contract people to do initial research for me and send me links and short descriptions. I encourage them to use generative AI to do so. I do not contract people with my level of knowledge for this work, so they’re going to have things I need to read carefully and follow the links for—they’re not specialists, after all. Generative AI suffers from this syndrome, too, but that means there is no difference for me and they can work smarter, not harder. It’s not like they are writing content; merely providing introductory research through a scan of web properties.

    As time goes on, I expect they will become specialists. But not in the things I pay them to research—in making generative AI do what they want. I would argue the person I contract with the most often is better than me at it, just because she’s doing it regularly. That skill set will inevitably be transferrable, and I may lose her to a full-time position making the I in generative AI actually mean something, and I’m great with that. Meanwhile, I’m getting the background info I need to do my job(s).

    Embrace it. Aim for 90%. Turn out even more rockstar-level apps for the org, and maintain them with less effort. This is where we’re headed, and it’s entirely possible you’ll be less buried in work for some of that time. Win/win. Go out and enjoy. The business will thank you for being even more productive … then waste that extra time you created by implementing new projects. But that’s in the future; use AI in the short term to get some breathing room and still be the force behind the apps.

  • How to Foster Collaboration Between DevOps and Security

    How to Foster Collaboration Between DevOps and Security

    DevOps is on the rise. Back in 2018, MarketsandMarkets wrote that it expected the DevOps market to grow to $10.31 billion by 2023. That’s up from $2.90 billion in 2017, with a compound annual growth rate (CAGR) at 24.7% projected for the forecast period. Demand for DevOps solutions and services in response to the need for fast application delivery capabilities would likely help to drive this increase.

    Even so, security issues are introducing some challenges for organizations. A study conducted by the Enterprise Strategy Group and commissioned by Synopsys Inc. found that 48% of respondents had knowingly pushed out vulnerable code into production due to time pressures. Patrick Carey, product marketing director for the Synopsys Software Integrity Group, noted that about half of those respondents had done so “because the vulnerabilities identified were discovered too late in the [development] cycle to resolve them in time.” Such weaknesses elevate the risk of a data breach, and they potentially carry reputational costs for organizations that don’t plug those gaps before they release their products into production.

    These findings beg the question: Why are organizations struggling with their security efforts for DevOps? What’s not working for them?

    This blog post will explore these questions in terms of a cultural divide that exists between DevOps and security teams. After exploring where each team is coming from, this blog post will provide recommendations on how organizations can work to foster cooperation between their security personnel and DevOps teams.

    The Great Divide: Understanding the Issue

    The cultural divide alluded to above boils down to a false understanding of security and its impact on the development process. DevOps personnel are required to work within short development cycles to meet their employers’ evolving business needs. Subsequently, some organizations might interpret security as an opponent to their developers’ speed and respond by sacrificing security for the sake of speed. This decision enables misconfigurations, vulnerabilities and other security weaknesses to make their way into production.

    However, this interpretation overlooks an important reality: Many DevOps teams view security as a nuisance that gets in their way and slows down their work. Retroactive fixes ultimately take time and effort. In response, organizations might hold back on investing in the security of their DevOps processes, thus creating “technical debt” in the event that the work doesn’t get done.

    With that said, organizations have an incentive to rethink how they conceptualize security so that they can avoid these costs and keep their development processes running smoothly. But this raises an important question: How can organizations go about doing that?

    How to Balance DevOps and Security

    First, organizations should work to foster a culture of communication through which security personnel and DevOps team members can learn from one another. One solution to start with is having leaders from both teams “walking in the other team leader’s shoes,” thereby allowing them to share information and discuss their perspectives.

    Such communication will be effective only if personnel understand where the other side is coming from, however. That’s why organizations have an obligation to make their security policies and development workflows as understandable and implementable as possible. With this transparency, security and DevOps can begin to craft a way forward.

    Organizations can help out by encouraging both security teams and DevOps personnel to expand their knowledge. With respect to the former, security personnel have an interest in learning how to frame their message in the right language. It’s important to acknowledge that security teams can speak of potential security issues burdening projects with unexpected work and/or threatening operations’ availability with longer mean response times.

    Of course, security teams need to have a basic understanding of where developers and operations personnel are coming from. They can do this if organizations support them in learning about programming languages and how applications are developed. Subsequently, security personnel can use this knowledge to hold more credible discussions with their Devs and Ops counterparts as well as to properly configure their organizations’ Kubernetes.

    StackRox emphasizes the importance of administrators using automation to review their environments for possible misconfigurations:

    That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls.

    As far as DevOps personnel are concerned, training is key. Organizations should specifically consider training their DevOps teams in secure coding practices and educating their employees about attackers’ tactics. These individuals can then incorporate that knowledge into their coding practices and development processes. Additionally, organizations can uphold this security mindset among DevOps personnel by assigning security responsibilities to an individual on the DevOps team or to someone in a new position. They can then overlook security protocols among the DevOps personnel.

    Positive Focus Goes a Long Way

    The key to making security and DevOps teams work together is not taking their collaboration for granted. Like any relationship, organizations need to foster this cooperation by using positive focus and work to bring these two groups together. In that way, they can enjoy both the speed of DevOps as well as the security to stay safe against evolving digital threats.