devopsy.kinsta.cloud

Category: News

  • Update to Open Source ZAP Tool Improves DAST Performance

    Update to Open Source ZAP Tool Improves DAST Performance

    An update to the OWASP Zed Attack Proxy (ZAP) open source dynamic application security testing (DAST) tool made available today improves performance by employing a multi-threaded passive scanner engine.

    Version 2.12.0 of ZAP also adds support for HTTP/2 and should make it simpler to update the vulnerability scanning tool by making the spider that discovers new resources an add-on that is now capable of discovering more URLs.

    ZAP is an open source penetration testing tool maintained by the Open Web Application Security Project (OWASP) designed specifically for testing web applications.

    Simon Bennetts, founder and chief maintainer of ZAP, said the latest update will make it simpler for developers to discover vulnerabilities in their code faster. One of the reasons developers often don’t frequently scan their code for vulnerabilities is because the scans are perceived to be slow, he said. Of course, the longer a developer waits before scanning their code the longer it will take to complete the scan.

    DAST tools are a critical element of any DevSecOps workflow because they enable developers to view weaknesses in application security as an attacker would—by analyzing a web application through its front end. That approach doesn’t eliminate the need for static application security testing (SAST) tools to discover vulnerabilities in source code; rather, a DAST tool helps developers better understand how cyberattacks target specific types of vulnerabilities in their applications, noted Bennetts. As an open source tool, ZAP is intended to remove the barriers to adoption of DAST tools by making it simpler for developers to download and install themselves, he added.

    Interest in DAST tools is, of course, rising in the wake of a series of high-profile attacks against software supply chains. The debate that has ensued is how far to shift application security responsibility left toward application developers. More organizations are starting to require developers to embed security tools within their application development tools. Others are also embedding various types of security tools within their DevOps workflows to ensure scans are run should developers fail to do so.

    No developer sets out to build an insecure application, of course. The primary issue is that many of the DAST tools being provided are not designed to be employed by developers, said Bennetts. Instead, they are designed for cybersecurity teams that then share results with developers after an application has been constructed, he added. That approach creates a dysfunctional relationship between application development and cybersecurity teams because developers are being asked to remediate vulnerabilities long after code was initially written, said Bennetts. In most cases, those developers have moved on to other projects so any context for how code was constructed is often lost, he noted.

    Implementing DevSecOps best practices is, naturally, as much about culture as it is the tools being provided. However, the one thing that is clear is that tools adopted willingly by developers are going to be much more widely used than tools chosen by others on their behalf. In many cases, the shortest path to improving the overall state of application security is going to be an open source tool that developers can readily access themselves.

  • Mezmo Adds Observability Pipeline to Analyze DevOps Data

    Mezmo Adds Observability Pipeline to Analyze DevOps Data

    At the KubeCon + CloudNativeCon North America conference this week, Mezmo launched an Observability Pipeline platform that promises to make it simpler to manage, enrich and correlate machine data.

    Previously known as LogDNA, Mezmo is expanding the scope of its reach to add the ability to augment and analyze data on top of its core log management platform. Over time, that capability will be extended to add support for metrics and traces using the open source OpenTelemetry agent software.

    Mezmo CEO Tucker Callaway said the goal is to provide a framework for centralizing the flow of observability data that is now being generated by a wide range of sources across a DevOps workflow. It’s clear that DevOps teams require a means to enrich and correlate high volumes of data in motion that goes beyond simply pre-processing so it can be stored more cost-effectively, he added.

    The Mezmo Observability Pipeline achieves that goal by ensuring the right data is flowing into the right systems in the right format for analysis, noted Callaway.

    As the volume of data being collected by DevOps teams continues to dramatically increase the need to embrace a set of DataOps best practices is becoming more apparent. DataOps has emerged recently to describe a set of data engineering practices that applies many DevOps principles to the way data should be managed. Mezmo’s Observability Pipeline aims to make it simpler to apply DataOps best practices specifically to the data collected by DevOps teams.

    Of course, each DevOps team will need to decide for themselves how much data they want or need to store long term. However, increasingly DevOps teams are holding onto data much longer as IT environments become more complex, noted Callaway. That creates a need to more efficiently analyze as much data as possible and store it more cost-effectively, he said. Those twin goals, however, often create a physics problem in the sense that they can be diametrically opposed.

    In the longer term, it’s not quite clear how much DevOps teams are embracing observability. Most DevOps teams make use of monitoring tools that enable them to track a set of pre-defined metrics. Observability platforms promise to make it easier for DevOps teams to query a wide range of data types to discover potential issues before they disrupt an IT environment. The challenge is that many DevOps teams may not know what queries to form to discover those issues. It’s likely that, over time, machine learning algorithms will be increasingly applied to observability data to make it simpler to surface potential issues.

    In the meantime, however, the need for DevOps teams to find ways to manage all the data being generated by multiple types of applications is becoming a higher priority. In fact, in the absence of any meaningful way to manage all that data, the benefits of an investment in an observability platform is likely to be limited, at best.

  • Meta Income Down by Half | Will Apple Make it Worse? | Linux Secure Boot Fix

    Meta Income Down by Half | Will Apple Make it Worse? | Linux Secure Boot Fix

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Meta’s latest results are very bad, Apple wants its cut of Facebook ads, and Lennart Poettering proposes a new Secure Boot for Linux. (more…)

  • Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Technologies this week launched a hosted platform-as-a-service (PaaS) environment, dubbed Fermyon Cloud, that promises to make it simpler to build WebAssembly (Wasm) applications.

    Announced during the Cloud Native Wasm Day event during the KubeCon + CloudNativeCon North America conference, Fermyon Cloud is now available in open beta.

    Fresh from raising $20 million in funding, Fermyon CEO Matt Butcher said IT teams can quickly build and deploy Wasm applications using a Fermyon Spin development tool and a Fermyon Platform the company launched earlier this year.

    Fermyon Cloud adds an opinionated PaaS environment managed by Fermyon that can start up Spin applications in less than a millisecond. It uses a serverless application programming interface (API) that makes it possible to cache and optimize applications as they are loaded, noted Butcher.

    Originally developed more than five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now used to rapidly build lighter-weight applications that can be deployed on any server platform. In effect, the promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

    Wasm isn’t necessarily going to replace existing approaches for building applications, at least not any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster.

    In addition, at a time when organizations are becoming more concerned about application security, the appeal of Wasm is clear. Existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. In contrast, Wasm code runs in a sandboxed environment that isolates execution environments to eliminate the ability of malware to laterally move across an application environment.

    Wasm is especially well-suited for building lightweight applications that previously might have been deployed on a serverless computing framework, noted Butcher. The issue developers are encountering when using a serverless computing framework is that those frameworks are based on containers that have comparatively slow startup times, he added.

    It remains to be seen how much traction Wasm gains in the months ahead, but Butcher said he expects most backend services, such as databases, will continue to be built using containers. Fermyon is betting, however, that many future cloud-native applications built by the average developer will be constructed using Wasm. In the longer term, Wasm will also soon be used to build applications infused with machine learning algorithms, said Butcher.

    In the meantime, DevOps teams should get ready for more Wasm code to move through continuous integration/continuous delivery (CI/CD) pipelines. The challenge, of course, is that code will need to be managed alongside all the other software artifacts moving through those pipelines, as well.

  • Sigstore Code Signing Service Becomes Generally Available

    Sigstore Code Signing Service Becomes Generally Available

    A free digital signing service for software created by the Sigstore open source community has become generally available this week via the cloud.

    Announced at the SigstoreCon event that occurred during the KubeCon + CloudNativeCon North America conference, the cloud service makes it possible for developers to both cryptographically sign artifacts and verify that the components used to build applications are secure.

    The Sigstore community operates under the auspices of the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation. Sigstore project sponsors, including Google, Red Hat, GitHub and Chainguard, have committed to operating a service with a 99.5% uptime and round-the-clock pager support. More than 70 organizations, including Shopify, Autodesk, Trail of Bits and Rancher Government Solutions are actively involved in maintaining and scaling Sigstore.

    More the four million Sigstore signatures have been logged using Sigstore thanks mainly to Sigstore support that is already included by maintainers of open source Kubernetes and Python projects. The npm community also announced it is working to integrate Sigstore in all packages used to build JavaScript applications.

    Bob Callaway, co-founder of Sigstore and technical lead and manager for the Open Source Security Team at Google, said this service will make it much simpler for developers to add digital signatures to code in a way that can be more easily verified within a software bill of materials (SBOM).

    The goal now is to expand the number of open source projects that will commit to employing Sigstore to better secure software supply chains, he added.

    The security of open source software became a major concern in the wake of the open source Log4j zero-day vulnerability. Sigstore was under development prior to that disclosure, but the Biden administration’s executive order requiring Federal agencies to verify the security of open source software has enabled the availability of more resources for the project.

    In response to the executive order, the OpenSSF outlined a 10-point plan to secure open source software that would require more than $150 million in funding. One of those goals is to have 50 of the top 200 projects and 1,000 of the top 10,000 projects adopt an interoperable approach to software signing. That project was estimated to cost $13 million for the first year and $4 million per year beyond, with a one-time additional $10 million required after the first year.

    It’s not clear how broadly developers will employ digital signatures, but given the current level of concern, it’s probable most organizations will soon require any code they use to be digitally signed so it can be verified as immutable. The next big challenge, of course, is finding a way to operationalize the collection of all the SBOMs that will include those signatures. After all, SBOMs are only the first step in a larger DevSecOps workflow that will enable organizations to accept or reject software components based on all the data being collected.

  • BMC Extends Scope of ServiceOps Initiative

    BMC Extends Scope of ServiceOps Initiative

    At the BMC Exchange conference this week, BMC revealed it has updated its Helix IT service management (ITSM) platform to include mapping and discovery capabilities. Those updates make it simpler for cross-functional teams to correlate incidents, alerts and data and pinpoint root causes faster.

    In addition, BMC is now applying pre-trained artificial intelligence (AI) models to observability data and the service models it tracks to assess service health, predict service impacts and proactively manage IT environments as the volume of metrics, events, and alerts continues to increase.

    Finally, BMC also announced that the BMC Helix Control-M orchestration engine now supports open source Apache Airflow, a workflow management platform for defining data pipelines using a Python programming tool.

    Margaret Lee, vice president and general manager for digital service and operations management at BMC, said these updates extend a unified ServiceOps initiative the company launched last year to unify ITSM, DevOps and customer service desk workflows. While each of these disciplines may have distinct objectives—such as speed and reliability—that are often in conflict with one another, Lee said it’s apparent IT organizations need to reduce the current level of friction that is often encountered when managing IT.

    As a software-as-a-service (SaaS) platform, Lee said the BMC Helix platform achieves that goal via a consumer-like user interface that can be easily personalized. The goal is to make it simpler to create virtual agents, knowledge bases, live chat and tickets that make it easy for customers and employees to request IT help, she added.

    Achieving that goal, however, will require IT organizations to rely more heavily on AI models to automate routine tasks as IT environments become more complex. There are simply not enough IT professionals available to manage IT environments using legacy processes, she noted.

    In addition, end users and customers are expecting service requests to be automated in way that allow them to resolve issues via a mobile device, added Lee. In many cases, how cumbersome IT processes now has a direct impact on both customers and employee retention. The primary goal is to reduce the number of interactions required to complete a task such as changing a password or provisioning a laptop whenever a new employee needs to be onboarded.

    While the pace at which IT management is evolving will vary greatly from one organization to the next, it’s apparent that many DevOps principles are being absorbed into traditional ITSM platforms. The challenge is that cultural divide between DevOps teams and centralized IT teams is still very wide. Most organizations are still trying to determine how far left they want to shift responsibilities toward application development teams versus continuing to rely on IT administrators using graphical tools to centrally manage IT workflows. It’s rarely going to be an all-or-nothing proposition. Rather, the issue is finding a way to strike a balance that enables organizations to be as agile as possible without introducing unacceptable levels of risk to resiliency.

  • JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    At the KubeCon + CloudNativeCon North America conference this week, JFrog announced it contributed the Pyrsia project, which uses blockchain technologies to secure software packages, to the Continuous Delivery (CD) Foundation.

    Stephen Chin, vice president of developer relations at JFrog and governing board member for the CD Foundation, said the goal is to increase the number of contributors to the project. Current contributors to the Pyrsia project include Docker, Inc., DeployHub, Futurewei and Oracle.

    As part of those efforts, the CD Foundation will bring a centralized governance model through which a roadmap for the project will be defined.

    Pyrsia provides IT teams with a decentralized blockchain network to access an immutable software package repository that is designed to seamlessly integrate with the package management systems developers already employ. It creates a digitally signed, immutable chain of evidence for code that can be incorporated into a software bill of materials.

    Securing software supply chains became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it.

    The trouble is, many organizations that rely on open source software assume it is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.

    It’s not clear to what degree security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, as most packaged applications include a large amount of open source code that is downloaded from any number of repositories. Whenever a zero-day vulnerability is discovered, organizations can easily spend months looking for all the instances of an open source component that might be vulnerable.

    In theory, blockchain platforms and DevSecOps best practices should make it easier to secure software packages by reducing the number of vulnerabilities in production environments. The challenge organizations face today is the amount of technical security debt that exists due to vulnerabilities in legacy applications. It might be close to a decade before applications based on more secure code replace existing solutions.

    In the meantime, multiple approaches to securing software supply chains are advancing, including the use of some type of immutable platform. It may be a while before those platforms are widely incorporated into software supply chains, but it’s apparent that it’s now more a question of how long it will take rather than if those technologies will be applied to securing software development environments.

  • Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A South Korean conflagration leads to a ridiculously long outage, and the price of public cloud is skyrocketing. (more…)

  • Cisco Unveils 800G Networking Platform to Advance DataOps

    Cisco Unveils 800G Networking Platform to Advance DataOps

    At the Open Compute Project (OCP) Global Summit conference, Cisco announced it developed an 800-gigabit switch that consumes significantly less power than the previous generation of its networking equipment.

    Thomas Scheibe, vice president of product management for cloud networking for Cisco’s Nexus and ACI product line, said the throughput provided by the latest 7-nanometer iteration of Cisco One ASIC processors is primarily needed by organizations processing massive amounts of data to train artificial intelligence (AI) models either in a local data center or in the cloud. The challenge is that many of the organizations are looking to build AI models that process massive amounts of data while simultaneously reducing their IT infrastructure’s carbon footprint, he noted.

    Cisco has been able to achieve that goal by continuing to invest in proprietary ASIC processors; they are at the core of its networking portfolio to improve data operations (DataOps), said Scheibe. Many IT teams are also looking to replace legacy network routers and switches that consume more power and reduce energy costs by as much as 77%, added Scheibe. In terms of climate impact, Cisco claimed its 8111-32EH switch can now provide 25.6Tbps at 15% of the power requirement. Cisco projected that switch will save about 10,000 kg CO2e per year compared to a 12.8Tbps switch. That equates to the greenhouse gas emissions generated by an average gasoline-powered passenger vehicle driving 26,155 miles, according to Cisco.

    IT teams also have the option of deploying either Cisco’s network operating system or SONiC—Software for Open Networking in the Cloud—network operating system (NOS).

    Cisco is also providing IT organizations with the option to configure its latest routers and switches to run at either 800, 400 or 100 Gigabits with an eye toward upgrading throughput sometime in the future.

    In general, DataOps as an IT discipline is maturing as organizations realize they need to implement best practices to optimize data flows across their organization. Cisco is giving IT teams the option of employing a standard Ethernet fabric or an alternative fabric that increases throughput by predicting which packets need to be delivered to a specific location based on their attributes and the behavior of previous network traffic. As the volume of data that needs to be accessed by low-latency applications continues to expand, DataOps will become a more critical IT discipline. Historically, storage administrators tended to be responsible for data management, but as these applications continue to proliferate, a new class of DataOps engineers is emerging to optimize the flow of data across distributed computing environments.

    In the longer term, it’s not clear how much carbon dioxide emissions are factoring into IT decisions these days, but there are organizations that have begun to track it as part of an effort to lower their carbon emissions. Most cloud service providers have also committed to being carbon neutral. Cisco is betting achieving that goal will require IT infrastructure upgrades at a time when the amount of data that needs to be processed will only continue to exponentially increase.

  • Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype this week published a State of the Software Supply Chain Report that found a 633% year-over-year increase in malicious attacks aimed at open source software residing in public repositories.

    In addition, Sonatype launched a Sonatype Safety Rating system that employs machine learning algorithms and other metrics to identify the most secure open source components stored in those repositories.

    The report found 96% of open source Java downloads have known vulnerabilities that could have been avoided if an available, more secure version had been used. Collectively, the report estimated there were 1.2 billion known-vulnerable dependencies that could be avoided if developers had only been aware that a later version of a software component was available.

    According to the report, the average Java application contains 148 dependencies. Updates to Java applications are, on average, made 10 times a year, so development teams are being asked to track 1,500 dependency changes per year.

    Sonatype CTO Brian Fox said the report makes it clear that organizations are not assuming enough responsibility for using open source software that has known vulnerabilities. In effect, organizations are blindly and recklessly using software components without any real appreciation of the associated risks, he said.

    Rather than a knee-jerk reaction to each new zero-day vulnerability that is discovered, Fox said, IT teams need to focus on putting processes in place to make sure the latest, most secure edition of any given software module is being used. A survey of 662 engineering professionals included with the report, however, found 68% of respondents were confident that their applications were not using known vulnerable libraries. Nevertheless, a random sample of enterprise applications conducted by Sonatype found 68% contained known vulnerabilities.

    Overall, the report surmised that consumption of open source software will soon surge past an estimated 3.1 trillion total requests, with six out of every seven vulnerabilities being the result of a transitive dependency created by indirect relationships between software components. At the current rate of consumption, it’s fairly clear that the processes used to build and deploy applications today are insane given how dependent organizations are on applications, said Fox.

    In the wake of a series of high-profile security breaches, there is, fortunately, a lot more focus on securing software supply chains today than there was this time last year. The scope of the challenge, however, is mind-boggling when you consider the totality of applications already deployed in application environments that have known vulnerabilities. Organizations need to first make sure they are remediating vulnerabilities in their most critical applications while at the same time implementing DevSecOps best practices. This will ensure as few vulnerabilities as possible find their way into the next generation of applications.

    Obviously, these application security issues are not going to be resolved overnight. DevOps teams will be spending the next several years addressing a level of technical security debt that has been allowed to accrue for more years than anyone in IT really cares to admit.