devopsy.kinsta.cloud

Tag: APIs

GitLab Research Shows Security Concerns in DevOps Teams

The threat of breaches is top-of-mind for many DevOps teams, and while security continues to shift left it appears to be a driving force for many decision-makers when it comes to choosing a DevOps platform or other technologies.

These were among the results of a GitLabs survey that also found getting security right is the number one challenge for DevOps teams.

Getting it Right

Among the top reasons respondents said they chose DevOps were better code quality, developer productivity and operational efficiency—cited by 37% of survey takers, followed very closely by better security/more secure applications.

The survey also revealed that 53% of developers said they are fully responsible for security in their organizations, a 14% jump from 2021.

Michelle McLean, vice president at Salt Security, said it is risky for organizations to depend on development teams alone for security.

“Security and developer teams need to collaborate and work together–at every point in the application life cycle–not just development,” she explained.

For example, security teams must bring runtime insights back to development so they can be applied for education and training.

“It’s fundamentally important to choose a DevOps platform that either has security capabilities built-in or that can easily integrate with security platforms to facilitate collaboration by security and DevOps teams,” she said. “Otherwise, organizations run the risk of pushing out unsecured software or introducing other risks into the software supply chain.”

Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, added that an obsolete mantra in the cloud-native community held that security wasn’t a high priority as proper DevOps workflows meant that incremental changes were small and easily deployed.

He said the Log4j and Log4Shell experiences called that philosophy into question with a recognition that security issues can, and do, occur out-of-band from a release or feature and that continuous monitoring for external threats is part of a properly functioning security process.

“By implementing monitoring for new threats, regardless of source or nature, the ability for cloud-native development to quickly issue tested patches becomes itself a security feature,” he explained.

Understanding the Pipeline

McLean pointed out that while there is a growing understanding of security in the pipeline with DevSecOps, it’s not enough.

“This is particularly true, for example, in the case of APIs. Because APIs aren’t just straight code, you must see them being exercised to spot logic flaws,” she said. “You need the ability to monitor them in runtime in order to spot anomalies and find areas where APIs might be exposing critical data. Although developers write APIs, their testing often falls short for security.”

To accurately see what’s going on with APIs, developers need to exercise the API–even in pre-production.

McLean said this is an area where security and development collaboration and integration is essential–APIs underpin a significant portion of the modern economy and the disconnect between security and development teams can have a direct economic impact.

John Bambenek, principal threat hunter at Netenrich, a security and operations analytics SaaS company, added there has always been a delay between the release of new platforms and the awareness that security capabilities for those platforms need to be implemented.

“With cloud-native and serverless technologies, that delay is as short as I remember in my career,” he said. “I greatly prefer the world where everyone at least understands the need for security instead of having to spend time getting buy-in that it matters in the first place.”

He said if you can manage and implement security in a seamless and efficient way early in the development process, it is far easier and cheaper to address issues than addressing them after code has already shipped—and that’s without adding in breach or liability costs.

“You can either fix it in dev or in prod, but you’re going to have to fix it sooner or later,” he said.

McLean noted many organizations are still maturing in their DevOps practices, not to mention their DevSecOps initiatives.

From her perspective, educating developers as to what is expected of them from a security perspective before a line of code is written is key.

“To help increase compliance, we’ve begun to see organizations taking steps to introduce security tooling into their pipeline process and add testing into the build process,” she said.

Then they’ll add a step that triggers an alert for non-compliant builds but won’t prevent the build. Then they’ll add a step that mandates sign-off by the developer that they’ve seen the security alert for a non-compliant build but still won’t interrupt the build.

“In rare organizations with highly mature DevSecOps processes, they’ll fail the build for non-compliance,” she added.

McLean said organizations need to understand what’s realistic given their maturity and risk tolerance and implement controls that match.

They also need to reevaluate those controls to look for opportunities to increase adherence to security policies and other compliance regulations.

Overall, continuing to educate through compliance automation in the software development life cycle (in development, testing and deployment phases) further helps reinforce best practices while ensuring issues are uncovered before they become a risk or technical debt.

Mackey said because DevOps platforms touch the software powering your business, when choosing any DevOps platform, the security of the platform itself and the competencies it enables should always be must-haves.

“In effect, any decision about new software should be based on how it improves the current security capabilities of the business,” he said.

August 30, 2022
Postman Survey: Increased Usage of APIs Results in More Security Incidents

A survey of more than 37,000 developers and application programming interface (API) professionals published this week by Postman, a provider of a platform for developing and managing APIs, suggests that as more APIs are deployed, more organizations are seeing a rise in cybersecurity incidents.

The survey finds more than half of respondents (51%) reporting that more than half of their organizations’ development effort is spent on APIs. About 20% also noted they are responding to API security incidents or breaches at least once a month at their organization. Overall, more than half (52%) said API security incidents occur less than once a year.

Kin Lane, chief evangelist for Postman, said that while a lot of the concerns over API security could be classified as “theater” being put forth by providers of API security platforms, it’s clear there is a need for a zero-trust approach to building, deploying and maintaining APIs.

The bulk of APIs are used primarily to interconnect internal-facing applications and systems, with a subset then used to integrate partners. Only a comparatively small percentage of APIs are externally facing. However, Lane noted many organizations fail to appreciate how quickly an internally facing API can become externally facing over the course of its lifecycle. As such, IT teams need the tools and platforms required to manage and secure APIs as they evolve, he noted.

In fact, nearly three quarters of respondents (72%) said being able to build APIs remotely is very important to them. That would suggest best DevSecOp practices will need to be extended to API development teams that are often working from home.

Despite those concerns, however, a full 89% said Investments in APIs will increase or stay the same over the next 12 months to drive, for example, digital business transformation initiatives. However, the survey also suggests most organizations are still coming to terms with API development and deployment. Only 8% of respondents identified themselves as API-first leaders, which Postman identifies as an elite group that produces APIs faster, deploys more often, has fewer failures and recovers sooner when failures occur.

Lane said the survey makes it clear that while APIs are playing a crucial role in advancing business goals, there is a need for increased visibility as more APIs are deployed across the enterprise. That’s especially critical as more types of APIs employed also continue to expand. Most APIs in use today are based on the REST format, but there are also now APIs based on GraphQL, event-driven architecture and various messaging platforms. None of these newer APIs are going to supplant REST APIs any time soon. Rather, they are being applied to drive additional processes alongside REST APIs, noted Lane.

It’s not clear how many organizations are adopting a design-first approach to building APIs before they write application code, but as more APIs are deployed, the way IT is managed is rapidly changing. Application services are essentially becoming more disposable so long as the API used to expose them to other applications remains stable. In fact, it’s now only a matter of time before most organizations fully appreciate the degree to which their entire IT strategy now revolves around their APIs.

August 19, 2022
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.

August 16, 2022
RapidAPI Adds Tool to Make Building APIs Simpler

RapidAPI today added a free RapidAPI Studio offering to its portfolio that makes it easier for developers to build, consume, manage and monetize application programming interfaces (APIs).

Wade Wegner, senior vice president and head of product at RapidAPI, said RapidAPI Studio, available in beta, makes it simpler for developers to move between design and development, testing and management without losing context.

It is also designed to be slipstreamed into developer workflows by either being accessed via a browser, as a desktop application, a macOS-native application or as an extension to the VS Code tools provided by Microsoft, added Wegner.

That approach also makes it easier for teams of developers to collaboratively work on API projects, he noted.

APIs are foundational to every modern application development initiative. Each microservice included in a modern application has its own API. As a result, the number of APIs—internal and external—that organizations are building and exposing has increased exponentially, especially as the number of digital business transformation initiatives continues to expand. While the bulk of APIs employed today are internally facing, the number of external-facing APIs being employed tends to rise sharply as more business processes become digitized.

Less clear is who within the organization is responsible for managing those APIs after they have been deployed. In some cases, developers assume responsibility for them along with every other component of an application. Developers, however, tend to move on to other projects; DevOps and cybersecurity teams are being tasked with managing, securing and updating APIs. This is part of a larger effort to better secure software supply chains in the wake of a series of high-profile breaches.

Unfortunately, documentation of those APIs has been somewhat lax within many organizations. In many cases, organizations are not even sure how many APIs have been deployed. Many organizations also discover, to their chagrin, that so-called zombie APIs previously abandoned by developers can still be exploited by cybercriminals to exfiltrate data.

At the same time, the management of APIs is becoming more complex. Along with existing REST APIs and legacy web services based on XML, organizations are now deploying GraphQL APIs. The result is a mix of API schemas that require different levels of expertise to manage and secure.

It’s not clear how the increased focus on securing software supply chains might impact API management. However, it’s apparent that cybercriminals are becoming more adept at discovering insecure APIs through which they can exfiltrate data. The challenge organizations face is that it’s not feasible to secure those APIs without first having a framework in place for managing them.
One way or another, an API management crisis will soon come to a head as it becomes even simpler to build and deploy APIs. The only thing that remains to be seen is to what degree organizations will get ahead of that issue before it spins out of control altogether.

July 27, 2022
How DevOps Teams Can Defend Against API Attacks

Remember when ransomware was the main security threat that DevOps teams needed to worry about?

Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

The Preponderance of APIs

Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

From Ransomware Protection to API Protection

You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

Prevent Lateral Movement

Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

Focus on Data Security

Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

Use Behavioral Security Models

Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

Don’t Rely on Perimeter-Based Defenses

Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

Look Beyond the Surface

Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

Conclusion

To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.

July 20, 2022
Connections Matter: Gaining Visibility Into APIs

Digital transformation is at the center of modern enterprise. Yet, as cloud initiatives take shape and the complexity of connecting systems and applications multiplies, the need to tie everything together and automate processes grows. APIs, otherwise known as application programming interfaces, fuel this automation. These small pieces of code—which connect and interconnect clouds, containers, microservices and applications—help organizations compress what used to be years of project development into months or weeks.

As businesses connect functionality—often across companies and service providers—APIs lead to an enhanced user experience. Simply put, they make it possible for much of the magic of the internet to take place, including seamless authentication, data sharing, payments and collaboration.

Today, it’s next to impossible to find an enterprise application that doesn’t rely on APIs. Yet, despite all the gains, APIs can cause plenty of pain. The slow performance or complete failure of an API can lead to an array of problems. These include customers who can’t complete transactions, employees who can’t collaborate through critical apps, and incomplete or incorrect supply chain data.

Today, a typical organization relies on more than 1,200 cloud-based applications and hundreds or even thousands of APIs. For many businesses, 50% to 90% of revenues are linked to APIs. If a system underperforms or breaks, there’s often no way to identify the root cause and fix it promptly. Reputational damage and lost sales often ensue.

When Good APIs Go Bad

It’s important to recognize that the monolithic applications of the past are a vanishing breed. Today’s highly-distributed software and services environment taps a universe of more than 24,000 APIs. It isn’t unusual for a transaction to pass through several cloud containers and across numerous companies en route to the desired outcome. Along the way, these APIs encounter different hardware, code and conditions.

When APIs work well, a process or transaction typically finalizes within milliseconds—and the digital experience usually excels. However, if a page loads slowly, a promotional code doesn’t work or payment doesn’t go through, the odds are high that somewhere along the line something went astray with an API.

For many organizations, there’s no simple and fast way to identify the source of the problem, understand the current impact, and take steps to fix the failure post haste. In fact, it isn’t unusual for several thousand or more failed transactions to pile up before the issue hits IT’s radar and anyone begins to notice a problem. By then, shoppers have likely abandoned shopping carts and sales have evaporated.

Adding to the challenge is the fact that APIs can fail in several ways. Not surprisingly, the number one problem is availability. If the API doesn’t function, the interaction or transaction cannot take place. In addition, an API might perform slowly or erratically, thus delivering highly inconsistent and frustrating experiences for users along with a problem that is difficult to diagnose and fix. Yet another problem is misconfigured or poorly functioning APIs that return incomplete data or the wrong data.

The real-world fallout can be significant. In practical terms, a customer shopping at a clothing retailer’s website may find it impossible to add socks to a shoe order or use one or more payment services. It may be impossible to cash in points from a loyalty program or view delivery information. Broken APIs can disrupt or break shopping carts, customer accounts, supply chain data, collaboration links, security tools, and much more.

Of course, when things go haywire, finger-pointing and conflicts with vendors, business partners and customers often ensue.

Deep Visibility

In today’s API-centric world, detecting problems early and often is critical. What makes the task so difficult is that API transactions do not unfold in a linear way. They bounce across servers and companies—often a couple dozen of them—scattered all over the world. Further complicating things: This routing can change at any given instant.

Identifying specific issues that trigger a problem—traffic bottlenecks, bandwidth issues, code problems and more—requires the right tools. It’s vital to understand how an API-based transaction behaves across a dozen or even two dozen hops and touchpoints that extend through clouds, containers and microservices.

Passive visibility tools, while useful for getting closer to the end-user, do not offer a comprehensive and granular view of events and processes. Today, businesses require broader and deeper observability capabilities that extend across an ecosystem of APIs and into the entire IT landscape—from network to device. It’s vital to understand how customers use websites, apps and other services.

Making Integrations Matter

As organizations delve deeper into clouds and digital interconnectivity, a more nuanced approach that incorporates both passive and active observability is in order. This approach makes it possible to emulate a user journey and quickly identify problem points. A business can detect problems as they pop up—after only a handful of failed transactions—rather than thousands or even tens of thousands of transactions later.

With a best-practice observability and remediation framework in place, an enterprise can establish baselines and triggers for alerts and notifications. It can assemble a complete picture within a single pane of glass and troubleshoot across the delivery chain. Whether the API involves a collaborative task within the organization or a financial transaction that stretches across several companies, it’s possible to view the entire transaction—and experience.

With both passive and active monitoring in place, a business can evolve beyond constant fire-fighting mode. Armed with the information and insight required to make vendors more accountable, businesses ensure they are getting the level of service (SLA) they are paying for. Make no mistake, as digital transformation initiatives accelerate and cloud complexity grows, it’s critical to ensure that APIs, microservices and other digital components are up to speed.

July 11, 2022
The Quest To Unify With GraphQL, The Modern Data API

There is an ongoing trend in enterprise software: Using GraphQL as an aggregation layer to unify access to underlying data sources and REST APIs. Some call this the supergraph, and others refer to it as a meta layer. The idea is that by providing a more consumable layer to a wide range of internal sources, frontend developers are better equipped to access whatever data they need when constructing applications. But the quest to unify all data sources into a single schema doesn’t come without its share of trials.

GraphQL adoption is steadily increasing, with significant large enterprises making up some of the early adopters. For example, Netflix engineers recently shared how one approach gaining traction is “GraphQL microservices (GQLMS) as a backend platform facilitating rapid application development.” As the use of GraphQL increases across a large enterprise, though, scalability and security hurdles present themselves. These include retaining proper authorization throughout multiple layers and mitigating the risks of an inherently open schema.

I recently met with Hasura CEO Tanmai Gopal to discuss why GraphQL should be used as a middleware element to access and expose underlying datasets and APIs. According to Gopal, GraphQL is becoming the data API for modern applications—this could be a massive positive shift. However, the potential downside is around the time involved in integration. Thus, the key will be automating the integration of data sources so that developers and DevOps teams can focus on the apps and services they’re building instead of maintaining the data model itself.

The Underlying Issue: Data Access

“Data access is a bottleneck,” said Gopal. “It needs to be self-service.”

On one side, there are data producers, such as databases, internal services and external SaaS services. On the other side, there are the clients that consume this data, such as mobile apps, web apps, microservices and APIs externalized for third-party developers.

The problem, according to Gopal, is that the link between both sides is increasingly challenging to implement. It takes time to integrate with HTTP-based APIs and parse JSON payloads. The exchange protocols are dissimilar and you must solve for performance issues, caching and concurrency in data access. What’s more, the authorization context must be maintained for all data sources. These issues are exacerbated since not all developers are accustomed to the nuances of maintaining integrations.

Frontend developers want to communicate with a centralized data store, but also need to mix and match various sources. At this point, Gopal explained, a data access layer is necessary to handle the communication between both sides. Such a layer requires some integration automation to truly get APIs to developers at the edge. And it also requires a simple, unified schema—this is where GraphQL comes in.

Solution: A GraphQL-Based Data API

“GraphQL is an absolutely delightful API to consume,” said Rajoshi Ghosh, co-founder of Hasura. “Using GraphQL as a data API can remove a lot of requirements of legacy knowledge of integration systems and how to securely fetch data.”

The concept involves using GraphQL as an intermediary data API—this would consume all sources, whether they are RESTful APIs, GraphQL services, an Amazon Aurora database or a PostgresSQL-style database—and unify them in a more accessible, pleasing construct. To create a unified API over these disparate sources, a middleware solution must map API resources to logical models and methods and add authorization rules to logical models, explained Gopal.

Although GraphQL enables developer agility, it’s the part in the middle that’s difficult to assemble. Building these connectors from scratch requires a lot of relearning and tedium to maintain, Ghosh said. And to truly cater to all data sources, organizations will likely need to craft custom plugins for legacy sources, he added.

Solving Unified Graph Problems

Data-driven initiatives are a common technology goal, but the breadth of data sources is rising. GraphQL can play an important role in uniting these sources and providing flexibility for frontend developers to call precisely what they need. A unified graph is thus a boon for developer experience but will be challenging to set up from scratch.

Arguably, authorization is the biggest challenge when approaching GraphQL as an aggregation layer for multiple APIs. Any system that unifies multiple backend APIs must ensure that only the person with the correct permissions can access underlying data. A unified GraphQL layer must retain granular permissions that are endpoint-centric and unique to the specific caller.

“Most enterprises don’t have a good authorization story,” Gopal said. Implementing authorization for data APIs is hard, Gopal said, as it’s unlike REST where the user ID can literally be specified within the URL request. These kinds of fine-grained attribute level entitlements must be recreated as a policy engine and applied to the graph API as well. For example, Hasura implements authorization by using a token that scopes the entire experience to the particular user.

The Future of Unified API Strategies

Looking to the future of this area, Ghosh noted that frontend stacks are becoming more robust and code in the backend is essentially becoming business logic deployed as serverless functions. And in this new reality of increasing abstractions, the role of modeling experts will likely become more important.

Furthermore, GraphQL must go beyond read-only capabilities to embrace another trend—real-time. Although most GraphQL APIs retrieve persistent data, GraphQL-based data brokers must also evolve to implement streaming, said Gopal, as real-time data and event-based subscriptions are becoming more common.

Today, you probably don’t need to unify all your sources into a unified data model all at once. This activity will likely be relegated to particular business domains or products to help them accelerate and demonstrate a proof-of-concept. But in the coming years, there will be mounting pressure to adopt a unified approach, Gopal said. “In a few years, if you don’t have a unified API strategy, you’ll have a massive problem.”

July 11, 2022
Supergraph: One GraphQL Schema to Rule Them All

GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

Microservices Enable Composability

First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

The Need for Aggregation

As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

What is Supergraph?

Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

Repercussions of ‘One Graph to Rule Them All’

Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

Supergraph: A Graph of Graphs

Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

“GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

June 21, 2022
Hasura Adds Join Capability to GraphQL Engine

Hasura today announced it has extended its GraphQL engine to make it possible to join data generated by multiple sources.

Hasura CEO Tanmai Gopal said GraphQL Joins makes it possible to join data from across different GraphQL services that can then be accessed via a single GraphQL application programming interface (API). The extension of the federation capabilities enabled by the Hasura GraphQL engine eliminates the need for custom code that would otherwise be required to join that data, he added.

The Hasura engine automatically generates a GraphQL schema from a data source that can then be used to accelerate the development of APIs. GraphQL Joins extends that federation capability to now include multiple GraphQL and, eventually, other data sources accessed via, for example, legacy REST APIs, said Gopal. That capability will make it easier for a wider range of developers to build applications that aggregate data across multiple sources, he added.

The core Hasura Engine is based on open source software that the company claims has now been downloaded more than 500 million times. Hasura makes available a cloud service based on that core engine. 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 that internal IT teams need to support, noted Gopal.

GraphQL was originally created by Facebook, and 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. Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with access to backend services via a GraphQL API can employ the Hasura Engine to automate that process.

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 range of types of APIs to support multiple digital business transformation initiatives that an organization may have simultaneously launched. In addition to building APIs, many of those organizations are now consuming data via APIs exposed by another organization. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex. The good news is that APIs make it easier to upgrade—and even replace—backend services without disrupting application services.

It’s not always clear, though, who within IT organizations will manage those APIs. They are often created by developers that then look to IT operations teams to maintain them. Before too long, it’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands, of REST and web services APIs—and soon, that may include many built using GraphQL.

April 28, 2022
Securing APIs at the Speed of DevOps

In the 2021 State of DevOps Report, 83% of IT decision-makers told Puppet that their organizations were in the process of implementing DevOps practices to improve the quality of their software, the speed of their delivery and the security of their systems. Those DevOps organizations varied in their stages of evolution, however. For example, respondents in the middle stages of their journey reported that culture blockers such as unclear responsibilities and insufficient feedback loops were making it difficult for them to continue their DevOps journeys and join the ranks of high-evolution organizations. Such obstacles help to explain why 97% of high-evolution organizations had already applied automation to their competitive tasks compared to just two-thirds of mid-level and a quarter of low-evolution teams.

The Importance of APIs to DevOps

The prevalence of automation ties into the importance of application programming interfaces (APIs) for any organization’s DevOps journey. In the words of IBM, an API “enables companies to open up their applications’ data and functionality to external third-party developers, business partners and internal departments with their companies.” APIs, therefore, enable the services and products of different companies to communicate with one another in a way that streamlines and/or augments functionality for the user.

That said, users aren’t the only ones who benefit from APIs. DevOps teams do, too. Many of these team members deal with increasingly automated processes as part of their daily tasks, so they need APIs that can help them to deploy and configure their infrastructure. APIs can also help DevOps teams gain detailed information about an app during runtime. DevOps staff can use these insights to proactively address issues before they lead to disruption.

Security Obstacles of APIs and DevOps

Despite their benefits, APIs and DevOps aren’t without their security challenges. Contemporary Computer Services, Inc. (CCSI) identified several security hurdles that organizations may encounter along their DevOps journeys. These include the following:

A fast development process: DevOps introduces a faster speed of software delivery. In their efforts to keep up with this demand, developers might make coding mistakes that leave applications vulnerable to attack. Absent a timely security review, those vulnerable products and services might make it into production, granting attackers an opportunity to exploit the flaws and to try to access affected customers’ digital assets.

Poor collaboration: No DevOps journey will succeed without collaboration between development and operations. When there’s a lack of joint processes, these teams may stick to their silos. This way of working may leave security gaps if development and operations aren’t communicating about the management of their credentials, tokens, SSH keys and other secrets, for example.

Those security challenges can then spill over into APIs. The speed of development along with poor team communications may give rise to multiple versions of the same API. This redundancy contributes to a sense of what’s known as API sprawl, a phenomenon where the number and reach of organizations’ APIs grow exponentially. API sprawl comes with its own obstacles including maintenance difficulties and broken clients, issues that provide attackers with more opportunities for infiltrating the organization’s systems. This reality helps to explain why 91% of enterprises experienced an API security incident in 2020 and why malicious API traffic increased by 300% in the middle of 2021.

How Can Organizations Address These Security Challenges?

For an answer to this question, we look back to what highly evolved DevOps organizations are doing. Most organizations are focusing on DevSecOps. In Puppet’s report, 51% of respondents said that they are integrating security into their DevOps requirements, with even more saying the same about design (61%) and build (53%). An additional 52% of survey participants indicated that they’re bringing security into their testing. By contrast, mid- and low-evolution organizations mainly engaged in security when they were in the process of preparing for an audit of their production systems or when they learned of an issue affecting production.

Beyond those areas of focus, organizations need to emphasize runtime protection. Salt Security agrees with this statement, noting how organizations need to “security test your APIs, but know that you will also need runtime protection to catch changes that don’t go through standard build process and abuses that testing tools aren’t designed to find.”

Finally, organizations need to treat DevSecOps as the cultural change that it is. They can do this by assigning security responsibility to one person from their DevOps team. Doing so will help to ensure that teams won’t overlook security during their jobs. Simultaneously, organizations can conduct security awareness training for their developers and regularly invite both development and operations to share their stories, priorities and successes with one another. This will help to foster collaboration, thereby minimizing instances of API redundancies and API sprawl across their systems.

March 23, 2022