Why is API security failing? In part, because we're over-rotating on 'shift left'

The benefits of shift-left approaches in security are well-documented, to the point where they have become common practice. This practice helps ensure that more coding quality and security issues are found before the code is released into production, saving time and money and reducing risk. However, not all security risks can be identified and eliminated in pre-prod.  This reality is particularly true with APIs, where the security risks associated with their widespread use and abuse is a significant concern. Experts from Gartner predict that by 2022, API abuse will become the most common attack vector.

Recent API incidents have already validated this prediction many times over. Starting in 2021, 90 percent of web-enabled applications will be exposed via APIs rather than the user interfaces. Without a balanced approach to protecting APIs, one that goes beyond just pipeline scanning and other shift-left practices, organizations will continue to suffer API security gaps that leave them exposed.

The Build Security Conundrum

Organizations tend to struggle with two aspects of build pipeline security: procuring the tooling required for security testing to cover all APIs, and the automation and integration of this security tooling into CI/CD pipelines. Some organizations will opt to cobble together open-source testing tools, which requires extra engineering effort and makes integration into build pipelines difficult. In addition, successful automation requires collaboration between security and application teams and shared responsibility among many IT functions including identity and access management, operations, development, and quality assurance. Herein lies another issue; not all organizations have all these functions accounted for with dedicated personnel. Also, where collaboration within the organization is lacking and DevOps maturity is low, you often find a misaligned focus on securing the build pipeline as the only goal of an API security strategy.

The Issues with Vulnerability Scanning

Use of vulnerability assessment and vulnerability management (VA/VM) tooling is a popular security practice. But network and infrastructure scanning is commoditized and low value in the world of API security. While these tools can be reliably used to identify vulnerabilities in commercial or open-source software packages, as well as misconfigurations of servers or workloads, claims that they can cover applications and APIs in depth are generally baseless.  This category of security tooling does little to assess the security of custom applications and APIs. Teams would be better served by incorporating purpose-built tooling such as application security testing (AST) tools instead.

Such AST tools include software composition analysis (SCA) scans that can analyze application components to identify vulnerable dependencies in source code or infrastructure-as-code (IaC). SCA scans can be automated as part of code commits, builds, and delivery, or they can also be run continuously in production to detect drift. These SCA capabilities are often integrated into AST suites as well as git-based version control systems like GitHub or GitLab.You’ll also find SCA capabilities within most workload protection offerings. There are commercial solutions and open-source alternatives, but SCA generally provides better API security coverage than VA/VM tools and is more effectively integrated into modern development practices.

CVEs are Not Everything

Common vulnerabilities and exposures (CVEs) are known vulnerabilities in published software packages and hardware. This makes scanning such as with VA/VM relatively easy but not always applicable to APIs. On the other hand, common weakness enumeration (CWE) is a broader category of software weaknesses better suited for categorizing flaws in homegrown applications and APIs, though the CWE taxonomy can complicate risk scoring and remediation tracking compared to the CVE taxonomy. CWEs are more relevant to the types of issues created when building or integrating code. However, most API-centric organizations see a combination of CVEs, CWEs and novel, unknown vulnerabilities so reliance on CVEs alone provides a false sense of security.

Other Shift-Left Pitfalls

• API schema validators are often billed as a DevOps-friendly option for build pipeline security but schema validation and enforcement is a reskin of  old school approaches to security, documentation and positive security. Development teams are burdened with creating API documentation, and matching enforcement rules or signatures must still be created by security teams. Schema validators also can’t detect business logic flaws which can cause teams to miss sensitive data exposures and abusable functionality.
• Production mirrors are lacking, and such non-production environments are required for running certain types of AST tools effectively. But discrepancies between production and non-production environments are almost always a given, particularly if components are not containerized for consistency and easily deployable. Service meshes and container platforms can make it easier to spin up environments as needed but have an associated learning curve. As a result, organizations with low DevOps maturity struggle to operationalize. Factoring in cost of AST licensing and limited resources available for maintaining production mirrors, having such testing environments for effective use of AST is a luxury for most organizations.
• Multiple build pipelinesthat blend legacy and modern technology stacks, different programming languages and development processes, monolithic and microservices architectures, and waterfall and agile methodologies can inadvertently lead to reduced visibility and control for an organization. The realities of application development, integration, and systems engineering in modern organizations are such that multiple build pipelines are common. The more pipelines that exist, the harder it is to secure applications, integrate tooling, and exert control.

The Light at the End of the Pipeline

In most cases, securing a build pipeline is a multi-year, cross-team endeavor that requires a certain level of DevOps maturity. It takes time to unify all elements of development cycles, both internal and external, and during that time, an organization may be exposed to attackers that can bypass access controls, exploit weaknesses in defenses, and abuse business logic. Organizations must recognize that some security gaps can’t be filled by automated build-time security scans and issues often emerge only in runtime.

Continuous API discovery provides a better picture of your API attack surface. And runtime behavioral analysis offers better protection from API attacks than the old ways of trying to detect and fix all vulnerabilities through traditional security scanning. Continuous discovery and runtime behavioral analysis make early detection possible, preventing API attacks before exploitation or abuse can occur. Runtime behavioral analysis can automatically account for an organization’s unique business logic and integrates nicely with existing technology investments. As such, APIs need to be secured in a modern way that accommodates the prevailing shift-left mindset and secure build pipeline focus while also protecting the organizations that might over rely on those approaches and leave them exposed.

Photo Credit: Panchenko Vladimir/Shutterstock

Michael Isbitski is Technical Evangelist, Salt Security