devopsy.kinsta.cloud

Tag: open source

  • Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

    Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

    The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

    Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

    Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

    In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

    Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

    Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

    There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

  • Driving the DevOps Evolution: ArgoCD, Tekton and Seamless Migrations

    Driving the DevOps Evolution: ArgoCD, Tekton and Seamless Migrations

    The landscape of CI/CD frameworks has evolved over the last couple of years. From the early days of Flux and Jenkins to the current focus on ArgoCD, this journey reflects the industry’s momentum toward efficient and reliable deployments.

    In recent times, we have seen many modern software delivery platforms adopt ArgoCD or Flux for automating deployments within their ecosystems. However, as multi-cloud deployments and scalability still remain a challenge, we are seeing the industry shift toward more powerful Kubernetes-native frameworks like Tekton.

    Evolution of CI/CD Frameworks

    Flux: Paving the Way for GitOps

    Flux was one of the pioneers in promoting the GitOps methodology. It allowed developers to manage infrastructure and deployments declaratively through version-controlled manifests.

    GitOps, as introduced by Flux, emphasized the use of Git repositories as the single source of truth for configuration, making deployments more reliable and traceable.

    Jenkins: The CI/CD Workhorse

    With its extensibility and vast plugin ecosystem, Jenkins quickly became the go-to CI/CD solution for many organizations. While Jenkins was powerful, its complexity and challenges in maintaining pipelines led to the exploration of alternative solutions.

    Spinnaker: Scaling Deployments

    Spinnaker emerged as a powerful tool for continuous delivery with a focus on scalability and multi-cloud deployments.

    Its support for canary releases, blue-green deployments, and pipeline orchestration attracted organizations aiming for more sophisticated deployment strategies.

    ArgoCD: The Rise of GitOps

    ArgoCD brought a renewed focus on GitOps, building upon the foundation laid by Flux. It provided a declarative way to manage Kubernetes applications, ensuring that the desired state in the Git repository is continuously in sync with the cluster state.

    The adoption of ArgoCD has been widespread due to its simplicity, scalability and ability to synchronize with multiple clusters.

    ‘Modern’ DevOps Platforms: Riding the ArgoCD Wave

    Many ‘modern’ software delivery platforms have either incorporated or integrated separately with ArgoCD to attempt a complete software delivery approach. This integration enables users to adopt GitOps principles seamlessly within their existing workflows.

    Here’s a glimpse into what it looks like to work with ArgoCD on these platforms:

    1. First off, you will have to orchestrate CI separately, which leads to context switching and a non-unified CI/CD workflow. You will need to leverage plugins on most of these platforms and hop back and forth between exploring steps and adding them to your pipeline for a few others.
    2. For CD, it is essential for you to connect your ArgoCD instance by keying in the server URL. This requires a working understanding of ArgoCD and also a working setup of the same before even signing up to these DevOps platforms.
    3. ArgoCD has to be defined as an artifact source and its specific steps must be added as deployment steps while configuring a pipeline. Other platforms require you to include steps or commands within the YAML files to interact with ArgoCD.

    While GitOps automation can be achieved by integrating ArgoCD with DevOps platforms, it has to be noted that these are not native workflows. There will be challenges that crop up, like:

    1. Improper synchronisation between repository and the deployment state on these platforms could result in unintended deployments or configuration drift.
    2. GitOps practices, when coupled with certain platforms, may have limitations in handling multi-cloud or hybrid cloud deployments.
    3. The complexity increases with the size of the infrastructure. The larger the number of clusters and environments the greater the number of pipelines and messier the orchestration.
    4. The fact that ArgoCD needs to be set up and running before even subscribing to DevOps platforms defeats the purpose of having low-code/no-code DevOps.

    The Rise of Tekton

    As the industry looks for solutions to address the challenges posed by existing CI/CD frameworks, Tekton has emerged as a promising alternative. Prominent tech enthusiasts in the DevOps space, like CloudBees co-founder Sacha Labourey, and market momentum make it clear that there’s a significant number of organizations working on integrating Tekton within their platforms, just like we saw with ArgoCD a couple of years back.

    What’s amazing is we already had platforms like Ozone, which started working on making Tekton enterprise-ready almost three years back and have further evolved over the years.

    Tekton: Container-Native CI/CD

    Tekton is a Kubernetes-native framework for building CI/CD systems. It provides custom resources to define CI/CD pipelines as code, allowing for greater flexibility and extensibility.

    This is done by introducing the concept of tasks that run within a pipeline. These tasks are reusable and pre-defined, all of which can be viewed in the Tekton hub.

    What ArgoCD achieves for GitOps is done with just one of the hundreds of task templates that Tekton comes with.

    Too good to be true? Well, every rainbow has its rain! Migrating from one framework to another is a huge task, and that is precisely why many enterprises shy away from migration.

    Can LLMs Help Automate the Migration of Existing Pipelines to Tekton?

    If you look at the diagram below, the answer is a resounding yes. The model is trained based on existing pipelines and what their corresponding Tekton pipelines look like.

    The overarching objective of this workflow is to facilitate a seamless conversion process using large language models (LLM) for generative AI.

    Central to this approach is using the chat context and the strategic application of roles for LLM models to establish context. Additionally, sample pipelines are leveraged to train and fine-tune the model to define how the corresponding YAML files of all these platforms look for any given pipeline.

    Here’s a more detailed read presented by Ozone as an industry-first last year at KubeCon North America.

    Conclusion

    The evolution of CI/CD frameworks reflects the DevOps industry’s dynamic nature and the demand for efficient software delivery pipelines. From Flux and Jenkins to ArgoCD and Tekton, each framework addresses deployment challenges.

    ArgoCD gained traction based on its GitOps principles and Kubernetes integration, yet faces synchronization, multi-cloud support and scalability hurdles. Tekton, a Kubernetes-native CI/CD framework, offers scalability, event-driven architecture and cloud-native practices to make up for these shortcomings.

    Whether embracing ArgoCD or exploring Tekton, the goal is resilient, scalable pipelines driving innovation and time-to-market acceleration.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

  • The Practicalities of Open Sourcing

    The Practicalities of Open Sourcing

    I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

    Manage Your Expectations of External Contributions

    If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

    OSS can be Intimidating

    While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

    Issue Triage and the Support Price Tag

    In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

    The Need for a Private Mirror

    There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

    Saying Goodbye to Obscurity

    Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

    Unfriendly Dependencies

    If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

    Navigating the Ecosystem: Dealing With Dependency Upgrades

    Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

    Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

    Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

    Unexpected Benefits

    Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

    ● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

    ● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

    ● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

    ● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

    And that’s a wrap, folks. Best of luck with your open source journey!

  • Kobiton Open Sources Test Script Generation Tool

    Kobiton Open Sources Test Script Generation Tool

    Kobiton today announced it is open sourcing a script generation tool for the Appium automation framework that automates the running of test scripts.

    The overall goal is to make the tool, which makes it simpler to create more testing scripts, more widely available and, ultimately, lead to higher-quality applications being deployed.

    Kobiton CTO Frank Moyer said the tool makes it possible to generate tests from a test case that has been captured in a Node.js format. Rather than having to hire hundreds of testers to create those scripts manually, it’s now possible to automate those tasks using an open source tool, he added.

    On average, Kobiton claims the tool it developed can write a 30-step script in 10 minutes, whereas a manual approach could take as long as four hours to construct a similar test.

    Once created, those test scripts can automatically be executed using the Appium framework. The output from that tool can also be used on other testing platforms, including Sauce Labs, BrowserStack and LambdaTest or integrated with low-code testing platforms from Perfecto and Tricentis.

    It’s no secret that the quality of any given application tends to vary widely, not just between organizations but also within them. Most of those issues can be traced back to a lack of testing that usually occurs because there isn’t enough time. As deadlines near, one of the first places organizations look to make up for delays is the time available for testing. The hope is that whatever issues arise will be addressed via the next update. Of course, when the update falls behind schedule, the testing process is again cut back.

    Ideally, application development projects would not be allowed to go forward without adequate testing, but given business pressures, they often do. The only way to limit the impact of application development delays is to reduce the time required to create and run tests. The more automated that process becomes, the less time there will be spent on manually running routine tests. In fact, hopefully, there might even be enough time to run more complex tests to uncover issues that might adversely impact the user experience in ways no one might have otherwise considered.

    One way or another, the quality of the applications being deployed needs to improve if for no other reason than end users have options. Most end users will never give a mobile application a second chance if the initial experience doesn’t meet expectations. At the same time, application security regulations are only going to become more stringent. The tolerance for known vulnerabilities discovered after an application has been deployed is falling. Many organizations will find themselves subject to fines being levied simply because there was not enough adequate testing baked into the software supply chain.

    In fact, application security should, in the final analysis, be an element of a large quality assurance process that begins with adequate testing.

  • Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode today revealed it discovered a command injection vulnerability in the way the GitHub Actions continuous integration/continuous delivery (CI/CD) platform was used to update the open source Bazel project that many organizations employ to build and test software.

    The vulnerability, now remediated, could have been used to create a backdoor through which malicious code could have been inserted into a codebase that is managed by Google.

    Cycode researchers shared their discovery with Google, which has since updated the way it employs GitHub Actions to manage the Bazel codebase. Specifically, Google updated the base permissions to embrace least privilege principles to resolve the vulnerability discovered by Cycode.

    The vulnerability was discovered using RAVEN, an open source tool for scanning CI/CD platforms for vulnerabilities that Cycode makes available.

    Elad Pticha, senior security researcher for Cycode, said the vulnerability is the latest example of an instance of an open repository for building software that has been shown to be potentially vulnerable to an attack on a software supply chain that could theoretically impact any number of downstream applications and projects, including Kubernetes, Angular and platforms and services provided by Uber and LinkedIn.

    A Custom Actions capability that enables application development teams to create their own workflows presents any cybercriminal attempting to compromise of software supply chain with a tempting target, noted Pticha. A few changes to lines of code in a workflow can translate into thousands or even millions of lines of code, many of which an organization may never detect. Out of 3.4 million workflows examined by Cycode, nearly all (99%) make use of one or more Custom Action.

    Cycode has previously identified dozens of vulnerabilities in open source projects by mainly focusing on vulnerabilities within workflows. This latest research shows those vulnerabilities extend to indirect dependencies, such as Custom Actions, noted Pticha.

    Each DevOps team should review its own workflows for similar vulnerabilities at a time when more cybercriminals than ever are intent on compromising software supply chains. While many organizations have embraced DevSecOps workflows to improve application security, there is a natural tendency to overlook vulnerabilities that might exist in the workflows used to build and deploy software. The challenge is that DevSecOps workflows are still immature. A recent survey of 500 U.S. CISOs, AppSec directors and DevSecOps team members conducted by Cycode found 78% admitted application security attack surfaces are unmanageable, with 90% acknowledging relationships between their security and development teams need to improve.

    It’s not apparent if the vulnerability discovered by Cycode was actually ever exploited, but as most cybersecurity professionals know, if it can be imagined, someone has tried it. As such, any organization that uses Bazel might be well-advised to conduct a code review.

    In the meantime, it’s already apparent that regulations pertaining to securing software supply chains are only going to become more stringent in the months ahead. In the wake of the executive order from the Biden administration requiring federal agencies to lock down their software supply chains, it’s now only a matter of time before similar requirements are baked into legislation and various other regulations are implemented. The challenge and the opportunity now is to get ahead of this issue before a mandate with a hard deadline that can’t be ignored winds up disrupting the entire software development life cycle.

  • Hitting the Accelerator for Change: How Open Source Drives Software-Defined Cars

    Hitting the Accelerator for Change: How Open Source Drives Software-Defined Cars

    Every new car on the road today contains hundreds of millions of lines of code, and that’s a good thing because the technological functions they enable add greatly to the car’s ultimate value. For over 100 years, automotive consumers coveted cars because of their paintwork, their leather interiors and the speeds they can travel. But now, their real and perceived value is influenced by technology features. Technologies such as electric vehicles, self-driving and other software-defined services are what drive the value of the car—and it’s no longer too nerdy to describe cars as ‘software-defined.’

    Navigating the Road to the Future

    For car manufacturers and their suppliers, the challenges of the software-defined car are already very much in focus. Original equipment manufacturers (OEMs) have been hiring new workers and re-training existing ones to navigate these challenges, such as cybersecurity and connected technologies. Ten years ago, OEMs such as Renault and Volkswagen had few in-house software engineers. Fast forward to today, and both companies have numerous resources focusing on software.

    Software will soon become ever more central to the vehicles we drive, and that will soon drive us, as vehicles become more connected, autonomous, shared and electric (CASE). In the next few years, autonomous vehicles will soon be handling tens of terabytes of data per day, gathered by sensors such as LIDAR and cameras. Customers are increasingly expecting smartphone-esque features, which involves keeping pace with the very latest apps and technologies.

    Combined with features such as passenger entertainment systems and remote diagnostics, the requirement for software and processing power in vehicles is going to grow at an ever-increasing pace. Open-source software can provide automakers with the power to keep up.

    You Must Shift Gears

    Inevitably, these processing power requirements will require a seismic shift in the way OEMs work. Currently, OEMs are struggling to maintain existing systems‒while at the same time attempting to develop new platforms. It’s a hangover from years in which vehicles were not connected or had extremely basic connected services. This has led to a situation where it’s difficult to upgrade the software at pace due to the requirements and constraints of the hardware.

    There are lessons for car-makers in the smartphone world. Think about how a software update can be applied across multiple different smartphones. An iOS update works just as well across a new device or a device from four years ago. One iPhone will see multiple updates, adding new features and boosting security.

    For car manufacturers, this won’t be an easy shift: The industry needs more defined standards to allow an easier interface between hardware and software. The industry also needs to reconsider how it develops hardware and how this relates to software. These challenges will require a new way of thinking for car manufacturers as they transition to a world where time cycles are critical. I believe that cross-industry collaboration is needed to accelerate the development of autonomous vehicles.

    Keep an Eye on Moving Parts

    Complexity is building at an increasingly rapid pace in the car industry, and this shows no sign of slowing down. In a report on the industry, McKinsey noted that the average complexity of individual software projects in the automotive sector has grown by 300% over the last decade. By 2025, the number of lines of code in the average luxury car will have doubled from today’s figure of 100 million lines of code, according to a prediction by Volkswagen‒which is already more than a military aircraft like the F-35. In full-self-driving cars, the figure could potentially reach a billion lines of code, analysts believe.

    It’s not just the software that is becoming more complex, the hardware is too. Modern vehicles already have up to 150 Electronic Control Units (ECUs), often scattered through the vehicle, close to sensors. Increasingly, manufacturers are moving towards a model where these ECUs are combined and consolidated, connected by an ethernet network. As the amount of data vehicles deal with increases, it’s unlikely that all of this will be directly uploaded to cloud servers; instead, much of it will be processed inside the vehicle before ‘edited highlights’ are uploaded to the cloud for processing.

    This has important implications for vehicle maintenance and also poses cost issues. Car manufacturers face challenges when it comes to managing the ever-growing complexity of their systems while trying to keep annual recurring costs down.

    Watch the Hacker Threat

    The need for cybersecure vehicles is also growing, particularly as we see self-driving vehicles enter the fray. In 2015, two security experts showed off a hack where they were able to ‘switch off’ a Jeep driving at 70mph down an American highway. It marked the dawn of the ‘hackable’ car—although the seeds of this were sown decades earlier when the first ‘connected’ components were unveiled in the 80s and were not built to be resilient to hackers. A 2021 report on global automotive security was damning, saying, “There have been 110 Common Vulnerabilities and Exposures (CVEs) that year related to the automotive industry, 33 in 2020 alone compared to 24 in 2019.”

    Ultimately, the automotive industry faces increasing regulation in the face of these threats. As governments begin to regulate software within the automotive industry, those designing the products and software will become more accountable.

    Open Source and Safety … Always

    For car manufacturers, there are also important issues related to functional safety—unsurprising when you are dealing with a device that weighs a ton or more. This directly impacts software development, with additional costs for any system that has an impact on driver or passenger safety.

    Car manufacturers need to learn from the aviation industry, where systems related to safety are rigidly separated from those that are not, reducing costs due to compliance.

    It’s often difficult to reuse existing software in cars today, as it can require porting to a different configuration. Costs can rise, not in a linear fashion, but exponentially. How much money will it cost to write, implement and test 100 million lines of code ‒ or a billion? This is the challenge manufacturers are facing. When it comes to managing these costs, open source will become ever more important and not only will allow the reuse of existing software, but will enable other manufacturers to contribute to said software.

    Software-Defined Cars

    The future is rushing towards us at speed—and in it, cars are increasingly software-defined. In this future, open source offers OEMs a highly attractive solution to the considerable hurdles ahead, from safety issues to cybersecurity. Open source will unleash the power of the ambitions of the car industry—not just to compete with the tireless innovation of other industries, such as mobile, but to exceed it. For consumers, cars are already the most complex devices they own: and they could be the most innovative. The flexibility and scalability of open source will allow car-makers to free their imagination and create the innovative, software-driven car of the future.