devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Cycode Acquires Bearer to Extend ASPM Platform

    Cycode Acquires Bearer to Extend ASPM Platform

    Cycode today announced it had acquired Bearer, a provider of a set of tools for static application security testing (SAST), discovering application programming interfaces (APIs) and identifying sensitive data.

    The provider of an application security posture management platform (ASPM) plans to integrate the Bearer tools into its core platform to enable DevSecOps teams to further consolidate tooling.

    Cycode CEO Lior Levy said the acquisition of Bearer gives Cycode access to a set of tools that take advantage of generative artificial intelligence (AI) to surface suggestions that enable DevSecOps teams to more easily secure modern applications based on, for example, a microservices-based architecture.

    Bearer achieves that goal by continuously scanning for application security issues as developers are writing code, he added. Overall, Bearer claims its approach to scanning is 31% faster than rival tools while simultaneously leveraging tools such as Bearer Assist, currently in beta, to provide more context concerning the level of risk to the business any issue discovered actually represents.

    Those capabilities will be infused into the Risk Intelligence Graph (RIG) that Cycode developed for its ASPM platform.

    Cycode earlier this year added generative AI capabilities to its platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments. The company uses the generative AI platform created by OpenAI to provide a natural language interface for RIG. As part of that effort, Cycode is making available an executive dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

    The company is at the forefront of developing ASPM platforms that continuously ingest data to identify and assess application security risks. Those platforms also provide a foundation for consolidating many of the tools that DevSecOps teams currently rely on to secure applications before they are deployed in production environments.

    It’s not clear how quickly organizations are embracing DevSecOps best practices, but given the number of vulnerabilities that continue to be discovered, there is still much work to be done. The challenge is that legacy tools that lack AI capabilities were not designed to enable organizations to practically shift more responsibility left toward application development teams that typically don’t have a lot of cybersecurity expertise, noted Levy. AI makes it possible to now provide those teams with the context required to address application security issues as they write code versus just before applications are deployed, he added.

    In theory at least, the applications deployed today should be significantly more secure than previous generations of applications. In effect, IT environments are steadily becoming more secure. Less apparent, however, is the rate at which modern applications are being deployed to replace legacy applications that are, all too often, rife with known vulnerabilities that cybercriminals can easily exploit. Given the rate at which vulnerabilities can be discovered and patched in those legacy applications, it may take the better part of the rest of this decade to address those issues once and for all.

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

  • StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    ServiceNow, Hugging Face and NVIDIA have once again combined their efforts to advance a generative artificial intelligence (AI) platform that has been specifically trained to generate higher quality code than rival approaches based on general-purpose large language models (LLMs) such as ChatGPT.

    StarCoder2 is a family of LLMs created by the BigCode community led by ServiceNow. Three iterations are starting now with a 3 billion‑parameter model trained by ServiceNow; a 7 billion‑parameter model was trained by Hugging Face, while NVIDIA built a 15 billion‑parameter model.

    The 3 billion‑parameter model is capable of matching the performance of the original StarCoder 15 billion‑parameter model.

    Nicolas Chapados, vice president of research for ServiceNow, said as AI research continues to advance, each successive wave of LLMs becomes more efficient. Each organization, depending on the use case and total cost, can then opt to deploy StarCoder LLMs either on a local machine or in the cloud. The more parameters an LLM has, the more infrastructure resources are needed to run any inference engine based on it.

    The StarCoder2 LLMs were trained using 619 programming languages and can be extended to, for example, provide summarizations of code. The foundation of StarCoder2 is a new code dataset called The Stack v2 that is more than seven times larger than version 1 of the dataset. In addition, additional training has enabled the model to understand low‑resource programming languages such as COBOL, mathematics and program source code discussions. Organizations can also fine‑tune models with industry or organization‑specific data using open source tools such as the NVIDIA NeMo platform or Hugging Face transform reinforcement learning (TRL) techniques. StarCoder2 was built using data under license from the digital commons of Software Heritage hosted by Inria.

    The overall goal is to provide development teams with LLMs that, in addition to being less likely to hallucinate, also generates code with much fewer vulnerabilities because the code generated is based on exampled vetted by the BigCode community, said Chapados.

    It’s not clear right now how much of the code finding its way into production environments is being generated by machines versus humans. However, as LLMs continue to advance, the percentage created by machines will undoubtedly increase. The challenge DevOps teams now face is determining how to apply AI to pipelines that will increase in number as codebases not only proliferate but also become inevitably larger.

    In the meantime, DevOps teams would be well-advised to become familiar with what type of LLM is being used to train the generative AI platforms being used to create code. The more general purpose an LLM is, the more likely it is to generate suboptimal code that DevOps teams are only going to need to eventually replace, especially if that code is consuming expensive infrastructure resources inefficiently.

    There is, of course, as far as generative AI is concerned, no going back at this point. The issue now is determining how to keep track of the provenance of all the code being generated to determine how best to fix it whenever needed.

  • Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

    As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

    In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

    Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

    In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

    Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

    In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

    More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

    Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

    Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

  • New Relic Streamlines Observability Data Management

    New Relic Streamlines Observability Data Management

    New Relic this week made available a live archives capability that provides instant access to historical logs for up to seven years and eliminates the need to rehydrate, reload, re-index or move data.

    At the same time, the company also announced its observability platform is now integrated with infrastructure and observability tools provided by Sentry Software to help IT teams reduce costs and collect additional sustainability metrics alongside logs, metrics and traces.

    Jemiah Sius, senior director of developer relations for New Relic, said overall, New Relic is moving to make it simple to analyze and store telemetry data regardless of when it was collected. For example, rather than requiring historical data to be accessed via a cold storage service in the cloud, the New Relic platform now makes that data available directly within the database that is at the core of its observability platform.

    That approach also provides the added benefit of not incurring ingress and egress fees for moving data in and out of cloud storage services, noted Sius.

    IT teams can simply create a New Relic Query Language (NRQL) to identify which logs to route to a live archive in as little as 30 seconds without having to add an additional log collector.

    The overall goal is to make it simpler to investigate incidents faster, given the urgency that is created whenever there is an outage or audit request that needs to be immediately addressed, noted Sius. That’s critical because DevOps teams are always for time, he added.

    In general, New Relic is reducing the overall toil associated that many DevOps teams encounter today when managing telemetry data. Rather than being confronted with a complex set of data engineering tasks, telemetry data from multiple applications and infrastructure platforms can automatically be collected, analyzed and stored.

    It’s still early days as far as the adoption of observability platforms is concerned, but there is already no shortage of options. The challenge is that in addition to logs, metrics and traces, IT teams are now starting to also track cost and energy consumption metrics. Observability platforms provide the means to centralize telemetry data that is only going to increase in volume as more applications are deployed. The challenge has been framing the queries needed to surface meaningful insights. Fortunately, with the rise of generative artificial intelligence (AI) tools that make it simpler to create queries, the overall level of skill required to invoke an observability platform is dropping. In effect, generative AI is making it possible to democratize DevOps best practices.

    Ultimately, existing DevOps teams should be able to manage highly distributed application environments without having to hire and retain a small army of additional software engineers. The issue is that, in many cases, the size of the overall code base is increasing rapidly as developers take advantage of various generative AI tools to help them write code faster. Hopefully, advances in AI will arrive soon enough to enable DevOps teams to cope with all that code before DevOps teams are inevitably overwhelmed.

  • The Great Debate: The Future of Humans and Software in the Age of AI

    The Great Debate: The Future of Humans and Software in the Age of AI

    Listening to the two sides of the debate regarding how much AI will take over software development, delivery and support tasks and its impact on jobs is both exciting for technology and scary for humans. The debate goes something like this:

    AI Advocate: Welcome to the future! With AI’s capabilities today, we’re looking at a world where software applications can practically develop, deliver and support themselves. The need for human involvement is diminishing rapidly.
    AI Antagonist: That’s an overly optimistic view. You’re underestimating the value of human creativity, empathy and ethical judgment. There are areas where AI simply cannot replace the human touch.
    AI Advocate: Consider design and specification. AI can generate prototypes and suggest improvements. It’s about efficiency and leveraging AI to cut down on the grunt work.
    AI Antagonist: But who sets the vision? AI lacks the understanding of user needs and market demands that only humans possess. The strategic decision-making and nuanced understanding of user psychology are irreplaceable.
    AI Advocate: True, but AI’s role in supervision and training cannot be overlooked. It can manage its operations, needing only minimal human oversight to update data and rules.
    AI Antagonist: And yet, who ensures these AI systems are aligned with ethical standards and current practices? Humans are crucial for overseeing these systems, ensuring they operate as intended and do not deviate into unethical territory.
    AI Advocate: I’ll give you that. However, in quality assurance and testing, AI significantly reduces the human workload by automating many processes.
    AI Antagonist: Automation has its place, but human insight is vital for identifying complex issues and understanding user experience in a way AI cannot. There’s a depth to exploratory and usability testing that AI can’t reach.
    AI Advocate: Ethical and legal oversight might be your strongest point. AI does struggle with nuanced decisions in privacy, security and bias. I concede that humans are necessary to navigate these complex fields.
    AI Antagonist: And don’t forget about customer support. AI can handle routine queries, but complex problems and sensitive issues require human intervention. The personal touch is something AI can’t replicate.
    AI Advocate: Innovation is a collaborative effort, I admit. AI assists, but human creativity drives continuous improvement and adapts to market trends.

    What Are the Implications if the AI Advocate is Correct?

    If the AI advocate’s vision comes to fruition, the implications for humanity could be profoundly transformative. First, the automation of routine and complex tasks alike would herald a new era of efficiency and productivity, potentially liberating humans from the drudgery of monotonous work. This shift could lead to an increased focus on creative, strategic and interpersonal tasks that leverage human strengths and foster innovation. Moreover, the widespread adoption of AI in software development could drastically reduce the time and resources needed to bring new technologies to market, accelerating the pace of technological advancement and potentially solving critical challenges in fields like healthcare, education and environmental protection. However, this future also raises concerns about job displacement and the need for societal adjustments to manage the transition, emphasizing the importance of re-skilling and education to prepare the workforce for a new economic landscape dominated by AI and automation.

    What Are the Implications if the AI Antagonist is Correct?

    On the other hand, if the AI antagonist’s perspective holds, the implications underscore the indispensable value of human involvement in technology. This scenario suggests that despite AI’s advancements, the nuanced understanding, ethical judgment and creative problem-solving capabilities of humans remain crucial. It highlights the potential risks of over-reliance on AI, including ethical dilemmas, privacy concerns and the perpetuation of biases if not carefully overseen by human intelligence. The emphasis on human skills and creativity could lead to a more balanced approach to technological development, where AI is used as a tool to augment human capabilities rather than replace them. This future would prioritize the development of technologies that are not only innovative but also ethical, user-centric and socially responsible, ensuring that technological progress benefits all of society.

    A Balanced Future

    Ultimately, the truth likely lies somewhere in between these two viewpoints, suggesting a future where AI and human capabilities are intertwined. The implications of such a balanced approach would be a collaborative ecosystem where AI enhances human efforts, leading to unprecedented levels of productivity and innovation while also creating new opportunities for human workers. This future emphasizes the importance of adaptability, lifelong learning and ethical considerations as central pillars of technological advancement. It also highlights the need for policies and educational systems that support the workforce in transitioning to roles that leverage human strengths in creativity, empathy and strategic thinking, ensuring that the benefits of AI are distributed equitably across society.

    Image source: https://vecteezy_futuristic-technology-concept-mixed-media-innovations-data_7019122_167-3.jpg

  • JFrog Extends MLOps Integration Efforts via Qwak Alliance

    JFrog Extends MLOps Integration Efforts via Qwak Alliance

    JFrog today announced it has integrated its DevSecOps platform with a managed machine learning operations (MLOps) platform from Qwak to advance collaboration between teams building and deploying multiple classes of software artifacts.

    This alliance comes on the heels of a similar Amazon Sagemaker alliance announced last month that also integrated a managed service for building artificial intelligence (AI) models provided by Amazon Web Services (AWS) with the JFrog Software Supply Chain Platform.

    Both machine learning operations (MLOps) platforms provide data science teams with a complete stack of curated tools required for building AI models from the ground up versus, alternatively, customizing AI models that were previously built.

    Gal Marder, executive vice president for strategy for JFrog, said integration with the Qwak platform makes it possible to manage the software artifacts created by MLOps teams alongside the rest of the software artifacts a DevSecOps team is already managing. That approach makes it possible to also detect and block the use of malicious ML models in addition to ensuring models comply with company policies and regulatory requirements, he noted.

    As it becomes apparent that more AI models will be directly embedded within applications, the need to integrate DevOps workflows with machine learning operations (MLOps) platforms used to create AI models is becoming more pronounced, said Marder.

    JFrog Software Supply Chain Platform can be used to provide both data scientists and developers with a single source of truth for securely managing software artifacts using a common repository to foster greater collaboration between teams that, in most cases, are still determining how best to collaborate, he added.

    The challenge is data scient teams typically train and deploy AI models every few months, while DevSecOps teams are often updating applications multiple times a month. Data science and DevSecOps teams, as a result, generally have distinct cultures, but in the long term, DevOps and MLOps workflows will eventually merge, said Marder.

    Most organizations are still trying to determine how best to operationalize AI using their own data. In the term, AI models are being invoked via application programming interfaces (APIs). Still, it’s also now only a matter of time before more AI models are embedded in applications to improve overall performance. The challenge is that AI models can’t be updated the same way other software artifacts are patched, so managing versions of AI models will require a different set of controls as one model replaces another. JFrog, for example, has developed versioning capabilities that can be applied to AI models in the context of a DevOps workflow.

    There is, of course, already no shortage of MLOps platforms, so DevOps teams should expect to see a wave of alliances being formed between the providers of these platforms. Less clear is to what degree those alliances might lead to mergers and acquisitions among the providers of those platforms.

    One way or another, however, AI models are coming to DevSecOps workflows. The only issue to be resolved is how best to manage their deployment alongside all the other types of software artifacts already moving through existing DevOps pipelines.

  • Securing the DevOps Pipeline: Tools and Best Practices

    Securing the DevOps Pipeline: Tools and Best Practices

    The DevOps pipeline refers to the set of practices and tools designed to automate and integrate the processes between software development (Dev) and IT operations (Ops) teams. This pipeline facilitates continuous integration (CI), continuous delivery (CD) and rapid deployment practices, aiming to shorten the development life cycle and provide continuous delivery with high software quality. 

    The DevOps pipeline typically includes planning, coding, building, testing, releasing, deploying, operating and monitoring, enabling teams to develop and deploy software more efficiently and with fewer errors.

    By automating workflows and integrating various development and operational activities, the pipeline supports the rapid iteration of software releases. This not only accelerates the pace of software development but also ensures that quality and performance standards are met throughout the application’s life cycle.

    Due to the critical nature of the DevOps pipeline, security is becoming a top priority. Some of the most devastating cyberattacks in recent years were related to breaches in DevOps pipelines, which led to global-scale supply chain attacks.

    The Need for Security in DevOps

    DevOps, by its very nature, encourages speed and efficiency. However, this drive for rapid software development and deployment can sometimes overlook the critical aspect of security. That’s why it’s essential to weave security into the fabric of the DevOps pipeline, an approach known as DevSecOps. By doing so, we can ensure that security isn’t an afterthought but an integral part of the development process.

    Incorporating security into the DevOps pipeline offers multiple benefits. First, it helps identify and rectify security vulnerabilities early in the development process, reducing the risk of security breaches. It also fosters a culture of shared responsibility, where the development, operations and security teams work together toward the common goal of creating secure software.

    Tools for Securing the DevOps Pipeline

    Securing the DevOps pipeline requires a set of tools that align with the DevOps philosophy of automation and continuous improvement. Let’s explore some of these tools.

    Static Application Security Testing (SAST)

    SAST, also known as white-box testing, is a tool that helps locate security vulnerabilities in the codebase without executing the application. It makes it possible to identify issues early in the development process, even before the code is run.

    SAST works by analyzing the source code, bytecode or binary code, looking for patterns that might indicate a security flaw. The strength of SAST lies in its ability to pinpoint the exact location of the security vulnerability in the codebase. This makes it easier to fix the issue, thus saving time and resources.

    Dynamic Application Security Testing (DAST)

    DAST, a type of black-box testing, involves testing the application in its running state. It’s designed to find security vulnerabilities that can’t be spotted during static analysis.

    DAST works by simulating attacks on the application and observing its response. It can identify security issues like cross-site scripting (XSS), SQL injection and security misconfigurations. The beauty of DAST is that it views the application from an attacker’s perspective, thus providing a real-world assessment of its security. However, DAST can’t identify vulnerabilities in the source code and relies on the application being in its running state for testing.

    Software Composition Analysis (SCA)

    Software composition analysis (SCA) is designed to provide visibility into the open source components used in the software. It helps identify any security vulnerabilities, licensing issues or outdated libraries in the open source components.

    SCA works by creating a bill of materials (BOM) that lists all the open source components used in the software. It then compares this list against various databases that track open source vulnerabilities. If a match is found, SCA flags the component, allowing the developers to take necessary actions.

    Endpoint Detection and Response (EDR)

    Endpoint detection and response (EDR) is a cybersecurity technology that addresses the need for continuous monitoring and response to advanced threats. EDR tools continuously monitor endpoint and network events and record the information in a central database where further analysis, detection, investigation, reporting, and alerting take place.

    EDR is like a surveillance system for your DevOps pipeline. It keeps an eye on endpoint activity, and if it detects a potential threat, it alerts developers and security staff. EDR is not just about detection; it also provides tools for responding to security incidents. It helps isolate affected systems, block malicious activities and even roll back systems to their pre-attack state.

    Container Security Tools

    In a DevOps environment that increasingly relies on containerization, container security cannot be overlooked. Container security tools provide a means to enforce security policies and protect containerized applications.

    These tools offer functionalities like image scanning, runtime protection and network segmentation. Image scanning helps identify vulnerabilities in the container images. Runtime protection monitors the container’s activities in real-time, looking for any signs of compromise. Network segmentation allows for isolating containerized applications, thus limiting the blast radius in case of a security incident.

    Best Practices for Securing the DevOps Pipeline

    Integrate Security Early (Shift Left)

    The concept of ‘shifting left’ in DevOps refers to integrating security measures early in the development process. Instead of treating security as an afterthought, it becomes a part of the software development life cycle from the get-go.

    Implementing security early allows us to identify and address potential vulnerabilities before they become a significant issue. It saves us time and resources by preventing security breaches instead of responding to them. Besides, it fosters a proactive approach to security, emphasizing prevention over remediation.

    SAST and DAST are useful in integrating security early. SAST tools analyze code in its static state to identify vulnerabilities, while DAST tools test applications in their running state to detect security flaws.

    Automate Security Processes

    Automated security scans can be incorporated into the continuous integration/continuous delivery (CI/CD) pipeline. Each time a code push occurs, these scans are triggered, allowing for immediate feedback on potential security issues. Automated scans can detect a broad range of vulnerabilities, from code defects to configuration errors.

    Configuration management tools like Chef, Puppet, Ansible and Terraform can help manage configurations and enforce security policies. They ensure that all systems are configured correctly and consistently, reducing the risk associated with manual configuration.

    Regular Security Audits and Compliance Checks

    Regular security audits and compliance checks are essential in securing the DevOps pipeline. They provide an opportunity to review and update security measures, ensuring they are effective and up-to-date.

    Security audits should be comprehensive, covering all aspects of the DevOps pipeline. They should evaluate security controls, identify potential vulnerabilities, and recommend remedial measures. Compliance checks ensure that security practices align with relevant regulations and standards.

    In conclusion, securing the DevOps pipeline requires a holistic approach that integrates security into every aspect of the development process. It involves shifting security left, automating security processes, conducting regular audits and compliance checks and fostering a culture of collaboration.

  • Dell Brings DevOps to Edge Computing Environments

    Dell Brings DevOps to Edge Computing Environments

    Dell Technologies today updated its edge computing platform this week to make it simpler to programmatically provision infrastructure using DevOps best practices.

    Phil Burt, senior director of project management for edge computing at Dell Technologies, said version 2.0 of Dell NativeEdge adds additional declarative blueprints based on YAML files and the Topology and Orchestration Specification for Cloud Applications (TOSCA) framework.

    Blueprints for Telit, Litmus and PTC for manufacturing use cases, Deep North for retail, Dell Streaming Data Platform for analytics and Rancher Labs K3s for Kubernetes environments are provided.

    Those blueprints make it simpler to either deploy applications on a lightweight operating system that Dell developed optimized for edge computing platforms or any other software stack an IT organization may prefer, he added.

    Dell is also adding support for the virtual Trusted Platform Module (vTPM) and UEFI Secure Boot capabilities to apply zero-trust IT principles to edge computing platforms using hardware-based cryptography and secure storage for encryption keys, certificates and passwords.

    Finally, Dell is also making available a three-year subscription plan for NativeEdge to lower the total cost of deploying edge computing platforms.

    Dell relies on virtual machines it developed for edge computing platforms to deliver software. IT teams can then opt to deploy monolithic applications or container-based applications running on an instance of Kubernetes deployed as an extension of the virtual machine provided by Dell. Those platforms can then also automatically connect to a network to provide the connectivity required.

    Regardless of approach, Dell is providing a method to programmatically orchestrate the management of highly distributed edge computing environments, noted Burt.

    In the longer term, Dell is also researching how to apply generative artificial intelligence (AI) to the management of edge computing environments using the data its monitoring tools provide, he added.

    While edge computing has been around in one form or another for decades, as more organizations start to process and analyze data at the point where it is created and consumed, the number of applications deployed at the network edge has increased substantially. As such, the number of applications that need to be built and deployed at the edge using DevOps best practices is growing exponentially. In fact, managing those workloads is only going to become that much more challenging as more AI models are deployed at the network edge.

    Of course, not every workload at the edge is managed by an IT team. For years, many organizations have relied on operational technology (OT) teams that have historically deployed applications at the network using manual processes. Organizations that embrace DevOps practices to automate the deployment of workloads at the edge will naturally have to navigate some cultural issues alongside the technical challenges encountered when programmatically deploying software.

    It’s not clear how much software will be running at the network edge in the years ahead, but as the capabilities of the IT infrastructure made available continue to increase, so will the complexity of the applications that will be deployed. The challenge, as always, is going to be finding the best way to manage all that distributed software at what will soon be an unprecedented level of scale.