devopsy.kinsta.cloud

Category: API

SmartBear Extends Scope of API Lifecycle Management Ambitions

SmartBear today added capabilities to its platform for designing and managing application programming interfaces (APIs) that make it easier to both keep track of them and detect drift.

A revamped Swagger Catalog, in addition to providing a unified view of APIs, also makes it possible to govern them.

At the same time, SmartBear is adding Swagger Contract Testing with drift detection that verifies the API is behaving as specified in a contract.

Additionally, SmartBear later this quarter plans to revamp its API editor along with artificial intelligence (AI) tools for generating APIs, a context-aware ability to create documentation, Spectral-based governance enforcement, a Model Context Protocol (MCP) Server and expanded multi-protocol support, including OpenAPI 3.1. AsyncAPI 3.0, and GraphQL.

Laura Kennedy, director of product management for SmartBear, said both additions extend the API lifecycle management capabilities of the company’s platform.

For example, Swagger Catalog combines centralized visibility, automated governance and policy enforcement that spans API design to the runtime environment, noted Kennedy.

Swagger Contract Testing with drift detection continuously verifies that real API behavior matches OpenAPI contracts to ensure that business logic in the API hasn’t been modified, she added.

API lifecycle management issues are coming to a head now more than ever because AI agents are dependent on them to access data. The challenge is that not only are there more types of APIs than ever, but they are also being updated more regularly after being initially deployed. As a result, there is a much greater chance that an API is likely to have been misconfigured.

More challenging still, it is also more likely that as the pace of application development accelerates, it becomes more likely that a rogue API will have been deployed that no one in IT is aware exists. In the absence of any visibility, it’s also probable that the API is fundamentally insecure.

Finally, there are also zombie APIs that, after being created, are no longer being updated and maintained. Those APIs then become prime targets for cybercriminals looking to exploit any API weakness they can discover.

It’s not clear to what degree software engineering teams are proactively managing APIs. However, as the sheer number of API strewn across the enterprise only continues to increase, it’s only a matter of time before the issue is forced.

In the meantime, DevSecOps teams especially should be at the forefront of creating an inventory of APIs. While the bulk of APIs tend to be internally facing, it’s not uncommon for an API that no one ever thought would be exposed to the internet to have, for one unexplained reason or another, been made accessible.

Ideally, APIs should be just one more software artifact to be managed and secured within the context of a larger DevOps workflow. The challenge, as always, is finding a way to keep track of who created which API for what business purpose. Any API that exists without that level of credible explanation warrants immediate further investigation.

April 15, 2026
Survey Surfaces More Focus on Software Security Testing and API Security

A global survey of 828 enterprise IT professionals conducted by the Futurum Group finds well over a third of respondents expect their organization to increase spending on software security testing (39%) and application programming interface (API) security (36%) over the next 12 to 18 months.

Overall, about 35% said they also plan to make some type of investment in application security, the survey finds.

Mitch Ashley, vice president and practice lead for software lifecycle engineering for the Futurum Group, said the survey results suggest more organizations are starting to appreciate how much the actual velocity at which software is successfully built and deployed now depends on how well security is encoded into workflows, APIs, and, ultimately, artificial intelligence (AI) agents.

In general, guardrails are replacing gates as security policies are becoming executable, enforced continuously by pipelines, platforms, and increasingly AI agents, said Ashley. The fastest teams will not be the ones that bypass security, but rather the ones that make it invisible by design, he added.

The payoff is fewer late-stage surprises, less rework, and more predictable delivery in AI-accelerated development environments, said Ashley.

The depth to which best DevSecOps practices are adopted still varies widely from one organization to the next. Unfortunately, the volume of code being generated in the age of AI only continues to exponentially increase, with much of that code containing known vulnerabilities that were not discovered, if at all, until just before code is promoted into a staging server. A full 60% of respondents said their organization is now actively using AI to build and deploy software, the survey finds.

Hopefully, there will come a day soon when AI agents are able to identify and remediate vulnerabilities created by AI coding tools, but in the meantime many DevSecOps teams are simply being overwhelmed by the amount of code that needs to be scanned and remediated.

It’s not clear to what degree it might take a major application security incident that is directly attributable to code generated by an AI tool to motivate more organizations to more consistently apply best DevSecOps practices. Until then, however, DevSecOps teams should expect there will be more application security incidents in the months ahead that will require some type of patch to be rapidly built and deployed.

For now, application developers need to be cognizant of the vulnerabilities they might be inadvertently adding to a code base. If a vulnerability is discovered just prior, or worse yet after, an application is deployed the cost of resolving those issues is considerably higher. In fact, all the investments made in DevOps tools and platforms to accelerate deployment can be easily negated if the quality of the code being generated only serves to increase the amount of rework that needs to be done.

There is, at this point, no way that AI coding tools are going back in the proverbial bottle. The challenge and the opportunity now is to determine how best to ensure the quality of the code being generated at the very least meets, or hopefully exceeds, the quality of the code being generated by human developers without any help from AI.

February 4, 2026
Cursor Acquires Graphite to Streamline AI-Powered Development

Cursor, the artificial intelligence (AI) coding assistant valued at $29 billion, has acquired code review startup Graphite to address what Cursor CEO Michael Truell describes as a growing bottleneck in software development.

The companies declined to disclose financial terms but confirmed the transaction involves a mix of cash and equity.

While AI has dramatically accelerated code writing, the review process has remained largely unchanged, consuming an increasing portion of engineering teams’ time.

“Over the past 2.5 years, Cursor has made it much faster to write production code,” Truell said in a statement. “However, for most engineering teams, reviewing code looks the same as it did three years ago.”

Graphite, founded nearly five years ago, raised $52 million in a Series B round in March. The startup serves tens of thousands of engineers at more than 500 companies, including Shopify Inc., Snowflake Inc., Figma, and Perplexity AI.

The accord brings together complementary tools in the AI development workflow. Cursor helps programmers write code through natural language prompts and intelligent suggestions; Graphite specializes in reviewing those changes and determining when code is ready to ship.

A key feature of Graphite’s platform is “stacked diffs,” which lets developers submit code for review and immediately begin working on the next module rather than waiting for approval. This eliminates traditional bottlenecks where engineers must wait for one piece of code to be reviewed before starting dependent work.

Graphite’s AI-powered review tool also catches cybersecurity vulnerabilities, performance issues, and ensures code complies with company-specific formatting guidelines and documentation requirements. The platform provides customizable dashboards and keyboard shortcuts to speed up the review workflow.

Both products will continue operating independently in the near term, with deeper integrations planned throughout 2026. Lutsky emphasized that Graphite’s brand and product aren’t going anywhere, but the company now has significantly greater resources to enhance its offerings.

The deal comes just one month after Cursor announced it had reached $1 billion in annualized revenue and marks the company’s third acquisition. Cursor previously bought AI coding assistant Supermaven in November 2024 and acquired talent from enterprise startup Koala in July.

The acquisition positions Cursor aggressively in an increasingly competitive market dominated by OpenAI, Anthropic, and GitHub Copilot. However, Truell downplayed concerns about competition from major AI labs, noting that Cursor’s strategy focuses on combining the best available models with proprietary technology and superior user interface design.

Looking ahead, Truell said the company has no immediate plans for additional acquisitions or an IPO, instead focusing on product development as it pursues its ambitious vision for the next decade of automated coding.

December 20, 2025
7 Critical API Protection Strategies to Fortify Your API Security
API security isn’t just good practice — it’s a necessity. As businesses increasingly rely on APIs to power everything from mobile applications to cloud services and IoT devices, these digital interfaces have become the new perimeter — and the new target for sophisticated attackers.

The question isn’t if an attack will happen, but when. A recent analysis by Treblle (2024) has revealed a startling reality — over half of API requests analyzed in 2023 used no encryption whatsoever, leaving sensitive data exposed to interception. What is even more concerning is that 52% had no authentication mechanisms in place — essentially leaving the digital front door wide open. Furthermore, 85% of APIs had not implemented rate limiting, making them vulnerable to brute force attacks and service disruptions.

These vulnerabilities aren’t just theoretical concerns. High-profile breaches like the one experienced by BeyondTrust in late 2023, where API key exposure led to significant organizational damage, have demonstrated the real-world consequences of inadequate security. With APIs continuing to proliferate and organizations deploying hundreds or even thousands across their ecosystem — the attack surface is expanding dramatically.

Compounding the problem is the rise of ‘zombie’ APIs — APIs that remain accessible but unmaintained. Treblle’s analysis found that a staggering 35% of endpoints fell into this category, creating significant blind spots in security postures. Without proper documentation, oversight or regular updates, these forgotten interfaces become prime targets for attackers seeking the path of least resistance.

Against this backdrop of escalating threats and costly consequences, organizations need a comprehensive, multilayered approach to API security. Let’s explore seven critical protection strategies that can help secure your APIs against emerging threats.

#1: Encrypt Your API Traffic

TLS Certificates Are Free — So Use Them!

While HTTPS might seem basic, data shows a shocking reality — 55% of the API requests analyzed hadn’t used any encryption (Treblle, 2024), meaning sensitive data was transmitted in plaintext, which is vulnerable to interception.

Even if the topic feels a little arbitrary to mention, we should first and foremost prioritize encrypting the traffic leaving or reaching the gateway.

Protection Levels:

1. Manual Certificate Management: Suitable for organizations that purchase extended validity certificates from authorities.

2. Automated Certificate Management: Using solutions such as Let’s Encrypt with the ACME protocol.

3. Self-Hosted Private Key Infrastructure: Managing your own PKI with ACME-compatible tools such as HashiCorp Vault.

Remember, even internal APIs deserve dataflow encryption. There is no excuse for internal APIs to be left unsecured. Leverage wildcard certificates to protect subdomains that are only resolvable through an internal DNS server.

#2: Enforce Strong Authentication & Authorization

Data from Treblle revealed that 52% of analyzed requests had no form of authentication in 2024. This number represents a massive vulnerability surface. Even internal infrastructure isn’t immune to threats. Recent breaches, such as the one experienced by BeyondTrust, have demonstrated that API keys can be compromised with devastating effects.

Unauthenticated API calls should be the exception — a deliberate choice of not implementing authentication. Everything besides this exception should have authentication.

The best approach starts with an identity provider as the foundation layer for proper API governance, with related authentication methods such as JWT, OIDC or OAuth2 building upon it.

#3: Protect APIs From Abuse & Overuse

Avoid Service Disruptions, Protect Performance, User Trust & SLAs

Despite the fundamental role of rate limiting in API security, a surprising 85% of analyzed APIs had no rate limits in place, leaving them vulnerable to denial-of-service attacks and excessive usage (Treblle, 2024). This widespread oversight exposes systems to severe disruptions, impacting both operational stability and user experience.

There are several layers of protection available to prevent such vulnerabilities, including:
- IP Address Filtering: This method restricts access to specific IP ranges, ensuring that only trusted sources can make requests.
- Parallel Request Limitation: By controlling the number of concurrent requests from a single client, systems can prevent overloads and maintain optimal performance. This is particularly useful in fighting web crawlers or DoS attacks.
- Request Flow Control: Implementing true rate limiting with token bucket algorithms helps manage request rates effectively, thereby preventing abuse.
- Distributed Rate Limiting: This approach shares rate limit counters across gateway replicas, ensuring consistent enforcement of limits even in distributed architectures. Every replica sees the same counters, enhancing security through coordinated rate limiting.
By leveraging these layered protections, organizations can significantly improve their security posture, reducing the risk of service disruptions and safeguarding user trust.

#4: Block Known Vulnerabilities

Configure a Web Application Firewall (WAF)

A web application firewall (WAF) is crucial for defending against known attack patterns, including SQL injection and cross-site scripting. Beyond protecting sensitive data, a WAF is also essential for maintaining regulatory compliance, such as PCI DSS requirements.

Traefik Labs utilizes an open-source core for its firewall, which has OWASP endorsement, ensuring industry-standard protection against the latest threats. Deploying a WAF is relatively straightforward, often requiring just a few lines of configuration, making it an accessible yet powerful mechanism for enhancing security.

#5: Apply Zero-Trust for Accessing APIs

Avoid Data Leaks With the Least-Privilege Principle

Rather than providing unrestricted access to entire APIs, a zero-trust approach restricts access to specific endpoints and methods, enhancing security by enforcing least-privilege access, significantly reducing APIs’ attack surface.

By defining granular access rules, you can control exactly what clients can access, even as your APIs evolve. This ensures that newly deployed endpoints are not automatically exposed, minimizing the risk of unauthorized access.

#6: Centralize Secret & Key Management

Protect API Keys for AI/LLM APIs

With the growing reliance on external services, particularly AI and LLM services that require API keys for access, centralizing API key management has become crucial. These keys are powerful, and if compromised, can allow unauthorized users to exhaust tokens, deplete account credits or even drain linked bank accounts.

The most effective solution is to store credentials centrally and issue short-lived tokens to end users. These tokens can be easily revoked, minimizing the impact of compromised keys. By implementing this gateway pattern, organizations can prevent the direct exposure of valuable API keys, ensuring better security and control.

Centralized API key management not only safeguards sensitive data but also streamlines the administration of access credentials.

#7: Avoid Zombie & Shadow APIs

Only Expose What’s Documented in Your OpenAPI Specification

One of the most alarming findings showed that 35% of API endpoints were ‘zombie’ endpoints — accessible but unmaintained and potentially vulnerable (Treblle, 2024).

Organizations are becoming increasingly vulnerable to threats due to unmaintained APIs. Use OpenAPI specifications to define legitimate endpoints and block everything else. Even for legacy systems without documentation, observability tools can help build specifications from observed traffic. You can block undocumented endpoints by flipping one single configuration value.

Bonus Tip: Implement Comprehensive Observability and Reduce Downtime Dramatically

While not directly a security control, observability provides the visibility necessary to identify potential threats and respond quickly.

Without this measure, you will not see if request rates spike up, error rates spike up or an IP address bombards your infrastructure. By implementing OpenTelemetry for metrics, tracing and logs, organizations can identify potential security incidents and correlate them with changes to systems. This visibility is essential for effective incident response.

Taking a Multilayered Approach

No single security measure is sufficient on its own. To effectively safeguard APIs, organizations should adopt a multilayered security strategy, integrating multiple protective mechanisms. Each layer — be it rate limiting, WAF, zero-trust, centralized key management or observability — provides unique benefits that collectively enhance security posture.

These measures are designed to work together, reinforcing each other to create a robust defense system. By implementing this comprehensive approach to API security, organizations can significantly reduce their risk profile, protecting their data and systems from emerging threats.

The multilayered strategy ensures a resilient and secure API environment, safeguarding business operations and maintaining user trust. Click here for more information.

KubeCon + CloudNativeCon EU 2025 is taking place in London from April 1-4. Register now.
March 3, 2025
Modern Application Management Requires Deeper Internet Visibility

Most IT teams regularly employ a range of tools to monitor application performance. But in an era where applications are running everywhere from the cloud to the network edge, the visibility being provided is limited. The metrics and analysis being surfaced are roughly akin to only being able to see a few yards ahead when driving a vehicle on a rainy night. Managing modern applications instead requires platforms that provide the equivalent of radar and sonar capabilities, so that IT teams have better visibility into application environments that today remain far too shrouded to effectively manage.

Achieving that goal requires a deeper insight into how various Internet services impact application performance. Just about every application depends on the quality of one or more of those services. The more application services that depend on the Internet, the more probable it becomes that someone will encounter issues intermittently impacting performance in ways that are difficult to understand, much less predict.

Unfortunately, most IT teams today have limited ability to discern how the performance of Internet services is impacting their applications. There are, of course, Internet performance monitoring (IPM) tools capable of surfacing network performance metrics. The challenge and opportunity now is to surface those metrics in context with all the other telemetry data that DevOps teams collect from the various application performance management (APM) and observability platforms they rely on to monitor and troubleshoot application environments.

Why Applications Are Becoming More Distributed

First, with the rise of cloud computing followed by the proliferation of software-as-a-service (SaaS) applications and now the rise of edge computing, applications are becoming more distributed with each passing day. The challenge is that each application is invoked across a network that adds latency, and existing APM and observability platforms cannot effectively analyze it.

The pace at which applications are becoming more distributed is only going to increase. More data is being processed and analyzed at the network edge as organizations deploy near real-time applications. Instead of transferring raw data to the cloud, these applications process and analyze data at the point where it is created and consumed. It’s only then that an application either streams or passes the aggregated results to a cloud service or to an on-premises IT environment for further analysis.

Most DevOps teams, however, lack visibility into how Internet services impact more highly distributed applications, beyond the cloud service or on-premises IT environment where they historically deployed their applications.

Internet Blind Spots

Broadly, there are three major classes of blind spots that impact distributed application performance. The first and arguably most opaque are the services provided by third-party vendors. Ranging from content delivery networks (CDNs) to software-as-a-service (SaaS) application, each of these services is controlled by an external service provider that typically doesn’t allows a DevOps team to collect telemetry data by deploying agent software in their IT environments. At best, they may expose an application programming interface (API) to enable an agentless approach to collecting data, but that method doesn’t typically provide the level of control required to optimize application performance.

The second major blind spot is at the device level. Configuration errors in browsers can have a significant impact on loading times that adversely impacts application performance, for example.

Finally, various platforms and protocols ranging Domain Name Servers (DNS) to publish-and-subscribe services can impact applications in way that an APM or observability platform isn’t going to detect.

The only way to provide the level of visibility required is to leverage an IPM platform that collect telemetry data from a global network, made up of thousands of points-of-presence (PoPs) to determine precisely what level of Internet service is delivered to any given end point.

Context and Control

Integrating the telemetry data collected via an IPM provided DevOps teams with a context to better troubleshoot distributed applications. Instead of wondering if a certain piece of code is to blame, a DevOps team can immediately determine whether Internet traffic moving through a specific location is either creating additional latency or blocking access altogether.

Armed with those insights, the team can contact then Internet services provider to address the issue or, if necessary, reroute via another service to ensure application availability.

Regardless of approach, the days when DevOps teams found themselves subject to the vagaries of network services, over which they had little to no influence, are coming to an end.

DevOps Meets Netops

The integration of IPM and APM or observability platforms creates a foundation upon which best practices for managing network operations (NetOps) and DevOps can finally be melded. Instead of having to convene “war rooms” to uncover the root cause of an issue, both teams will instantly be able to visualize to what degree networking services might be adversely impacting networking services. All that time spent guessing what the cause of a problem might be can now be allocated to remediating the issue.

In an era where applications have never been more dependent on networking services, the need to converge the management of NetOps and DevOps workflows has never been more critical.

Conclusion

Most DevOps teams know all too well there are often major discrepancies between what DevOps teams relying on APM and observability platforms believe and what is actually occurring in a distributed computing environment. The challenge is that they typically lacked the visibility required to determine what best course of action to address the issue. As IPMs become more integrated with APM and observability platforms, network blind spots that previously made discovering the root cause of an issue will soon be all but eliminated.

Of course, each DevOps team needs to determine to what degree gaining those insights is a priority. However, given the number of issues DevOps teams are trying to resolve that can be traced back to an Internet service, it’s clear the overall level of stress and toil DevOps teams regularly encounter could be greatly reduced by simply providing more networking visibility into those services.

April 5, 2024
Smoothing API Onboarding With Simulation and Documentation
“Soon we’ll be making another run…And love, exciting and new, Come aboard, we’re expecting you…”– Theme from The Love Boat, American television program, circa 1977

If software is eating the world, then APIs are eating software. Investment in the API economy is increasing. More than 200 million APIs are already out there in the world, and more than 24,000 are publicly available as of 2022, and surely these figures have only skyrocketed since then.

APIs were supposed to ease the journey of creating innovative new features and services within internal and external-facing applications, while making integration smooth sailing.

Unfortunately, leveraging API services within your own application development process often feels less like stepping onto the welcoming deck of The Love Boat, and more like getting marooned on an island for the next season of Survivor.

Developers want to build functionality that delivers the maximum business value—with a minimum of effort—so don’t leave them stranded when they are trying to consume APIs.

Barriers to API Onboarding

The process of adding some API calls to an application seems quite simple in comparison to the old days of web services and integration buses. A provider publishes an API with a Open API spec, and developers connect to it. Unfortunately, onboarding seldom works out that simply for several reasons:
- Poor documentation. While there may be a Swagger or Postman file sitting there for reference, chances are the documentation isn’t updated as often as the API, nor does it provide helpful instructions or code samples that help developers structure their own calls.
- Inconsistently available sandboxes. All too often, there isn’t a reliable way to try out the API, thereby wasting developer’s time and impacting quality. Further, sandboxes are hosted in temporary instances or unscalable architecture that can lag or go down at any time. Complex test scenarios like load testing or negative testing may be disallowed or rate-limited, and teams may have scheduling conflicts over a limited number of sandbox environments.
- Poor maintenance. Test API environments are often poorly maintained, and further, API producers don’t usually update test instances or inform developers about changes and downtime until after the events have already passed.
- Downstream dependencies. Any published API may have known or unknown downstream connections to other data services and API that can change or interfere with business logic or availability.
Simulating Success With API Mocking

Developers need a great onboarding experience to successfully make that first successful call, and then they need support on a continuous basis as they productively incorporate APIs into their app.

DevOps methodologies recommend automation at every stage of the continuous delivery pipeline, with “shift left” early testing and validation of all components that will make up the finished application. That’s certainly helpful, but for API development in particular, a lack of ready sandboxes leaves developers doing the cumbersome work of prototyping test APIs for early consumption, when they would rather spend their time developing and testing features.

The practice of API mocking allows developers to simulate the stateful behavior of a responsive live API service, even if the producer of that service hasn’t yet provided a live version or test environment.

The WireMock Cloud solution provides an on-demand environment with sophisticated API mocking that can be generated from specifications, Swagger definitions or even from live service traffic. The resulting mock API instances are addressable just like live production APIs, but because they are hosted in a stable multi-tenant cloud environment, they often prove to be ‘better than the real thing’ in terms of availability, performance, and predictability.

In essence, a mock API automatically represents a solid reference documentation, with an accompanying OpenAPI spec of the producer’s target API. It also makes every API consumed by developers more modular, because teams can consume and share the mock API assets and specs when collaborating on contract tests and reproducing results.

Where to start? Just create mocks and embed them in your developer portal, so every API also has a matching prebuilt mock. With this packaging, API mocks can be used as a smart, reliable sandbox which will improve the onboarding developer experience for APIs in your developer portal.

The Intellyx Take

Who wants to build more APIs, and maintain additional sandbox infrastructure, just to test APIs?

The most valuable resource of any developer is time, so don’t give them a frustrating reason to jump ship before they’ve even onboarded. API mocking simulates production APIs and provides useful documentation, in a ready-to-consume environment developers will love.

API mocking allows teams to work in parallel, eliminating constraints and returning time to every turn of every development cycle. It’s all smooth sailing from here!

©2024 Intellyx B.V. Intellyx is editorially responsible for this document. No AI bots were used to write this content. Image source: Adobe Express AI. At the time of writing, WireMock is an Intellyx customer.
April 2, 2024
7 API Observability Anti-Patterns to Avoid
Observability has become a buzzword, and the API world is slowly catching up. But be careful when looking for content about API observability- there are many outdated best practices and irrelevant pieces of content.

I was recently invited as a guest to Stephen Townshend’s SlightReliability podcast, and his brilliant blog post on “Bad Observability” inspired me to start ranting about the topic.

Here is a follow-up to our discussion: The observability anti-pattern to avoid when working with APIs. Thanks, Stephen, for the inspiration!

Anti-Pattern: You Forgot Your Users

It’s easy to lose sight of the fact that APIs are built for people to use. APIs are not just a technical interface; they are a bridge that connects digital experiences and enables people to accomplish tasks efficiently.

There are two different kinds of users for your API:
- The developers who are integrating your API into their system.
- Your customers’ users, who will ultimately interact with the applications or services that rely on your API.
If you can’t understand how they interact with your APIs, you’re missing half the picture.

When developers integrate with your APIs, how long does it take them to make their first successful API call? What are typical errors slowing them down? Observability plays an essential role in surfacing insights to improve developer experience.

Once your customers’ applications or services relying on your APIs are in production, can you track how your releases impacted their requests? Which version of your APIs are they using? What are the most popular endpoints? Are all customers getting the same performance? Same error rates?

Anti-Pattern: Relying Only on API Monitoring

API monitoring typically involves sending automated test requests to API endpoints and verifying the responses. It helps you keep track of the health of your APIs even when there is no customer activity at all, and can be used to report uptime.

But API monitoring is nothing more than black box testing; you don’t see what is happening inside. You just know that your requests reach the API and receive responses, but you can only create and maintain tests for some possible use cases. You will miss something.

Anti-Pattern: Using API Access Logs for Troubleshooting

API access logs are records of requests and responses made to an API, capturing details such as the requestor’s IP address, HTTP method, requested endpoint, status codes and other relevant information for monitoring, debugging and security purposes.

Using access logs to troubleshoot API issues is like searching for a needle in your microservices haystack. One of our users had a performance issue with their APIs; they spent days searching for the root cause using access logs. Is it the gateway? Does it need more CPU? Is it a configuration issue? They enabled distributed tracing and, within seconds, they could see what was happening: All the time was spent in the authentication server issuing JWT tokens.

To really understand what is happening in your system, you need to be able to track a single user request from the API gateway to the upstream services and their dependencies for effective troubleshooting.

As Martin Thwaites puts it: “Logs are a poor man’s observability tool.” You need distributed tracing.

Anti-Pattern: Different Teams, Different Tools, Different Data

Different teams have different needs. The tool that works for your DevOps team might not fit your product team best. By forcing everyone to use the same tool, you’re not promoting unity but inefficiency.

However, while promoting tool diversity might be the right move for your organization, there should be some coordination and integration between different tools and data sources. Open standards like OpenTelemetry help ensure that information can be shared and leveraged across teams and tools.

The DevOps and the product teams should rely on the same error rate when assessing the performance and reliability of the newest API product launched.

Anti-Pattern: One Size Fits All

Different API architecture styles have different needs when it comes to observability.

REST APIs might be today’s default, but newer styles like GraphQL and gRPC are gaining popularity. Each of these styles has distinct characteristics and requirements regarding observability. Just think about GraphQL’s way of handling errors, which differs significantly from REST APIs. Web Socket and event-driven APIs have their own unique observability challenges, as well.

Different API architectures have different needs, and your observability strategy needs to reflect that to improve the overall reliability of your application.

Anti-Pattern: Observability for Production Only

Why aren’t you using observability in pre-production?

By using distributed tracing during the API development life cycles, developers can trace the flow of requests and responses across different services, providing a comprehensive view of how the API behaves under various scenarios.

With observability, they can identify performance bottlenecks and even detect architectural problems like N+1 problems in GraphQL queries.

For teams leveraging APIOps practices, observability data can be used as an additional validation before promoting an API to the production stage.

Anti-Pattern: Starting the Trace at the API Gateway is Overrated

Tutorials about observability usually start the instrumentation process at a microservice level. It is great to have detailed insights into your microservices. But a lot will happen at the API gateway level when dealing with APIs.

You want to capture all your user transactions, including those that never reach your microservices because of rate-limiting rules, an authentication problem or a caching mechanism.

Starting the trace at the API gateway gives you a clear entrance point and a complete picture of the journey of all your users. That’s why it’s important to use a modern API gateway with built-in support for OpenTelemetry.

So there you have it: Seven API observability pitfalls to avoid. Keep your APIs observable and your users happy!

To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.
March 6, 2024
Cycode Acquires Bearer to Extend ASPM Platform

Cycode today announced it had acquired Bearer, a provider of a set of tools for static application security testing (SAST), discovering application programming interfaces (APIs) and identifying sensitive data.

The provider of an application security posture management platform (ASPM) plans to integrate the Bearer tools into its core platform to enable DevSecOps teams to further consolidate tooling.

Cycode CEO Lior Levy said the acquisition of Bearer gives Cycode access to a set of tools that take advantage of generative artificial intelligence (AI) to surface suggestions that enable DevSecOps teams to more easily secure modern applications based on, for example, a microservices-based architecture.

Bearer achieves that goal by continuously scanning for application security issues as developers are writing code, he added. Overall, Bearer claims its approach to scanning is 31% faster than rival tools while simultaneously leveraging tools such as Bearer Assist, currently in beta, to provide more context concerning the level of risk to the business any issue discovered actually represents.

Those capabilities will be infused into the Risk Intelligence Graph (RIG) that Cycode developed for its ASPM platform.

Cycode earlier this year added generative AI capabilities to its platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments. The company uses the generative AI platform created by OpenAI to provide a natural language interface for RIG. As part of that effort, Cycode is making available an executive dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

The company is at the forefront of developing ASPM platforms that continuously ingest data to identify and assess application security risks. Those platforms also provide a foundation for consolidating many of the tools that DevSecOps teams currently rely on to secure applications before they are deployed in production environments.

It’s not clear how quickly organizations are embracing DevSecOps best practices, but given the number of vulnerabilities that continue to be discovered, there is still much work to be done. The challenge is that legacy tools that lack AI capabilities were not designed to enable organizations to practically shift more responsibility left toward application development teams that typically don’t have a lot of cybersecurity expertise, noted Levy. AI makes it possible to now provide those teams with the context required to address application security issues as they write code versus just before applications are deployed, he added.

In theory at least, the applications deployed today should be significantly more secure than previous generations of applications. In effect, IT environments are steadily becoming more secure. Less apparent, however, is the rate at which modern applications are being deployed to replace legacy applications that are, all too often, rife with known vulnerabilities that cybercriminals can easily exploit. Given the rate at which vulnerabilities can be discovered and patched in those legacy applications, it may take the better part of the rest of this decade to address those issues once and for all.

March 5, 2024
ngrok Previews API Gateway Service to Streamline App Networking

Under an early access program, ngrok today made available an application programming interface (API) gateway that can be consumed as a service.

Rather than having to deploy, maintain, and secure API gateways themselves, application development teams, via a single command or function call, can now invoke a service through which they can route API traffic, authenticate and authorize access, and apply rate-limiting policies using an ngrok policy engine.

ngrok CEO Alan Shreve said this approach also makes it simpler for IT teams to unify ingress management at a time when application networking is becoming more challenging to manage. That approach also reduces friction because instead of being dependent on an IT operations team, it gives developers more direct control over APIs, he added. Today, most access to APIs is granted after developer first create a ticket request in an IT services management (ITSM) platform, noted Shreve.

In addition, the ngrok gateway also streamlines access to APIs spanning multiple clouds and on-premises IT environments in a way that enables organizations to implement a multi-cloud computing strategy, he added. Today, many organizations are locked into a single platform because they are dependent on the API gateway services provided by their cloud service provider, noted Shreve.

Finally, organizations will only need to pay for the API gateway service based on actual usage versus incurring the cost of acquiring a gateway upfront, said Shreve.

Previously, ngrok has been making available software development kits (SDKs) to provide programmable access to its API gateway. The as-a-service option being offered now is the next logical extension of that effort, noted Shreve.

In general, more infrastructure than ever is being consumed as a service, so making available an API gateway service is only the latest example of that larger trend, he added.

Each organization, based on total cost, will naturally need to decide when it makes the most economic sense to consume IT infrastructure as a service; however, as application networking continues to become more challenging to manage at a time when the number of IT professionals with that expertise remains limited. Relying on a service provides a viable alternative for managing what are often hundreds of APIs spanning a distributed computing environment.

It’s not clear yet precisely which teams within an IT organization are assuming responsibility for application networking, but as layer 4 through layer 7 of the networking stack become more programmable, more responsibility for networking can be assumed by DevOps and platform engineering teams. Existing networking teams, meanwhile, continue to manage the physical networking underlays used to route network traffic. Regardless of how application networking evolves, the rigidity that has characterized the delivery of network services is starting to fade away in a way that makes it possible to dynamically invoke networking services as needed.

IT teams must decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications. The goal, however, should be to eliminate as much friction as possible at a time when applications have become more dependent on networking services than ever.

February 15, 2024
Squaring the Circle: How to Make Public APIs Private
APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

Day 2 API Security Solutions and Snowflakes

This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

A Difficult Race to Win

Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

Why Not Avoid the Race?

So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

Zero-Trust API Networking Needs to be Built for APIs

To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

There are usually three reactions to the diagram above:
1. OK, tell me how it works. See below.
2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.
How Zero-Trust API Networking Works

Here are the four pillars of zero-trust API networking:
1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code:
3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.
The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:
- Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
- Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
- Extensibility. Software-only, cloud-native architectures. Preferably open source based.
- Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
- Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
- Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
- Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.
Zero-Trust API Networking

While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.
February 14, 2024