1. Page 1 of 11
Traceable.ai Debuts Platform for
Building API Knowledge that Detects
And Thwarts Services Vulnerabilities
Transcript of a discussion on a new platform designed from the ground up specifically to define, manage,
secure, and optimize the API underpinnings for so much of what drives today’s digital business.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re
listening to BriefingsDirect.
The rapidly expanding use of application programming interfaces (APIs) to accelerate
application development and advanced business services has created a vast constellation of
interrelated services -- now often called the API Economy.
Yet the speed and complexity of this API adoption spree has largely outrun the capability of
existing tools and methods to keep tabs on the services topology -- let alone keep these
services secure and resilient.
Stay with us now as we explore a new platform designed from the ground up specifically to
define, manage, secure, and optimize the API underpinnings for so much of what drives today’s
digital business.
To learn more about how Traceable AI aims to make APIs
reach their enormous potential safely and securely, please
welcome Sanjay Nagaraj, Chief Technology Officer (CTO) and
Co-Founder at Traceable AI. Welcome, Sanjay.
Sanjay Nagaraj: Thanks, Dana, for having me.
Gardner: Why is addressing API security different from the
vulnerabilities of traditional applications and networks? Why do
we need a different way to head off API vulnerabilities?
Nagaraj: If you compare this to the analogy of protecting a
house, previously there was a single house with a single door.
You only had to protect that door to block someone from
coming into the house. It was a lot easier.
Now, you have to multiply that because there are many rooms in the house, each with an open
window. That means an attacker can come in through any of these windows, rather than only
through a single door to the house.
To extend the analogy across the API economy, most businesses today are API-driven
businesses. They expose APIs. They also use third-party libraries that connect to even more
Nagaraj

2. Page 2 of 11
APIs. All of these APIs are powering the business but are also interacting with both internal and
third-party APIs.
APIs and services are everywhere. The microservices are developed to power an entire
application, which is then powering a business. That’s why it is getting so complex compared to
what used to be a typical network security or a basic application security solution. Before, you
would take care of the perimeter for a particular application and secure the business. Now, that
extends to all these services and APIs.
And when you look at network security, that operated at a different layer. It used to be more
static. You therefore had a good understanding of how the network was set up and where the
different application components were deployed.
Nowadays, with rapidly changing services coming
online all the time, and APIs coming online all the
time, there is no single perimeter. In this complex
world, where it is all APIs across the board, you must
take into consideration more aspects to understand
the security risks for your APIs, and -- in turn -- what
your business risks are. Business is riskier when it
comes to today’s security.
Because it’s so very complex, the older security solutions can’t keep up. We at Traceable AI
choose to take care of security by looking at the data that comes in as part of the calls hitting
the URLs. We take into consideration more context to detect whether something is an attack or
some anomaly that is not necessarily malicious but may be a reconnaissance-type of attack.
All of these issues mean we need more sophisticated solutions that frankly the industry hasn’t
caught up to even though developer and development, security, and operations
(DevSecOps) advances have moved a lot faster.
Gardner: And, of course, these are business-critical services. We’re talking about mission-
critical data moving among and between these APIs, in and out of organizations and across
their perimeters. With such critical data at hand, the reputation of your business is at stake
because you could end up in a headline tomorrow.
Data is everywhere, exposed and in need of security
Nagaraj: Exactly. At the end of the day, APIs are exposing data to their business users. That
means the data flowing through might be part of the application, or it might be from another
business-to-business API. You might be taking the user’s data and pushing it to a third-party
service.
We’ve all seen the attacks on very sophisticated technology companies. These are very hard
problems. As a developer myself, I can tell you what keeps me up most of the time: Am I doing
the right thing when it comes to the functionality of my application? Am I doing the right thing
when it comes to the overall quality of it? Am I doing the right thing when it comes to delivering
the right kind of performance? Am I meeting the performance expectations of my users?
You must take into
consideration more aspects to
understand the security risks
for your APIs, and -- in turn --
what your business risks are.

3. Page 3 of 11
What do I, as a developer, think about the security of every single API that I’m writing? At the
end of the day, it’s about the data that is getting exposed through these APIs. It’s important now
to understand how this data is getting used. How is this data getting passed around through
internal services and third-party APIs? That’s where the risk associated with your API is.
Gardner: Given that we have a different type of security problem to solve, what was your
overarching vision for making APIs both powerful and robust? What is it in your background that
helped you get to this vision of how the world should be?
Nagaraj: If you dial back the clock for myself and Jyoti Bansal, my co-founder at Traceable, we
built the company AppDynamics, which was on the forefront of helping developers and DevOps
teams understand their applications’ performance. When that product started, there was a basic
understanding of how applications performed and were delivered to the customers. Over time,
we started to think about this in a different way. One of the goals at AppDynamics was to
understand applications from the ground up. You had to understand how these applications with
their modules and sub-modules, and with the sub-services, were interacting with each other.
A basic understanding was required to learn if the end-user experience was being delivered with
the expected performance. That gave rise to application performance management (APM) in
terms of a fuller understanding of an application’s underlying performance itself.
From an AppDynamics’ perspective, it was very important for us to know how the services were
impacting each other. That means when a call gets made from service A to service B, you
should understand how much time was consumed on the call and what was happening between
the two, as well as how much time was spent within the service, between the services, and how
much total time was spent delivering the data back to the user.
This is all in the performance context. But one of the key things we clearly knew as we started
Traceable AI was that APIs were exploding. As we talked about with the API Economy, every
one of the customers Traceable started to talk to asked us about more than just the
performance aspects of APIs. They also wanted to know whether these APIs and applications
were secure. That’s where they were having a difficult time. As much as developers like to make
sure that APIs are secure, they are unable to do it simply because they don’t understand what
goes into securing APIs.
That’s when we started to think about how to bring some of the learning we had in the past
around application performance for developers and DevOps teams, and bring that to an
understanding of APIs and services. We had to think about application security in a new way.
We started Traceable AI to find the best way to
understand applications and the interactions of the
applications, as well as understanding the uses. The
way to do it was the technology built over the last
decade for distributed tracing. By helping us trace
the calls from one service to another, we were able
to tap the data flowing through the services to
understand the context of the data and services.
From the context and the data, you can learn who the users of these APIs are, what type of data
is flowing, and which APIs are interacting with each other. You can see which APIs are getting
By helping us trace the calls
from one service to another,
we were able to tap the data
flowing through the services
to understand the context of
the data and services.

4. Page 4 of 11
called as part of a single-user session, for example, and from which third-party APIs the data is
being pulled from or pushed to.
This overall context is what we wanted to understand. That’s where we started, and we built on
the existing tracing technology to deliver an open-source platform, called Hypertrace.
Developers can easily use it for all kinds of tracing use cases, including performance. We have
quite a few customers that have started to use it as an open-source resource.
But the goal for us was to use that distributed tracing technology to solve application security
challenges. It all starts with so many customers saying, “Hey, I don’t even know where my APIs
exist. Developers seem to be pushing out a lot of APIs, and we don’t understand where these
APIs are. How are they impacting our overall business in terms of security? What if some of
these things get exposed, what happens then? If you must do a forensic analysis of these, what
happens then?”
See it to secure it, with tracing technology
We said, “Let’s use this technology to understand the applications from the ground up, detect
all these APIs from the ground up.” If the customers don’t understand where the APIs exist, and
what the purpose of these APIs are, then they won’t be able to secure them. For us, the basic
concept was bringing the discovery of these applications and APIs into focus so that customers
can understand it. That’s the vision of where we started.
Then, based on that, we said, “Once they discover and understand what APIs they have, let’s
go further to understand what the normal behavior of these APIs are.”
Once APIs are published there are tools to document those APIs in the form of an OpenAPI or a
Swagger spec. But if you talk to most enterprises, there are rarely maintained records of those
things. What developers do very well is ship code. They ship good functionality; they try to ship
bug-free code that performs well.
But, at the same time, the documentation aspects of it are where it gets weak because they’re
continuously shipping. Because the code is changing continuously, from a continuous
integration/continuous delivery (CI/CD) perspective, the developers are not able to continuously
keep the spec documentation up-to-date, especially as it continuously gets deployed and
redeployed into production.
The whole DevSecOps movement needs to come
together so the security practitioners are
embedded with the developer and DevOps teams.
That means the security folks have to have a
continuous understanding of the security practices
to ensure the APIs that are coming online
continuously are understood.
Our customers now also are expecting our solution to help them automate these things. They
want to automatically understand the risks of APIs -- which APIs should be blocked from being
deployed into production and which APIs should be monitored more. There needs to be a cycle
of observing these APIs on a continuous basis. It’s very, very critical.
Security folks have to have a
continuous understanding of the
security practices to ensure the
APIs that are coming online
continuously are understood.

5. Page 5 of 11
From our perspective, once we build this ongoing understanding of the APIs – as we discover
and build an understanding of the APIs – we then want to protect those APIs before they get
into production.
The inability to properly protect these APIs is not because some small company doesn’t have
the technology skills or the proper engineering. It’s not about developers not having the right
kind of training. We are talking about capable companies like Facebook, Shopify, and Tesla.
These are technology-rich companies that are still having these issues because the APIs are
continuously evolving. And there are still siloed pieces of development. That means in some
cases they might understand the dependencies of the services, but in a lot of cases they don’t
fully understand the dependencies and the security implications because of those
dependencies.
This reality exposes a lot of different types of attacks, such as business logic attacks, as you
and Jyoti talked about in your previous conversations. We know why those are very, very
critical, right?
How do you protect against these business logic vulnerabilities? The API discovery and
understanding the API risk are very key. Then, on top of those, the protection aspects are very,
very key. So, that was where we started. This is part of the vision that we have built out.
Because of the way our new platform has been built,
we enable all these understandings. We want to
expose these understandings to our customers so
they can go and hunt for different types of attacks
that may be lurking. They can also use and analyze
this information not just for heading off prospective
attacks but to help influence all the different types of
development and security activities.
This was the vision we began with. How do you bring observability into application security?
That’s what we built. We help evolve their overall application security practices.
Gardner: In now understanding your vision, and to avoid a firehose of data and observations,
how did you design the Traceable platform to attain automation around API intelligence? How
did you make API observability a value that scales?
Categories aid continuous comprehension
Nagaraj: One of the key aspects of building a solution is to not just throw data at your
customers. That means you’re correcting the data; you’re not just presenting a data lake and
asking them to slice and dice and analyze it using manual processes. The goal from the get-go
for us was to understand the APIs and to categorize them in useful ways.
That means we must understand which APIs are external-facing, which are internal-facing, and
where the sensitive data is. What amount and type of sensitive data is getting carried through
these APIs? Who are the users of these APIs? What roles do they have with an API?
We want to expose these
understandings to our
customers so they can go and
hunt for different types of
attacks that may be lurking.

6. Page 6 of 11
We are also building a wealth of insights into how the APIs themselves behave. This helps our
customers know what to focus on. It is not just about the data. Data forms a basis for all these
other insights. It’s not about presenting the data to the customers and saying, “Hey, go ahead
and figure things out yourself.”
We bring insights that enable the security and operations teams -- along with the developers
and DevSecOps teams -- to know what security aspects to focus on. That was a key principle
we started to build the product on.
The second principle is that we know the security and operations teams are very swamped.
Most of the time they are under-resourced in terms of the right people. It was therefore very
important that the data we present to those teams is actionable. The types of protection we
provide from detection of anomalies must have very low levels of false positives. That was one
of the key aspects of building our solution as well.
A third guiding principle for us, from the DevSecOps team’s perspective, is to give them
actionable data to understand the code that is being deployed even when the services are
deployed in a cloud-native fashion. How do you understand at the code level, which ones are
making a database call and where that data is flowing to? How do you know which cloud-based
APIs are making third-party API calls to know if there are vulnerabilities? That is also very
important to manage.
We have taken these principles very seriously as we built the solution. We bring our deep
understanding of these APIs together with artificial intelligence (AI) and machine learning (ML)
on top of the data to extract the right insights -- and make sure those are actionable insights for
our users. That is how we built the platform from the ground up. Because continuous delivery
(CD) is how applications are deployed today, it’s very important that we are continuously
providing these insights.
It’s not enough to just say, “Hey, here are your APIs.
Here are the insights on top of those, and here is
where you should be focusing from a risk
perspective.” We must also continuously adjust and
gain new insights as the APIs evolve and change.
There was one last thing we set out to do. We knew our customers are in a journey to
microservices. That means we must provide the solution across diverse infrastructures, for
customers fully in a cloud-native microservices environment as well as customers making their
journey from legacy, monolithic applications; and everything in-between. We must provide a
bridge for them to get to their destinations regardless of where they are.
Gardner: Yes, Traceable AI recently released your platform’s first freely available offering in
August. Now that it’s in the marketplace, you’re providing a strong value to developers, by
helping them to iterate, improve, and catch mistakes in their APIs design and use. Additionally,
by being able to define vulnerabilities in production, you’re also helping security operations
teams. They can limit the damage when something goes wrong.
By serving both of those two constituencies, you’re able to bridge the gap between them.
Consequently, there’s a cultural assimilation value between the developers and the security
teams. Is that cultural bond what you expected?
We must also continuously
adjust and gain new insights as
the APIs evolve and change.

7. Page 7 of 11
Reduce risk with secure interactions across services
Nagaraj: Absolutely. I think you said it right. In a lot of cases, these organizations are rapidly
getting bigger and bigger. Typically, today’s microservices-based, API-driven development
teams have six to eight members building many pieces of functionality, which eventually form an
overall application. That’s the case internally at Traceable AI, too, as we build out our product
and platform.
And so, in those cases, it’s very important that there is an understanding around how API
requests come into an overall application. How do they translate across all the different services
deployed? What are the services – defined as part of those small teams -- and how are they
interacting with each other to deliver a single customer’s request? That has a huge impact on
understanding the overall risk to the application itself.
The overall risk in a lot of cases is based on a combination of factors driven by all the APIs
being exposed to those applications. But knowing all the APIs interacting with these services --
and the data that’s going through these services -- is very important to get a holistic
understanding of the application, and the overall application infrastructure, to make sure you’re
delivering security at an application level.
It’s no longer enough just to say, “Yes, we are secure. We’re practicing all the secure-coding
practices.” You must also ask, “But what are the interactions with the rest of the organization?”
That’s why it was essential for us to build what we call API Intelligence from the ground up
based on the actual data. We attain a deeper understanding of the data itself.
That intelligence now helps us say, “Hey, here are all
the APIs used across your organization. Here’s how
they’re interacting with each other. Here’s how the
data goes between them. Here are the third-party APIs
being accessed as part of those services.”
We get that holistic understanding. That broad and inclusive view is very important because it’s
just not about external APIs being accessed. It includes all the internal APIs being built and
used, as well, from the many small teams.
Customers often tell me after using our solution that their developers are shocked there are so
many APIs in use. In some cases, they thought they were duplicate APIs. They never expected
those APIs to show up as part of any single service. It feels good to hear that we are bringing
that level of visibility and realization.
Next, based on our API Intelligence, comes the understanding of the risks. And that is so very
important because once the developers understand the risks associated with a particular API,
the way they go about protecting them also becomes very important. It means the vulnerabilities
are going to get prioritized and then the fixes are going to be prioritized the right way, too. The
ways they protect the APIs and put in the guards against these API vulnerabilities will change.
At the end of the day, the goal for us is to bring together the developers and the DevOps and
security teams. Whether you look at them as a single team or separate teams, it doesn’t matter
Here are all the APIs used
across your organization.
Here’s how they’re
interacting with each other.

8. Page 8 of 11
for an organization. They all must work together to make security happen. We wanted to provide
a single pane of glass for them to all see the same types of data and insights.
Gardner: I have been impressed that the single pane view can impact so many different roles
and cultures. I also was impressed with the interface. It allows those different personas to drill
down specific to the context of their roles and objectives.
Tell us how that drilling down capability within the Traceable AI user interface (UI) gives the
developers an opportunity to compress the time of gaining an understanding of what’s going on
in API production and bring that knowledge back into pre-production for the next iteration?
An ounce of prevention in pre-production
Nagaraj: One of the key things in any development lifecycle is the stages of testing you go
through. Typically, applications get tested in the development and quality assurance (QA)
stages along the way.
But one of the “testing” opportunities that can get missed in pre-production is to learn from the
production data itself. That is what we are addressing here. As a developer, I like to think that all
the tests being written in my pre-production environment cover all the use cases. But the reality
is that the way customers use the applications in production can be different than expected. And
the type of data that flows through can be different too.
This is even more true now because of API-driven applications. With API-driven applications,
the developer has an intent of how their APIs are used, and most of their tests mimic that intent.
But once you give the APIs to third-party developers – or hackers -- they might see the same
APIs that the developer sees yet use them in unintended ways. Once they gain an
understanding of how the API logic has been built internally the external users might be able to
get a lot more information than they should be able to.
This is where it gets complex. This means that rather than treating production and pre-
production as silos, the thought process is to bring the production learnings and knowledge to
help improve the application’s security posture in pre-production because we know how certain
APIs are actually being used.
If we understand the true risks associated with these APIs in use, we can present that in-
production use knowledge back into pre-production, such as users accessing APIs they aren’t
supposed to be accessing. That means decisions about which APIs need to be protected
differently can be made by using the right kinds of controls.
The core benefit to customers is that they can
understand their API risks earlier so that they can
protect their APIs better.
Gardner: The good news is there’s new value in post-production and pre-production. But who
oversees bringing the Traceable AI platform into the organization? Who signs the PO? Who are
the people who should be most aware of this value?
Customers can understand their
API risks earlier so that they can
protect their APIs better.

9. Page 9 of 11
Everyone sees APIs through a single pane of glass
Nagaraj: Yes, there are typically various types of organizations at work. It’s no longer a case of
a central security team making all the decisions. There are engineering-driven, DevOps teams
that are security-conscious. That means many of our customers are engineering leaders who
are making security their top priority. It means that the Traceable AI deployment aspects also
come to pre-production and production as part of their total development lifecycle.
One of the things we are exploring as part of our August launch is to make the solution
increasingly self-service. We’ve provided low friction way for developers and DevOps teams to
get value from Traceable AI in their pre-production and production systems, to make it part of
their full lifecycle. We are heavily focused on enabling our customers to have easy deployment
as a self-service experience.
On the other hand, when the security and operations teams need to encourage the developers
or DevOps teams to deploy Traceable AI, then, of course, that ease-of-use experience is also
very important.
A big value for the developers is that they get a single pane of glass, that means they are
seeing the same information that the security teams are seeing. It is no longer the security
people saying, “There are these vulnerabilities which is a problem;” or, “There are these attacks
we are seeing,” and the developers don’t have the same data. Now, we are offering the same
types of data by bringing observability from a security perspective to provide the same analysis
to both sides of the equation. This makes everyone into a more effective team solving the
security problems.
Gardner: And, of course, you’re also taking advantage of the ability to enter an organization
through the open-source model. You have a free open-source edition, in addition to your
commercial edition, that invites people to customize, experiment, and tailor the observability to
their particular use cases -- and then share that development back. How does your open-source
approach work?
Nagaraj: We built a distributed tracing platform, which was needed to support all the security
use cases. That forms a core component for our platform because we wanted to bring in tracing
and observability for API security.
That distributed tracing platform, called
Hypertrace, as part of the Traceable AI
solution, will enable developers to adopt the
distributed tracing element by itself. As you
mentioned we are making it available for free
and as open source.
We’ve also launched a free tier of the Traceable AI security solution which includes the basic
versions of API discovery, risk monitoring, and basic protection, for securing your applications.
This is available to everybody.
Our idea was we wanted to democratize access to good API security tools, to help developers
easily get the functionality of API observability and risk assessment so that everyone can be a
Hypertrace … will enable developers
to adopt the distributed tracing
element by itself. [It] is available for
free and as open source.

10. Page 10 of 11
pro-active part of the solution. To do this we launched the Free tier and the Team tier, which
includes more of the functionality that our Enterprise tier includes.
That means, as a DevOps team, you’re able to understand your APIs and the risks associated
with them, and to enable basic protections on those APIs. We’re very excited about opening this
up to everyone.
But the thing that excites the engineer in me is that
we are making our distributed tracing platform
source code available for people to go build
solutions on top of. They can use it in their own
environments. At the end of the day, the developers
can solve their own business problems. We are in
the business of helping them solve the security
problems, and they can solve their other business
needs.
For us, it is about how do we secure their APIs. How do we help them understand their APIs?
How can they best discover and understand the risks associated with those APIs? And that’s
our core. We are putting it out there for developers and DevOps teams to use.
Gardner: Sanjay, going back to your vision and the rather large task you set out for yourselves,
as Traceable AI becomes embedded in organizations, is there an opportunity for the API
economy to further blossom?
How big of an impact do you expect to have over the next few years, and how important is that
for not only the API economy, but the whole economy?
API economy thrives with continuous code delivery
Nagaraj: From an API economy perspective, it’s thriving because of the robust use of these
APIs and the reuse of services. Any time we hear news about APIs getting hacked or data
getting lost, there is an inclination to say, “Hey, let’s stop the code from shipping,” or, “Let's not
ship too many features,” or, “Let's make sure it is secure enough before it ships.”
But that means the continuous delivery benefits powering the API economy are not going to
work. We, as a community of developers, must come up with ways of ensuring security and
privacy so we can continue to maintain the pace of a continuous software development life
cycle. Otherwise, this will all stall. And these challenges will only get bigger because APIs are
here to stay. The API economy is here to stay. APIs will be continuously evolving, and they will
be delivering more and more functionality on a continuous basis.
The only way we can get better at this is by bringing in the technology that enables the
continuous delivery of code that is secured in pre-production and not just at runtime. And that’s
the goal from our perspective, to build that long-term and viable solution for enterprises.
Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored
BriefingsDirect discussion on how the rapidly expanding use of APIs to advance business
services has created a complex constellation of interrelated services.
What excites the engineer in me
is that we are making our
distributed tracing platform
source code available for people
to go build solutions on top of.

11. Page 11 of 11
And we’ve learned how an AI-enabled security capability in a new platform from Traceable AI is
designed from the ground up to discover, secure, and optimize the API underpinnings of
today’s digital businesses for teams across the full lifecycle of development.
So, a big thank you to our guest, Sanjay Nagaraj, Chief Technology Officer and Co-Founder at
Traceable.ai. Thank you so much, Sanjay.
Nagaraj: Thanks a lot.
Gardner: And a big thank you as well for our audience for joining this BriefingsDirect API
resiliency discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host
throughout this series of Traceable AI-sponsored BriefingsDirect interviews.
Thanks again for listening. Please pass this along to your business community and do come
back for our next chapter.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Transcript of a discussion on a new platform designed from the ground up specifically to define, manage,
secure, and optimize the API underpinnings for so much of what drives today’s digital businesses.
Copyright Interarbor Solutions, LLC, 2005-2021. All rights reserved.
You may also be interested in:
● How to migrate your organization to a more security-minded culture
● How API security provides a killer use case for ML and AI
● Securing APIs demands tracing and machine learning that analyze behaviors to head off attacks
● Rise of APIs brings new security threat vector -- and need for novel defenses
● Learn More About the Technologies and Solutions Behind Traceable.ai.
● Three Threat Vectors Addressed by Zero Trust App Sec
● Web Application Security is Not API Security
● Does SAST Deliver? The Challenges of Code Scanning.
● Everything You Need to Know About Authentication and Authorization in Web APIs
● Top 5 Ways to Protect Against Data Exposure
● TraceAI : Machine Learning Driven Application and API Security