devopsy.kinsta.cloud

Author: Mike Vizard

  • Datadog Unfurls Application Security Service

    Datadog Unfurls Application Security Service

    Datadog, Inc. today made generally available an Application Security Monitoring (ASM) service that is based on the same agent software that many DevOps teams already use to monitor applications.

    Pierre Betouin, vice president of product for the cloud security platform at Datadog, said ASM is designed to make it simpler for DevOps teams to add additional DevSecOps best practices to their existing workflows. The ASM service is based on a runtime application self-protection (RASP) engine and web application firewall that Datadog gained with the acquisition of Sqreen a year ago.

    ASM then employs distributed tracing to discover code-level vulnerabilities such as server-side-request forgeries (SSRFs), SQL injection and cross-site scripting (XSS) flaws. It is designed to extend an existing Datadog Cloud Security Platform that includes cloud security posture management (CSPM), cloud workload security (CWS) and cloud SIEM services.

    The overall goal is to make it simpler for DevOps teams to address application security by eliminating the need to deploy and maintain a separate set of agents within applications, said Betouin. That approach reduces resistance among DevOps teams that would otherwise be concerned about the additional overhead another approach to application security would add to an application environment, he added.

    The number of organizations looking to implement DevSecOps best practices is expected to increase in the weeks and months ahead in the wake of a series of high-profile breaches and zero-day vulnerability disclosures. Many organizations are now performing security reviews across their entire software supply chain as part of an effort to discover any malicious malware that might have been inserted into applications.

    The challenge those organizations face is that as application environments become more dynamic, maintaining application security becomes more difficult as code is continuously updated. The best way to address that engineering challenge is to extend the reach of an observability platform that many DevOps teams already have in place, noted Betouin. Ultimately, the goal is to automate application security as much as possible but that’s not going to be achievable if DevOps teams lack the context required, he added.

    It’s not clear at what rate organizations are embracing DevSecOps best practices. However, it’s clear that DevOps teams are being held more accountable for application security. Most developers are now charged with becoming application security experts overnight, so the only way to effectively ensure application security is to uncover security flaws before applications are deployed in production environments.

    There are, of course, multiple ways of achieving that goal. Datadog is betting that the path of least resistance is via a cloud service that connects to agent software inserted within those applications. DevOps teams have been inserting agent software, in one form or another, into those applications for years. The issue is that with each new agent added there is yet another software component that needs to be deployed and regularly updated. If not carefully tracked, a DevOps team could find itself attempting to manage an entire portfolio of agent software for every platform employed.

  • mabl Makes Move to Automate Accessibility Testing

    mabl Makes Move to Automate Accessibility Testing

    mabl today made available in beta an automated accessibility testing capability that it added to its software-as-a-service (SaaS) platform for testing applications.

    Dan Belcher, mabl co-founder, said given the increased accessibility requirements included in various compliance mandates, there is a greater need to address these issues as early as possible in the application development life cycle. Otherwise, organizations could find they are liable for failing to comply with accessibility requirements outlined in, for example, versions 2.0 and 2.1 of the Web Content Accessibility Guidelines (WCAG).

    At the same time, providers of applications that don’t address accessibility are also likely to find themselves called out on public social media forums, noted Belcher. The damage to brand reputation can be considerable, he added.

    The SaaS platform mabl created makes it possible to create reusable tests using a low-code engine dubbed axe-core. Those tests can then be inserted, as appropriate, into a DevOps workflow. That approach allows a dedicated testing team to create tests in a way that doesn’t need to occur on a DevOps platform, said Belcher.

    Regardless of regulatory requirements, Belcher said there is a clear need to include end users with disabilities within a digital universe that continues to rapidly expand. Unfortunately, as a whole, the software industry is only just starting to make accessibility a first-class concern, he added.

    The goal should be to enable fast feedback via accessibility regression tests that address, for example, contrast check, said Belcher. However, it’s not likely those tests are going to eliminate the need for periodic audits by accessibility subject matter experts as an application continues to evolve, he noted. Those reviews would address everything from the user interface to the overall performance impact, noted Belcher. It may possible, however, to one day address 50% of the accessibility issues identified in the WCAG guidelines via automation, he noted. Scanning code as it is being developed will prevent a backlog and a buildup of accessibility debt that would be much more costly to address after an application is deployed, added Belcher.

    In general, Belcher said, it’s not likely automation is ever going to entirely eliminate the need for dedicated testing teams. Testing platforms such as mabl are designed to enable a finite testing resource to keep pace with an accelerated rate of application development, he added.

    Accessibility is, for all intents and purposes, a subset of any comprehensive software quality review. The sooner development teams realize that fact the less likely they will find themselves apologizing in the future for not coming to that realization earlier.

  • Digital.ai Extends Scope and Reach of DevOps Platform

    Digital.ai Extends Scope and Reach of DevOps Platform

    Digital.ai today unveiled the Ascension release of its namesake DevOps platform that adds pre-built metrics and best practices dashboards using a Test Lens capability to more easily employ analytics to identify software delivery bottlenecks.

    In addition, the company has added autonomous testing tools that automatically generate performance and security tests for mobile applications. These tools can be run by DevOps teams, developers or business users. An enhanced Change Risk Prediction capability enables machine learning algorithms to make more extensive use of historical data.

    Finally, Digital.ai has also added integrations with the open source Argo continuous integration/continuous delivery (CI/CD) platform and made available an Agility Sync tool for building custom integration with legacy application environments and opened an online marketplace for integrations.

    Jeff Moloughney, chief marketing officer for Digital.ai, said the goal is to extend the reach of the company’s DevOps platform. At its core, the platform has a value stream management (VSM) and version control software originally developed by XebiaLabs and CollabNet VersionOne before the two companies merged to create Digital.ai. The combined company subsequently acquired Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools, and Arxan, a provider of an application security platform. The company claims that its platforms are used by more than 1,500 organizations.

    In general, DevOps is entering a new era as organizations realize how dependent they are on software to drive business processes, noted Moloughney. Historically, the adoption of DevOps practices has been driven from the bottom up within most organizations. Now, business and IT leaders are also looking to drive the adoption of a consistent set of DevOps best practices to gain more visibility into software delivery, he added.

    That does not mean, however, that organizations can dictate what tools individual developers can use, so the DevOps platform employed has to be extensible in terms of the available integrations, said Moloughney.

    At the same time, Molougney added that more DevOps processes will be automated using machine learning algorithms. Digital.ai is embedding these algorithms within its core platform to both uncover software delivery bottlenecks and automate routine tasks such as testing.

    It’s not clear to what degree organizations that have already embraced DevOps might be considering replacing their existing platforms but, regardless of size, most of them are encountering issues. On the plus side, the number of organizations that are adopting DevOps practices more broadly is increasing as more digital business transformation initiatives are launched. As those practices evolve, the expectation is many of those organizations will embrace analytics in the form of VSM to better optimize their efforts.

    In the meantime, the rate of DevOps adoption across enterprises will continue to vary widely. Each development team within an organization tends to define a set of DevOps practices based on their own requirements. The challenge, given all the dependencies that exist between those projects, is determining the actual rate of progress the organization is making as each of those isolated initiatives progresses.

  • Riverbed Unveils Unified Observability Platform

    Riverbed Unveils Unified Observability Platform

    Riverbed today launched a beta of a unified observability platform it will make available under the Alluvio by Riverbed brand name.

    Jim Hansen, senior vice president for product management at Riverbed, said the Alluvio by Riverbed observability platform combines several existing network and application performance management platforms into a single offering that is now infused with machine learning algorithms to provide deeper insights into IT environments.

    The goal is to provide an open observability platform that can not only aggregate data collected from both Riverbed and third-party offerings but also identify the best ways to resolve an IT issue, added Hansen.

    Scheduled to be generally available later this year, the Alluvio by Riverbed observability platform will differ from existing observability platforms in that it will enable IT teams to not just identify the root cause of an IT issue, but also note which processes should be employed to resolve it, he said.

    With this launch, Riverbed is attempting to reposition itself. Previously, the company offered network and application performance management platforms alongside a wide range of network software and hardware. Each of those offerings is now a source of data that can be fed into the Alluvio by Riverbed observability platform, noted Hansen.

    Observability, of course, has always been a core tenet of any DevOps best practice. Achieving that goal, however, has proven to be elusive. Most of the IT monitoring tools used today are designed to track a set of pre-defined metrics. Whenever there is an issue, IT teams typically convene in a war room where they try to uncover the root cause of, for example, a performance issue by comparing reports and the various dashboards generated by monitoring tools. It can take weeks to discover an issue that often only takes a few minutes to fix once the source of the problem is identified.

    In contrast, observability platforms promise to reduce the time required to discover IT issues by aggregating all the data generated by the IT environment within a single platform that correlates events and makes it easier to identify anomalous behavior. Armed with those insights, it becomes a lot simpler for IT teams to launch queries that enable them to resolve issues faster.

    Those insights are also increasingly being used to drive business decisions as organizations become more dependent on software to drive digital business transformation initiatives. However, a recent survey conducted by Riverbed finds three-quarters of business decision-makers (75%) said their organizations struggle to glean actionable insights from data generated by their technology infrastructure.

    The challenge IT teams inevitably encounter is they don’t always know the right questions to ask, which is an issue that can be addressed by machine learning algorithms capable of identifying anomalies indicative of an IT issue that needs to be resolved.

    There already is no shortage of observability platforms. The issue now is determining which observability platform to employ across a distributed IT environment that is becoming more instrumented with each passing day.

  • Report Finds Most Log4Shell Vulnerabilities Unpatched

    Report Finds Most Log4Shell Vulnerabilities Unpatched

    A report published today by Rezilion, a provider of a platform for tracking and analyzing software vulnerabilities, found that despite all the attention the Java zero-day Log4Shell vulnerability attracted, it appears that nearly 60% of the affected software packages remain unpatched.

    Rezilion used Google’s Open Source Insights tool to scan open source software packages, including dependencies, and found that out of a total of 17,840 affected Java software packages, only 7,140 have been patched.

    In addition, the Rezilion report cited a Log4j vulnerability resource center maintained by Sonatype indicated that 36% of the vulnerable versions of the Log4j Java log management tool that were actively downloaded from Maven Central are still vulnerable to Log4Shell.

    Rezilion also made use of dive, an open source tool for exploring Docker container images, to verify what version of Log4j might be present in containers, and Shodan.io, a search engine for discovering internet-connected devices.

    Yotam Perkal, director of vulnerability research for Rezelion, said that the results suggested that many organizations that have deployed a Java application have no way of knowing whether it includes the widely used open source Log4j tool for tracking logs within Java application. Many of the instances of that tool are subject to a recently discovered zero-day vulnerability that can be easily used to execute malicious code within a Java application.

    The challenge is that many organizations are using Java software components provided to them by a third party, and they assume that software is secure. However, that third party is often not aware of how that software may have been deployed, noted Perkal.

    More troubling still, many organizations that deploy software today don’t actively manage anything that might be considered a software supply chain, he added. Software is deployed as needed with little to no regard for provenance, said Perkal.

    Even when organizations can track software components, patching Log4j is a challenge. Java files can be nested layers deep into other files. Java applications can also be packaged in ways that make searching for vulnerabilities more difficult.

    Naturally, much of the responsibility for discovering instances of vulnerable Java applications falls to DevOps teams. As organizations embrace DevSecOps best practices that revolve around a software bill of materials (SBOM), it becomes easier to track vulnerable software packages. The issue is that most organizations either don’t have an SBOM or fail to update it as applications are upgraded. In the absence of an SBOM, many DevOps teams are still looking for instances of Log4jShell four months after the initial vulnerability was disclosed.

    Unfortunately, this latest vulnerability crisis doesn’t appear to be the wake-up call that drives more organizations to implement DevSecOps workflows, said Perkal. While some organizations are proactively patching applications, many others are still waiting on updates from a third party they hope will address the issue. Those updates, however, may not arrive in time to prevent cybercriminals that know about the Log4jShell vulnerability from wreaking havoc.

  • SolarWinds Unveils Unified Observability Platform

    SolarWinds Unveils Unified Observability Platform

    SolarWinds this week launched an observability platform that makes available a range of tools and technologies that the company has developed and acquired via a common user interface.

    Rohini Kasturi, chief product officer for SolarWinds, said the SolarWinds Hybrid Cloud Observability platform also makes an observability platform affordable for a much wider range of organizations.

    The platform also makes it easier to discover, map, and understand dependencies in ways that make it easier to achieve and maintain service level objectives, he added.

    The SolarWinds Hybrid Cloud Observability is a suite of tools made available via multiple tiers that make it simpler to automatically discover the root cause of an IT issue in addition to making it easier to manage configuration, reporting, and planning tasks across cloud computing and on-premises IT environments, said Kasturi.

    As IT teams increasingly distinguish between merely monitoring IT environments and achieving observability that allows them to proactively surface anomalies using machine learning algorithms and other forms of data science, the level of depth and insight that can be applied to managing IT is increasing dramatically. In fact, observability is quickly becoming table stakes for any provider of IT management tools, noted Kasturi.

    There is, of course, no shortage of observability platforms. The SolarWinds Hybrid Cloud Observability is designed to be deployed alongside existing monitoring tools rather than requiring IT teams to rip and replace the tools they already employ, said Kasturi.

    It’s not clear to what degree IT organizations are embracing observability. As a core tenet of best DevOps practices, observability has always been a goal. However, even the most advanced DevOps teams have thus far achieved little more than continuous monitoring of IT environments that are based on a set of pre-defined metrics. An observability platform not only surfaces anomalies but also enables DevOps teams to launch queries across logs, metrics and distributed traces to identify the root cause of a performance issue before it becomes a major disruption.

    The biggest challenge, however, may not be the technology as much as it is simply understanding what queries to launch. As IT environments become more complex thanks in part to the rise of microservices-based applications, the number of potential permutations that might impact a highly dynamic IT environment is increasingly beyond the ability of any IT team to manually track. It’s already apparent that many of the legacy monitoring tools that DevOps teams rely on today will need to be rationalized in favor of tools infused with machine learning algorithms capable of discerning patterns across a complex IT environment.

    In the meantime, IT teams will need to spend a considerable amount of time experimenting with observability platforms in the months ahead. After all, applications don’t magically instrument themselves. However, once IT teams do find a way to aggregate the logs, metrics and traces that can be collected from one application environment, it does become easier to define a set of best practices that can eventually be more widely applied.

  • Report Finds Software Engineering Productivity Gains

    Report Finds Software Engineering Productivity Gains

    An analysis of the time 23,000 software engineers spent working in 2021 that was published this week by Jellyfish, a provider of an engineering management platform (EMP), finds cycle times on average were down to 12.6 days, representing a 12.3% decline over 2020. The report, however, also finds commits were down 4% year-over-year, while the number of issues resolved was up 5% year over year.

    Jellyfish CEO Andrew Lau said the data suggests that software engineers are opting to commit less code in favor of resolving issues faster. Overall, coding days per engineer were down 8% to less than 1.6 days per week in 2021, the report found.

    Engineering teams on average in 2021 allocated 35% of their time to growth and innovation, while 19% was allocated to infrastructure work, up nearly 6% from 2020. Time spent on support work (24%), meanwhile, was down nearly 5% year over year. On average, unplanned work accounted for 22% of the time software engineers spent working in 2021, a 3% increase over the prior year. In general, Lau said the report suggests that engineering teams need to factor more time into schedules for unplanned work as application environments become more complex.

    The report also finds engineering organizations using EMPs tend to allocate similar time to “keeping the lights on” and customer support activities as other organizations but spend 29% more time on innovation work and 48% less time on unplanned work. In addition, the report notes teams that devote 50% or more resources to growth and innovation work deliver software at least three times faster than those who commit 25% or less.

    Virtual collaboration in the last year has also increased more than 20% as teams continue to embrace remote and hybrid work models, according to the report. Overall, organizations that allow software engineers to work from home remain productive but it’s not quite clear if managers have completely adjusted to the realities of hybrid work, noted Lau. The report also noted that pull request reviews per engineer are up 30% on average to 1.7 reviews per week. Pull review comments per engineer were up 23% year over year.

    In addition to the report, Jellyfish conducted a survey of 128 engineering leaders that finds more than 79% expect to grow their teams in 2022, with 57% expecting more than 10% headcount growth. Improving operations, tooling and processes (36%) is their highest priority in 2022, followed by hiring and retaining talent (18%), improving infrastructure (17%) and managing technical debt (10%). The biggest overall challenge is making sure everyone is focused on the highest priority work (45%), the survey finds.

    However, only 27% of the leaders currently track productivity metrics, despite more than two-thirds (67%) describing them as being very important or critical to track. Among teams that do track metrics, more than half (53%) do so manually, the survey finds.

    While the productivity of software engineers will naturally vary by organization, it’s apparent the weight of application environments is starting to impact how much time can be devoted to building and deploying new applications. The challenge, of course, is demand for new applications in the age of digital transformation has never been higher, which in part explains why so many organizations are struggling to find and retain software engineers.

  • Checkmarx Finds Malicious Open Source PyPi Repository

    Checkmarx Finds Malicious Open Source PyPi Repository

    Checkmarx, a provider of a platform for testing application security, this week disclosed it has discovered a malicious instance of a PyPi repository for Python code that has been downloaded more than 70,000 times.

    Tzachi Zorenshtain, head of supply chain security, said this discovery represents another instance where cybercriminals have made available a malicious copy of a popular open source software package that contains malware that is destined to find its way into downstream applications. Cybercriminals, via a tactic known as starjacking, create a web page that includes bogus statistics, such as GitHub stars, to make it appear a software package that a developer might download is from a legitimate open source project, he noted.

    Cybercriminals are combining starjacking with typosquatting to set up web pages to mimic a legitimate open source project, noted Zorenshtain.

    Starjacking represents yet another effort to compromise the integrity of software supply chains that rely on a wide range of open source software components to build applications. The only way to thwart starjacking is for either developers or DevOps teams to validate components before incorporating them within applications, noted Zorenshtain. Otherwise, it’s possible malware will only be discovered after it has already found its way into downstream applications deployed in a production environment.

    The challenge, of course, is remembering to take the time to validate the source of any software component. Developers that are typically trying to build applications as fast as possible don’t always stop to make sure that all the components they are employing are from a legitimate source.

    It’s not clear how pervasive fake sites through which developers are encouraged to download malicious software have come to be. However, as cybercriminals expand their efforts to compromise software supply chains, it’s clear their tactics are evolving in ways that exploit the trust developers have in open source software. It’s not likely these attacks will disrupt the open source ecosystem, but they do add additional urgency to make open source software more secure.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to ultimately spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software that is widely employed both inside and out of government agencies a priority by expanding compliance mandates. The White House is also clearly trying to pressure IT vendors and larger enterprises to contribute more to the effort to secure open source software.

    The trouble is many open source projects are maintained by a small number of programmers that contribute their time and effort to building components that others are free to use. Many of them argue the onus for making sure that software is secure is on the organizations that decide to deploy that software. Nor is their responsibility to track down cybercrimimals that employ Typosquatting techniques to distribute malicious versions of their software.

    Many of the IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or just helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are now also assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may now be only a matter of time before a long-simmering open source software security issue erupts into a major crisis of confidence.

  • Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore has made generally available a namesake backend development engine for rapidly building scalable distributed IT environments across multiple cloud platforms.

    Fresh off raising $3 million in seed funding, Encore CEO André Eriksson said the Encore platform analyzes source code to eliminate the need to manually configure, connect and set up portable cloud computing environments.

    In addition to being able to automatically setup and manage cloud infrastructure based on the metadata surfaced by static analysis tools, Encore provides access to a built-in continuous integration/continuous delivery (CI/CD) platform, previews of environments, live reloads of cloud environments, authentication, secrets management and automatic distributed tracing capabilities.

    Eriksson said the development of the Encore environment was, in part, inspired by how developers of games today routinely use an engine to build application environments rather than presenting developers with a set of text-based editing tools to build those environments using low-level boilerplate code that has to be written by developers for each application instance.

    Written in the Go programming language, Eriksson said Encore platform is based on an open source Encore Go Framework that prevents IT organizations from becoming locked into an Encore platform that today can be deployed on Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud services.

    The building and deploying of distributed applications has always been a major challenge. Encore is designed to automate most of the routine tasks that DevOps teams today need to manually perform for each distributed application they support. As the number of applications being deployed across various cloud computing platforms increases, the challenges associated with managing those environments increase. Encore is designed to enable developers to easily build and deploy application code in a way that can be centrally managed by a DevOps team, noted Eriksson.

    It also takes advantage of the concurrency capabilities that the Go language enables to make it simpler to build and deploy distributed applications in a cloud-agnostic manner, said Eriksson. DevOps teams can also employ Go to extend the Encore environment within the boundary of certain limitations, he added.

    Essentially, Encore is making a case for an opinionated distributed computing environment that, in return for less flexibility, promises to make it simpler to deploy complex applications. Eriksson said Encore doesn’t see many DevOps teams looking to deploy distributed applications that span multiple cloud services, but they are being required to deploy more applications on different cloud platforms. Each cloud platform a DevOps team needs to support only serves to make the overall IT environment that much more complex to manage, he noted.

    It’s not clear to what degree IT organizations are ready to embrace a more opinionated approach to managing cloud computing environments. However, the concept of relying on one is hardly new. Platform-as-a-service (PaaS) environments have been employed for years. However, with the rise of microservices-based applications that are inherently distributed, the issue may soon be forced as IT organizations find simply no other way to keep pace with the rate at which applications are being developed and then continuously extended after they are deployed.

  • Blast Radius of GitHub Breach Major Security Concern

    Blast Radius of GitHub Breach Major Security Concern

    The extent to which software supply chains may be compromised in the wake of a security breach disclosed by GitHub may include thousands of organizations.

    GitHub has revealed that unauthorized parties compromised OAuth user tokens maintained by Heroku, an arm of Salesforce that provides a platform-as-a-service (PaaS) environment, and Travis CI, a provider of a continuous integration/continuous delivery (CI/CD) platform. GitHub has since disconnected the third-party applications that were employing those tokens to access repositories but how much any code might have been exfiltrated or, worse yet, modified may not be known for weeks.

    “There’s a lot of directions this could take,” said Mitch Ashley, principal researcher for Techstrong Research, an arm of Techstrong Group, which owns DevOps.com. “This is an attack against an authentication mechanism.”

    In fact, the full extent of the blast radius of the breach may never be known unless every organization employing Heroku or Travis CI platforms discloses whether their software supply chains were breached. GitHub has also yet to provide any timeline for the extent of the breach, so no one affected yet knows how far-reaching an investigation should be launched or how long it could take to discover malicious code that may have been injected into applications, noted Brian Soby, CTO at AppOmni, a provider of a platform that provides visibility into platform configurations.

    “We don’t know yet when this occurred,” he said. “This could have a big blast radius.”

    In the meantime, the GitHub disclosure will only intensify security reviews of software supply chains, which have begun in earnest in the wake of a series of high-profile breaches that started with an incident involving an IT service management platform provided by SolarWinds.

    In the case of the latest GitHub breach, security professionals are surmising that developers hard-coded tokens into applications accessing GitHub to make it easier to access repositories. “Developers are lazy,” said Demi Ben-Ari, CTO for Panorays, a provider of a platform for evaluating third-party security risks. “They like to take shortcuts.”

    Some organizations in the wake of the attack may move to distribute source code across repositories from multiple vendors as part of any effort to better secure their intellectual property, noted Ben-Ari.

    Organizations also may decide to rely on code repositories that are not accessed via the cloud. However, given the need to integrate disparate services across a software supply chain, there is no guarantee that an organization with a repository running in an on-premises IT environment wouldn’t be affected by a similar attack.

    On the plus side, as more organizations become aware of the threat vector employed to compromise the GitHub repositories, the level of awareness for implementing best DevSecOps practices should increase. The challenge, of course, remains bridging the technical and cultural divides that often result in developers not following best security practices when building and deploying applications. However, as the number of incidents continues to mount, more organizations are beginning to appreciate just how easy it is for the code they are relying on to engage customers and suppliers to be tampered with or outright stolen.