devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

This DevSecOps Thing Is Real After All

Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.

For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started devopsy.kinsta.cloud in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my! Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

July 8, 2022
Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

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: Spear-phishing causes $540 million loss, a high severity bug in OpenSSL might be “worse than Heartbleed,” and Lennart Poettering is now working for Microsoft. (more…)

July 7, 2022
Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’

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: Linus says next release will support Rust, FBI warns scammers are getting hired in deepfake interviews, and 80% of IBM staff stay at home. (more…)

June 30, 2022
CodeSee Unveils Open Source Hub

CodeSee today launched a free Open Source Hub (OSH) community through which developers can more easily analyze the codebase that makes up an open source software project.

Shanea Leven, CodeSee CEO, said that capability is crucial because making it easier to explore open source codebases reduces the level of effort required for developers to understand where to make contributions.

OSH is based on a namesake visualization tool that CodeSee created. The CodeSee tool makes it possible for developers to see how a codebase has been constructed using graph technologies that scan software repositories and identify components and their relationship to one another. Developers can also use CodeSee to better understand what impact changes to that codebase will have.

In addition to making it easier for developers to discover open source software projects, OSH also enables maintainers and contributors to create personal profiles through which other members of the open source community can see how their efforts have impacted various projects.

CodeSee, as part of OSH, is also providing integration with Discord, an online voice, video and text collaboration service, to make it simpler for maintainers and contributors of open source software projects to collaborate.

Leven said it simply takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the less likely it is a developer will want to take the time required to begin making a meaningful contribution, she noted.

OSH is arriving at a time when maintainers of open source projects are especially looking for help securing open source software. The core issue is that 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. Many of them simply don’t have the time to immediately provide a patch to an application when a zero-day vulnerability is discovered.

Unfortunately, many IT vendors and large enterprise IT organizations benefit from open source code without contributing anything meaningful back to the project—whether in terms of financing or helping open source maintainers find and remediate vulnerabilities. Not every contribution has to be in the form of code, either. Many open source projects simply need help with documentation which, once provided, should free up other contributors to focus more of their time and effort on application security.

It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Even when they do, it’s not easy to onboard a developer to any software development project. It can take months before a developer is actually making meaningful contributions to a project.

Application development, by definition, is now a group effort. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to more easily collaborate when most of them have never actually met in person.

June 29, 2022
Hasura SDK Integrates GraphQL Platform With More Data Sources

At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.

In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.

Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.

Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.

The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.

That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.

GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.

It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.

The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.

In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.

In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.

June 28, 2022
Dynatrace Adds Synthetic Tests to Validate App Experiences

Dynatrace today extended the application release management capabilities it provides to include synthetic tests for validating and assuring user experiences.

Saif Gunja, director of product marketing for Dynatrace, said the user experience validation and user experience assurance (UXA) capability spans everything from application availability and performance to actual engagement with specific features based on the service level objectives (SLOs) defined by a DevOps team.

Dynatrace views application release management as an extension of its observability platform, said Gunja. While application release management has historically been viewed as an extension of a continuous delivery (CD) platform, Gunja said that observability platforms—such as the Dynatrace platform, which is infused with a Davis artificial intelligence (AI) engine—provide the visibility required to better automate the process.

In fact, as DevOps continues to evolve, it’s apparent that CD and continuous integration (CI) are becoming more loosely coupled as DevOps processes mature, said Gunja. Most organizations have yet to implement CD simply because it’s been too difficult to achieve. Each platform that applications have been deployed is unique. Dynatrace provides the foundation for automating application release management via the agent software it makes available to instrument applications, said Gunja.

It’s not clear whether DevOps teams are reevaluating their approach to application delivery, but Gunja noted that much of the interest in the Dynatrace approach is coming from organizations that have already installed the Jenkins CI/CD platform. The number of extensions that have been built and that need to be supported has created a level of technical debt that is unsustainable for many DevOps teams, he noted.

Many IT leaders concluded they would rather allocate more resources to building applications than maintaining DevOps platforms, added Gunja.

Most DevOps teams are committed to ruthlessly automating as many IT processes as possible. Observability has always been a core DevOps tenet in pursuit of that goal. Applications that are not instrumented can be programmatically managed. The issue is that providing observability isn’t enough—DevOps teams need to be able to take actions across the entire software development life cycle based on the data collected by the observability platform, said Gunja.

Obviously, it’s still early days as far as observability is concerned. While application performance management (APM) platforms have been employed for decades, it’s only recently that observability platforms capable of correlating application and IT infrastructure data have emerged. Thanks to the rise of open source agent software, it’s also becoming less costly to instrument IT environments. The challenge, of course, is, as always, deploying and maintaining all that agent software.

Regardless of the approach to observability and DevOps, it’s clear that IT teams will soon have a lot more visibility into their IT environments. The days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. Observability, however, is not an end in itself, but instead is the end of the beginning of a previous DevOps era.

June 28, 2022
ServiceNow Adds Lightstep Notebooks to Visualize Observability Data

ServiceNow today added a visualization tool to its Lightstep observability platform that will make it simpler for DevOps teams to correlate metrics, logs and traces.

Ben Sigelman, general manager for Lightstep at ServiceNow, said Lightstep Notebooks will make it easier for DevOps teams to make sense of the massive amounts of data collected by the observability platform.

Lightstep Notebooks is an extension of the Change Intelligence analysis engine that ServiceNow already makes available within an observability platform it acquired in 2021.

Included with Lightstep Notebooks are a set of ad hoc charts that include access to heat maps and time-series data with trace exemplars using the database at the core of the Lightstep observability platform.

An instantly generated investigative path also makes it simpler to identify the root cause of any issue, and each instance of Lightstep Notebooks can be shared with other members of the IT organization via an embedded link. Finally, 100% of trace data can be retained for up to three days.

Sigelman said the ability to share Notebooks via embedded links will also help bridge the divide between DevOps and IT service management (ITSM) teams that often need to collaborate to resolve an IT issue.

Naturally, the level of collaboration between those teams tends to vary widely by organization. However, as DevOps best practices are more widely embraced, the number of organizations that are trying to achieve that goal continues to steadily increase. Earlier this year, ServiceNow added an incident response offering to orchestrate on-call escalation, group alerts and provide analytics in further pursuit of that goal.

Observability platforms aggregate the collection of logs, metrics and traces in a way that makes it possible for DevOps teams to query that data. The goal is to make it easier for DevOps teams to both identify the root cause of an IT issue and pinpoint any anomalies that might disrupt an application environment. The goal is to eliminate the need to convene a “war room” meeting that requires IT teams to suffer through the painstaking process of elimination to identify the root cause of an issue.

Of course, before an IT environment can be observed, it needs to be instrumented. Thanks to advances in the form of open source agent software being advanced via the OpenTelemetry project managed under the auspices of the Cloud Native Computing Foundation (CNCF), it’s becoming less costly to instrument IT environments. That’s especially critical at a time when more DevOps teams are deploying microservices-based applications that are more complex to manage than legacy monolithic applications. While generally more resilient, the dependencies that exist between the microservices that make up an application can be difficult to identify without the aid of an observability platform.

As a core DevOps tenet, the need for observability and instrumentation has always been apparent. The challenge has been finding the best way to achieve that at an acceptable cost, Fortunately, there is now no shortage of observability platforms. The only remaining issue is to determine which one best fits within the construct of the organization’s defined DevOps workflow.

June 27, 2022
TechStrong Con: Open Source Software Community Needs Security Help

The only way to make significant improvements in the state of open source security is if more organizations that benefit from open source projects commit to making more resources available to achieve that goal.

At the virtual TechStong Con event, executives on an Open Source and DevOps panel called for more contributions from enterprise IT organizations to ensure the integrity of open source software.

Organizations of all sizes now benefit from open source software whether directly or indirectly. Those organizations have a responsibility to participate in the development of that software in any way they can, said Jeffrey Barnes, senior software engineer for Remote Operations, a provider of medical transcription services. “We need to give back to the community,” he said.

Those efforts don’t necessarily have to involve contributing actual code, added Barnes. Many open source projects are in need of documentation and testing help because the number of actual maintainers of the project is relatively small, he noted.

The challenge is that many enterprise IT organizations don’t understand how to participate in open source software development processes, noted Tom Sweet, CIO for Industrial Refrigeration Pros. An organization might download a piece of open source software and then extend it. Rather than continuing to maintain that branch on their own, organizations should contribute that code back to the project to reduce maintainers’ overall IT burden, Sweet said.

“Many organizations are struggling to contribute back,” said Sweet. “It’s an evolution.”

Organizations clearly need to make contributing code back to open source software projects a natural extension of their DevOps workflows. In the meantime, the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects.

The core issue is that 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 the projects and software are secure is on the organizations that decide to deploy that software.

Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities.

It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Many of them assume that open source projects are supported by IT vendors when, in reality, there are many projects that are dependent on the efforts of a small handful of developers volunteering their time and skills.

Many organizations, of course, may soon decide not to employ open source software if it doesn’t have a critical mass of developers working on it. However, in an era where DevOps teams and developers routinely download software, enforcing those policies is going to be problematic. The best thing enterprise IT organizations can do is engage with the open source software community more rather than less.

June 24, 2022
Cloudflare Outage Outrage | Yet More FAA 5G Stupidity

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: Cloudflare suffers another huge outage while the FAA and FCC still disagree over 5G/NR near airports. (more…)

June 23, 2022
What the New OWASP Top 10 Changes Mean to Devs

The open web application security project (OWASP) recently updated its top 10 list of the most critical security risks to web applications after four years. It represents the most radical shake-up since the list was introduced in 2003. The changes will undoubtedly have a big impact on how businesses address application security going forward and how developers and DevOps teams approach their jobs. This article will look at three of the most significant changes that have emerged in the new top 10 list.

New Methodology for Current and Future Threats

This time, OWASP took a more data-driven approach to their research to get better insight into current and future threats. Members provided more than 1.5 million data points on the security threats they see. OWASP categorized the data and assigned an impact score before deriving their overall ranking.

OWASP also included survey data from security professionals about emerging threats. For example, the current incident rate of server-side request forgery (SSRF) vulnerabilities is low, but security professionals consider this attack very serious and expect it to increase significantly in the future. SSRF enables attackers to use vulnerable servers to request and receive data from protected internal sources, which is a very serious risk. So, SSRF became a new category (A10:2021) this year.

With this new methodology, OWASP is now able to offer comprehensive insight into the most serious current and future threats.

OWASP 10 Expands Security to the Left

One key change in the new top 10 list is the inclusion of many categories (e.g, Insecure Design—A04:2021, Software and Data Integrity Failures—A08:2021) that recognize the industry has to start with better application design practices to improve security.

Many application vulnerabilities creep into software because secure design principles are not followed from the outset. In the race for faster app development, corners are being cut. The CI/CD approach to application development is a major contributor to the use of plugins, libraries or software modules of dubious integrity. This problem is getting worse. Businesses must ensure that all their software components are from reputable sources and should use software supply chain tools to check for known vulnerabilities.

Major Ranking Changes due to the Evolving Threat Landscape

Injection attacks, which have been ranked as the number-one risk since 2003, are now ranked number three. While this is welcome news, we cannot claim victory just yet. Your valuable data is still very much at risk from vulnerable apps that allow bad actors to run unauthorized commands and access the sensitive corporate information your business depends on.

Injection attacks have been replaced by broken access control (A01:2021). OWASP reported that in their data set 94% of applications were tested for these vulnerability types and 3.8% showed one or more weaknesses. A staggering amount!

Due to the increased adoption of standardized authentication frameworks which are more readily available and easier to implement, identity and authentication failures (A07:2021) have plummeted in the ranking from number two to number seven as a risk.

This shift demonstrates that as businesses have improved their determination of who can access applications, they have neglected to enforce controls over what an individual user, process or device can do in that application. It is crucial to consider authentication and authorization together for a better security posture.

Lots of Work Ahead to Bring Left and Right Security Together

The 2021 OWASP top 10 list is a big step forward. OWASP’s expansion of security to the left with the inclusion of new categories and significant changes to their rankings will require businesses to revaluate their application security posture. Addressing security earlier in the application development life cycle will likely prevent many of the more common attacks, but businesses must complement this with robust, proven and scalable security protections on the ‘right’ like web application firewalls. It is not just about shift left, it is about expand left. You need both left and right security for a better multilayered security posture.

June 23, 2022