Category: Features

  • Contrast Security Adds API Support to Security Platform

    Contrast Security Adds API Support to Security Platform

    Contrast Security has fully extended its vulnerability scanning and runtime application self-protection (RASP) platform to now include application programming interfaces (APIs).

    Company CTO Jeff Williams said the Contrast Secure Code Platform embeds agents directly into code to detect vulnerabilities using a combination of integrated static and dynamic application security testing tools. That approach makes it simple to embed vulnerability scanning and exploit prevention capabilities within a DevOps workflow as an application is built and deployed, he noted.

    In contrast, traditional approaches to application security depend on legacy platforms such as web application firewalls (WAFs) that are deployed by cybersecurity teams to protect applications in a way that doesn’t provide the same level of granular control at the API level, said Williams.

    Contrast Security claims the Contrast Secure Code Platform improves scan times by a factor of ten while fixing defects 45 times faster. It also reduces false positive alerts by being 200% more accurate, the company claims.

    As more organizations start to embrace best DevSecOps practices to better secure software supply chains, many of them are trying to achieve that goal without slowing down the rate at which applications are built and deployed. That approach, however, requires giving developers and DevOps teams the tools needed to build and deploy secure applications without requiring a lot of direct intervention on the part of a security operations team.

    In general, there is also now a lot more focus on API security as more organizations build and deploy microservices-based applications that rely on APIs to interconnect discreet components. Those APIs should be built, deployed and secured by DevOps teams before they are deployed just like any other software component, noted Williams. The current process of building applications is at its core, from a security perspective, fundamentally broken, he added.

    Application security, in general, has always been somewhat problematic. Cybersecurity teams tend to fund the tools and platforms they regularly employ. The assumption is that application development teams will invest in the tools they need to build and deploy applications. Alas, application development teams that have limited cybersecurity expertise assume that cybersecurity teams are securing both the underlying infrastructure and the applications deployed on top of it. As a result, application security is frequently underfunded.

    In the wake of a series of high-profile breaches of software supply chains there are now at least more reviews of application security being conducted. Contrast Security is making a case for securing the entire application, including the APIs, it invokes using agent software that is injected into the application at the time it is constructed.

    It’s not clear to what degree application security issues will be addressed using agent software rather than traditional cybersecurity platforms managed by security operations teams. Responsibility for application security is shifting left toward developers and the DevOps teams that support them, but as long as humans write code, mistakes will be made, said Williams

    The issue, of course, is many of the members of those teams are still focused a lot more on writing code and deploying applications than they are on cybersecurity.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is launching a weekly DevOps jobs report today through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.
    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re committed to providing additional insights into the state of the DevOps job market in the weeks ahead. In the meantime, here are five DevOps jobs for your consideration:

    Indeed.com

    Mayo Clinic
    Phoenix
    Senior MLOps/DevOps Engineer
    $121,701 – $176,446 a year – Full-time

    Dice.com

    AWS – Professional Services
    Anywhere
    DevOps Engineer
    $131,000 Base Pay

    LinkedIn

    Kasisto
    New York
    Director of DevOps
    $160,000 to $180,000

    Monster.com

    University of North Carolina
    Chapel Hill, North Carolina
    DevOps Developer
    $80,000 to $95,000

    SimplyHired

    Tide Cleaners
    Cincinnati (Preferred)
    Senior DevOps Engineer
    $120,000 to $160,000

  • Dynatrace Extends Reach of Application Security Module

    Dynatrace Extends Reach of Application Security Module

    Dynatrace has extended the Application Security Module it provides for its observability platform to protect against vulnerabilities in runtime environments, including the Java Virtual Machine (JVM), Node.js runtime and .NET CLR.

    In addition, Dynatrace has extended its support to applications built using the Go programming language.

    The Dynatrace Application Security Module leverages existing Dynatrace tracing and artificial intelligence (AI) technologies to detect threats in real-time and then apply appropriate policies to automatically secure applications. At the core of the Dynatrace approach to application security is its OneAgent software for application instrumentation, which collects data and feeds it back to an observability platform that includes an AI engine dubbed Davis.

    Amit Shah, director of product marketing for application security at Dynatrace, said by extending the Application Security Module to support runtimes in the most widely adopted programming languages Dynatrace is now providing real-time visibility and vulnerability analytics across the entire application stack, which includes custom code, open-source and third-party libraries, language runtimes, container runtimes, and container orchestrators.

    The Dynatrace platform not only identifies vulnerabilities across each of these layers automatically but also analyzes them to reduce false positives by only surfacing alerts concerning code that is actually running, noted Shah. Without those capabilities, it becomes impossible for development teams to prioritize their application remediation efforts in the absence of any context, he added.

    In general, achieving and maintaining application security will require more responsibility to shift both left and right, said Shah. While it’s critical to discover as many vulnerabilities as possible before applications are deployed it’s also crucial to make it simpler to discover vulnerabilities in runtimes after an application is deployed, he noted. The goal is to enable DevOps teams to employ the same observability platform they are using to manage and optimize applications to also ensure application security, Shah added.

    That Dynatrace approach provides the added benefit of also avoiding the need to convene a “war room” to discover where all the vulnerabilities in those application environments might reside once they are discovered, Shah noted.

    The primary application security challenge organizations face is the rate at which applications are now being deployed. Cybersecurity teams, because of a chronic shortage of talent and expertise, can’t keep pace. As a result, more responsibility for application security is being shifted left toward developers and DevOps teams as well as right toward IT and security operations teams. In effect, application security is finally becoming a team sport within IT organization as cybersecurity teams focus more of their efforts on securing runtime environments, noted Shah.

    It may be a while before that approach has a major impact in terms of reducing the number of vulnerabilities being regularly introduced into application environments. However, as more tools and platforms that specifically address application security are deployed, the overall state of application security will steadily improve.

    In the meantime, however, the volume of attacks aimed at the application layer of the IT stack will, unfortunately, continue to increase as cybercriminals focus more of their efforts on exploiting both now and zero-day application vulnerabilities that are increasing in volume with each passing day.

  • The Rogers Outage of 2022: Takeaways for SREs

    The Rogers Outage of 2022: Takeaways for SREs

    When, eight years from now, folks are creating lists of the top IT incidents of the 2020s, there’s a good chance that they’ll include the Rogers outage of 2022. The failure, which made internet and cellular network service unavailable for more than 12 million users across Canada, was one of the most significant outages in memory, in terms of both the number of affected accounts and the level of service disruption.

    For site reliability engineers, there’s a lot to learn from this incident, from both a technical and a crisis-management perspective. Here’s a look at our main takeaways.

    The Rogers Outage: What Happened?

    Before diving into lessons for SREs, let’s go over what happened during the Rogers outage and what we know about the cause of the incident.

    Rogers is a major telecommunications provider that serves around 12 million customers in Canada. Early on July 8, 2022, it suffered an incident with its infrastructure that made internet and wireless phone service unavailable for most or all of its customers. The outage was so complete that users couldn’t even make 911 calls or withdraw money from ATMs–which means the failure brought down not just ordinary services, but also what you might consider resources that are essential for normal daily life.

    Connectivity was restored for most users within about 15 hours. However, some customers reported continuing disruptions for several days after the beginning of the outage.

    What Caused the Rogers Failure?

    At first, Rogers did not reveal much technical detail about what triggered the incident. A statement attributed to the company’s CEO the day after the outage said that a “maintenance update in our core network … caused some of our routers to malfunction.” But that didn’t explain specifically which type of maintenance update the company was trying to apply, why the update didn’t go as planned or which types of routers were affected.

    It wasn’t until several weeks later, when Rogers submitted a response to questions from the Canadian Radio-Television and Telecommunications Commission, that more technical detail came to light. Rogers explained to the CRTC that, during an update process, the company ran code that deleted a routing filter. It’s still unclear exactly how the bad code made its way into the update routine.

    Lessons for SREs

    For SREs, the Rogers outage is an example of a worst-case scenario. It was an extremely disruptive incident that took a relatively long time to mitigate, at least when you consider how severe the outage was. That’s why SREs should use Rogers’ experience to assess what SRE teams can do to avoid issues like this–and manage them more effectively when they do happen.

    Test Your Updates

    From a technical perspective, one of the biggest takeaways from the Rogers outage for SREs is that you should test updates thoroughly before applying them. If engineers had tested their update routine more carefully, they would presumably have detected the bad code that deleted the routing filter before the deletion actually took place.

    To be fair, Rogers is hardly the first company to experience a major outage due to a bad update. Atlassian, for instance, had a similar issue earlier this year, when a buggy migration process caused a long-lasting outage.

    If you’re an SRE, you don’t want your company to be the next to make headlines when something that should be a simple change, like an update, triggers a massive outage. Test, test and test again before bringing your changes into production.

    Build in Redundancy

    It also seems reasonable to conclude that Rogers didn’t have redundancy built into its infrastructure in the form of backup routers that could take over when the primary routers crashed due to the bad update.

    This is another reminder to SREs about why it’s so critical to avoid putting all of your eggs in one basket or creating single points of failure. Redundancy may cost more, and it may not totally prevent disruptions. But it can make them less severe and easier to recover from. It’s not hard to imagine the Rogers incident being a lot less severe if even just 20% or 30% of its traffic could have been automatically redirected to backup routers. That might have been enough to keep critical services operational, at least.

    Have an External Crisis Communications Plan

    Rogers has received more than a little criticism for not communicating well with its customers during the outage. The company waited hours before releasing an initial statement about the failure. It was not very responsive to media queries early on, and, as noted above, it took several weeks before Rogers finally released technical details about what went wrong (and even then, the details emerged only because of a government inquiry into the incident).

    The lack of rapid, transparent communication probably wasn’t deliberate. We have to believe that Rogers didn’t want to leave customers in the dark. Instead, the slow communication likely reflects the absence of a pre-planned strategy for external incident communication in a situation where Rogers’ own networks were non-operational. Without a communications plan, Rogers presumably struggled to decide which information to share, or how to share it, in the midst of a major crisis.

    If Rogers had a playbook in place for communicating with the public and media about this type of issue before its network went down, it probably would have been able to share information more effectively–and it may not have faced as much of a backlash from customers and regulators.

    Internal communications, at least, presumably were smoother. The company did manage to get service back up for most customers within about fifteen hours, which probably would not have happened if its engineers lacked a means of communicating with each other as they worked to resolve the incident.

    Conclusion

    For SREs, the Rogers outage of 2022 is a lesson in the importance of testing, designing redundant infrastructure and preparing for transparent communications before crisis strikes. While more careful planning in these respects may not have totally prevented the incident, it would likely have at least reduced its severity and mitigated the backlash that Rogers now faces from angry customers and regulators.

  • Cycode Expands Scope of AppDev Security Platform

    Cycode Expands Scope of AppDev Security Platform

    At the Black Hat USA 2022 conference, Cycode this week announced it has added static application security testing (SAST) and container scanning capabilities to its software composition analysis (SCA) platform that is based on a graph database.

    Amnon Even-Zohar, director of product management for Cycode, said the addition of these tools brings to eight the total number of modules that are now integrated with its Knowledge Graph database. Those modules address application security requirements spanning everything from infrastructure-as-code misconfigurations and DevOps pipelines to binary and source code analytics in a way that reduces both the number of false positives being surfaced, he added.

    That approach makes it possible to provide more context to software remediation efforts by pulling data from across the entire software development life cycle rather than focusing solely on vulnerabilities found in source code, he noted. Cycode, for example, can pinpoint where vulnerable dependencies are found in test and production environments, said Even-Zohar.

    A Cycode Pipeline Composition Analysis tool also provides insights into which components enable a vulnerability or security issue, how pipeline components relate to each other and if they are present in runtime environments, he added.

    While there’s a lot of interest in implementing DevSecOps best practices in the wake of a series of high-profile AppSec breaches, many organizations still lack the tools required to secure an application development environment on an end-to-end basis. The Cycode platform leverages the data that already exists in DevOps workflows to enable organizations to better prioritize their remediation efforts and lower the total cost of doing so, said Even-Zohar.

    The goal is to not only enable organizations to shift cybersecurity further left toward developers but also further right by more closely integrating cybersecurity and DevOps teams, he noted.

    The DevSecOps challenge that most organizations are trying to navigate is that, historically, a list of vulnerabilities discovered by cybersecurity researchers is shared with DevOps teams without much context. Developers don’t know which vulnerabilities are most critical or, for that matter, whether the vulnerability identified is actually present within their application environment. SCA tools, in theory, could make it easier to identify, for example, where a Log4j or a shell vulnerability might be found. Graph-based tools take that capability to the next level by making it easier to visualize where any instance of a vulnerability might be found. In the absence of such tools, IT organizations would spend weeks looking for each instance of a vulnerability.

    It may be a while before DevSecOps workflows become commonplace but at the very least there is now more awareness of software supply chain security issues. The Biden administration has also issued an executive order that requires federal agencies to review the security of software supply chains. Many enterprise IT organizations are now following suit. One way or another, application security is going to improve. The only thing that remains to be determined is what impact those improvements will have on the rate at which software can be built and deployed.

  • CloudNativeDay: WASM to Drive Next IT Epoch

    CloudNativeDay: WASM to Drive Next IT Epoch

    WebAssembly (WASM) is poised to drive the next era of development of cloud-native applications that can truly run anywhere.

    Liam Randall, CEO of Cosmonic, a provider of a platform for building and deploying WASM applications, told attendees at a virtual CloudNativeDay event that WASM will be at the core of a new IT epoch that will enable organizations to more quickly build highly portable applications that are not tied to any IT infrastructure platform and more secure.

    WASM, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of WASM as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

    The Cloud Native Computing Foundation (CNCF) is now trying to advance the adoption of a Cosmonic’s WASM runtime that makes it possible to run WASM applications on any platform versus being constricted to building applications that can only run, for example, on Windows or Linux.

    That level of portability will prove crucial as more organizations look to drive application deployments on a wide range of edge computing platforms, noted Randall.

    It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity, it has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

    In the meantime, as organizations continue to review their application development practices to better secure software supply chains, it’s become clearer that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy approaches to application development, it may be cheaper and easier to adopt a new app development method.

    The challenge, of course, is, as always, taking that first initial step away from the inertia of legacy application development approaches.

  • GitHub Brings 2FA to JavaScript Package Manager

    GitHub Brings 2FA to JavaScript Package Manager

    GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

    In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

    Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

    Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

    There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

    GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

    The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

    In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

    The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

    Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.

  • CREST Defines Quality Verification Standard for AppSec Testing

    CREST Defines Quality Verification Standard for AppSec Testing

    At the Black Hat USA 2022 conference, CREST today shared a quality assurance verification standard to improve application security testing. The standard is based on the open source framework defined by the Open Web Application Security Project (OWASP).

    Tom Brennan, executive director for Americas at CREST, said the OWASP Verification Standard (OVS) measures an organization’s ability to execute and deliver assessments related to Level 1 and Level 2 of the OWASP Application Security Verification Standard (ASVS) and OWASP Mobile Application Security Verification Standard (MASVS).

    The goal is to provide a consistent methodology for accrediting companies that provide application security testing services, said Brennan. Ultimately, organizations of all sizes will then be able to require application software providers to pass an OWASP accreditation test rather than testing the security of every application they use, he noted.

    Organizations need to be accredited through CREST Penetration Testing to apply for the OVS program, which requires companies to demonstrate that they can meet the program requirements and execute and deliver Level 1 and Level 2 ASVS and MASVS services. Level 1 determines whether or not applications store or handle sensitive data; that determination then defines whether or not they need the more rigorous controls of Level 2 or 3. Level 1 controls can be checked either automatically using tools or manually without access to source code. Level 2 ensures that security controls are in place, effective and used within the application. In addition, all organizations will need to ensure that their teams have completed CREST’s Skilled Person Register and have each signed the CREST code of conduct.

    CREST is a nonprofit organization that was originally known as the Council of Registered Ethical Security Testers. CREST works with governments, regulators and multinational organizations to improve application security using CREST OVS Mobile and CREST OVS Apps accredited services. It’s becoming more common for organizations to require OVS to better ensure application security in much the same way they require compliance with frameworks such as the System and Organization Controls (SOC) framework, said Brennan.

    OWASP is administered by a separate nonprofit foundation that works to improve the security of software by sponsoring community-led open-source software projects and training application developers. By aligning with OWASP, CREST creates a verification standard to provide a more structured approach to implementing ASVS and MASVS, noted Brennan.

    OVS, of course, is arriving at a time when there is now a much greater focus on software supply chain security in the wake of a series of high-profile breaches. It is apparent cybercriminals have become more adept at discovering and exploiting a wide range of known software vulnerabilities. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to review the security of their software supply chains.

    It may be a while before application testing using OVS becomes routine, but as more organizations embrace DevSecOps best practices to secure their software supply chain it’s clear there is a greater need for application security testing standards. Especially those that organizations can extend versus reinventing the wheel.

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • Open Standards Are Key For Realizing Observability

    Open Standards Are Key For Realizing Observability

    Observability has quickly become a major focus of enterprise DevOps. Yet tool sprawl and complexity can hold some observability initiatives back. The 2022 CNCF Microsurvey on observability trends found that 23% of organizations use between 10 and 15 tools for monitoring, metrics and gathering logging and tracing data. A full 50% also noted that engineers and teams using multiple tools presented a top challenge to observability.

    I recently met with Dotan Horovits, principal developer advocate for Logz.io, to get his take on improving how modern development teams handle observability. According to Horovits, open standards and open source projects are the principal drivers to realizing interoperable observability industry-wide. Below, we’ll consider the issues facing observability and introduce OpenTelemetry, a CNCF project quickly gaining traction to unify telemetry data from various sources.

    Open Standards For The Win

    Although proprietary monitoring agents have a lot of intelligence, they inherently use tight coupling between telemetry generation and the backend storage analytics, said Horovits. This can cause vendor lock-in and lead to formatting variations in telemetry data between toolsets. “The open standards have the power to converge our industry to prevent vendor lock-in, even the playing field, and allow us to get any telemetry for any source,” said Horovits.

    Without an open standard, supporting the evolving suite of technologies at the heart of modern polyglot software stacks is challenging. Organizations constantly add to their tech stack, from SQL to NoSQL, Kafka, API gateways and serverless cloud services, and these modules produce varying data formatted in unique styles. What’s more, companies are typically using more than one cloud vendor, further necessitating the need for a decoupled method to represent multi-cloud metrics. “As soon as your IT stack becomes this complex, there is a need to aggregate all telemetry into one unified observability standard,” explained Horovits.

    Introducing OpenTelemetry

    OpenTelemetry is described as a “high-quality, ubiquitous and portable telemetry to enable effective observability.” Using OpenTelemetry (sometimes abbreviated as OTel), engineers can generate, collect and export metrics, logs and traces. OpenTelemetry works with many popular libraries and is completely vendor-neutral and supported by a rising number of tools in the space. OpenTelemetry was accepted to CNCF on May 17, 2019, and is an incubating project.

    The OpenTelemetry registry boasts hundreds of libraries and plugins to export and transform telemetry data from many different environments, from legacy to contemporary sources. By decoupling the data collection and export process, OpenTelemetry is “one agent to rule them all,” Horovits explained. Of course, he added, vendors who adopt OpenTelemetry may still provide their own logic behind it.

    The Benefits of More Open Telemetry Data

    At the time of writing, live public repository data shows OpenTelemetry is the second-most active CNCF project, behind Kubernetes. So, why is the observability community so excited about OpenTelemetry? Well, for one, the interoperability it affords could equate to efficiency and time savings. “OpenTelemetry gives you the freedom to integrate throughout the stack,” stated Horovits. Part of this is because its open source roots make it a force multiplier. “You can never achieve such vast coverage with closed source as you would with a wide-open community,” Horovits said.

    Arguably, an open telemetry toolset has also become necessary due to the sheer complexity of cloud-native architectures. Most organizations are shifting to a distributed microservices architecture supported by a dynamic, elastic container-based infrastructure. In this world, a single service might span multiple clusters. Therefore, engineers might need to consider clusters, pods, nodes and namespaces when filtering for data.

    In this complex reality, there are many dimensions, multiplying what needs to be monitored. And in general, traditional monitoring systems become ineffective at this level. Tool sprawl and lack of consolidation are problems that arise when trying to cater to many environments simultaneously. Thus, a unified, decoupled observability platform makes a lot of sense.

    Future of OpenTelemetry

    We’ve seen vast adoption from cloud vendors and solution providers around OpenTelemetry. And, the project has been moving swiftly—OpenTelemetry has had a distributed tracing specification released for about a year. The project almost has a release candidate for metrics and one for logs is in the works, said Horovits.

    Beyond that, one feature that Horovits is excited about is continuous profiling, which could help users continuously analyze a function and track usage trends across instances. Another exciting potential development is eBPF. Since it’s language-independent and runs at the kernel level, eBPF could extract observability signals without requiring application-specific hooks or integrations. This could increase support for more environments.

    For more information, you can visit the OpenTelemetry site to peruse the documentation or read up on the feature roadmap for OpenTelemetry. Horovits also gave this helpful presentation on OpenTelemetry at KubeCon 2022.