Skip to content

Building a modern API security strategy — API components

Building a modern API security strategy — API components

Part three of the five-part series, Building a modern API security strategy.

Got a GitHub account? Lucky you: You can pollute code libraries. 

Anyone with a GitHub account can contribute code to critical libraries: a fact that attackers adore.  All too frequently, libraries get hijacked and transferred to new owners who make malicious code commits. The nightmare of code tampering has led to what’s become nearly a monthly parade of major software supply-chain attacks, including SolarWinds, Accellion, Click Studios, Python and PHP, CodeCov, Kaseya, Log4Shell, and more.

Attackers are looking for any entry point into the victim’s software development lifecycle (SDLC).  Once in, the DevOps automation that organizations rely on to increase efficiency of application release also makes it easier for attackers to move laterally.

Securing the supply chain

In particular, the  massive cyberattack on SolarWinds Orion infrastructure management software in December 2020 — an attack that victimized multiple agencies of the U.S. federal government, including groups that manage top-secret information — was a wake-up call for organizations to prioritize application security for all parts of their software supply chain, which has four elements:

  • What you write: Custom code developed by in-house and contracted development teams,
  • What you build with: Software development tools that aid in-house developers in their work,
  • What you buy: Commercial off-the-shelf (COTS) Software-as-a-Service (SaaS) applications in use by an organization, and
  • What you use: The numerous third-party libraries that most applications depend on. 

When working against tight sprint deadlines, developers almost always default to using third-party open-source or COTS components to provide ready-made functionality for a particular business use case. Developers pull these components from a variety of sources, including public repositories and project sites. 

The sheer number of libraries and the complexity of transitive dependencies make securing the supply chain difficult. The result is complex dependency trees that can be difficult to track. Application security teams can quickly become overwhelmed with this volume of technical debt. This, in turn, introduces gaps in visibility and governance. Too often, the result of these deficiencies is that you can’t respond quickly to zero-day exploits.

‘What’s in this app?!’

In many cases, security teams struggle to answer the simple question, “What’s in the application?” This state of affairs would be difficult enough if every vulnerability in every library posed equal risk to an organization. But Contrast Labs research shows that 62% of libraries found in the typical application are inactive — that is, two-thirds of libraries are never invoked by the software.

In creating a modern application programming interface (API) security strategy, after figuring out API inventory and security testing, the third piece of the puzzle is to lock down your open-source supply chain. In the traditional API security approach, this is done with static Software Composition Analysis (SCA): a technique from the early 2000s that was designed for monolithic web apps and waterfall development. 

Instrumentation fends off zero days

Contrast Security’s modern solutions help organizations manage all their supply-chain components, including APIs, with comprehensive observability of the entire software supply chain. That helps organizations to respond effectively to zero-day attacks — even when patches are unavailable or aren’t feasible to install. 

Such was the case with Log4j. As the Federal Cyber Safety Review Board recently concluded in its review of attackers' abuse of the Log4j library to hack vulnerable systems, Log4j abuse is now endemic. Organizations "should be prepared to address Log4j vulnerabilities for years to come" and "should continue to report (and escalate) observations of Log4j exploitation," the board warned. 

Yet even before a patch was available, Contrast users could shrug off Log4j. “We were able to analyze whether our own built software would be vulnerable to the Log4j zero-day, using the Contrast Secure Code Platform, and got the answer within 30 seconds by just looking at the Libraries menu!” said CISO Sandor Incze. “How fast is that!”

At Contrast, the key to our magic is instrumentation. Contrast’s runtime SCA enables businesses to protect their software supply chain by identifying real threats from third-party components across the entire SDLC — from code through test and on through production.

Dynamic SCA uses instrumentation to identify vulnerable libraries and how APIs use them, while Interactive Application Security Testing (IAST) continuously monitors for security defects while an app is being built and tested.

Software instrumentation is simple in concept — you just add “sensors” to a piece of software so that you can see what’s going on inside it. You don’t have to modify the source code, recompile, retest or redeploy. Rather, you can directly measure security from the app itself, which is faster, more accurate and far, far easier to use than traditional SCA tools. 

Contrast SCA is embedded in running apps and APIs, making every test a security test. It’s highly accurate, and it works in real time, making it a great fit for Continuous Integration/Continuous Deployment (CI/CD). It enables businesses to protect their software supply chain by identifying real threats from third-party components across the entire SDLC — from code, through test, to production.

It flags security gaps embedded in your software supply chain, be they in open-source, commercial or proprietary code, and scaling across development to testing and on into production environments.

We’re on a mission: In a world that runs on software — including the burgeoning use of APIs — we make sure that software infrastructure is safe from cyberattacks. 

The five parts of API security

Last week, we looked at API security testing

Stay tuned: Next week, we’ll be looking at API protection. 

For a guide to all five parts of Contrast’s series on forging a modern API security strategy, check out this overview

Also, be sure to check out this discussion between Jeff Williams, Co-Founder & CTO, Contrast Security, and Melinda Marks, Senior Analyst, ESG Research, where they unravel: 

  • What the future of API security holds for enterprises.
  • What you need to know to secure your APIs.
  • Strategies to stay ahead of the CI/CD lifecycle game.
  • The path forward to building unified developer and security teams that can build secure APIs. 


To download the recorded webinar:


Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.