APIs are dominating the development landscape. In its 2022 State of the API Economy report, Google Cloud found that more than two-thirds (67%) of respondents leverage APIs to help speed application development. However, most organizations surveyed haven’t adopted a comprehensive API strategy. In fact, 66% of organizations replied that their API program’s maturity could be ranked as “medium” to “low”. APIs provide a standardized and efficient means to integrate, extend, and innovate within the software ecosystem. But, with only a minority of organizations claiming to have a mature API program, it’s far too common to have poor controls that create API sprawl.
Making matters worse, while many API Security solutions may tout that they are “shifting left,” there’s a fundamental gap in their testing methodology, creating an opportunity for threat actors to capitalize on your zombie and shadow APIs.
Many solutions today can’t identify zombie and shadow APIs, since they’re only scanning live traffic.
Considering the rise of API Security attacks, it’s more important now than ever before to test during the API development process, as well as before they are pushed to production.
What are zombie and shadow APIs
No matter how sophisticated a development team may be, undocumented APIs are likely hiding in your organization. Documented APIs are those APIs that development teams have provided the AppSec team with API documentation files, like RAML files, Swagger files, or OpenAPI files. These files describe what an API is, what it looks like, where it lives, and what parameters it has.
Existing API security solutions like DAST, WAFs, and API gateways can only protect what they know. They must be configured per API to protect that API. What that means is that if the AppSec team doesn’t have the API documentation, or, if that documentation is incorrect, AppSec can't configure the WAFs or gateways to protect those APIs.
Shadow APIs are created under the radar—typically for a small use case, or they are created and deployed outside of an organization’s official API governance, visibility, and security controls. Shadow APIs may not have the proper authentication and access gates in place, or they may expose sensitive data improperly. Most importantly, with that lack of documentation, existing API security solutions can’t protect them.
Zombie APIs arise in a slightly different way. For example, an organization could have a frontline API that was in production for some time, like an old version of a login API. When it’s time to update the application and login service, you have a new version of the same API. When developers create an updated API, they often don’t decommission the old version right away. Instead, the new API runs alongside the older API to ensure that the user experience isn’t impacted if any issues arise.
Eventually, you might forget about version one, since traffic is no longer going to the old login page, and your development team’s focus is now on version two. The problem is that the API is still lurking behind the scenes, leaving you potentially vulnerable to an attack. Since shadow and zombie APIs aren’t properly documented, a WAF doesn’t know about it, and can’t protect it accordingly.
The problem with API discovery solutions today
There are new types of API threat protection solutions that have entered the market in recent years. Many API discovery solutions or threat protection solutions integrate with your WAFs, gateways, load balancers, and other network devices to analyze the traffic logs. By analyzing the traffic, they find all the API endpoints that that traffic is going to - they discover the APIs by looking at your live traffic going through these devices.
It certainly helps, but it doesn't solve the problem.
The furthest left these solutions go is API documentation, but that doesn’t protect against undocumented APIs, or even worse, the APIs that are documented incorrectly. Many organizations don’t have a single choke point in application infrastructure that can integrate with, and see, all API traffic.
So, while other solutions may say that they “shift left” in the SDLC, it’s often not the case. WAFs say they shift left, but in reality, they only sit in front of production APIs. API threat protection solutions say they shift left, but they’re analyzing traffic to those live production APIs, on the far-right side of the SDLC. Instead, a shift left and integrate right approach is needed...
Shift left, and integrate right, to protect your APIs
Instead of relying on API traffic, Checkmarx believes a shift left and integrate right approach for API Security is best, securing APIs as they’re being developed, as they’re being pushed into production, and helping you identify and protect against shadow and zombie APIs.
Starting with the source code
Checkmarx API Security focuses on starting with the source code, understanding that there are likely gaps in API documentation. Checkmarx SAST identifies vulnerabilities, while Checkmarx API Security discovers the APIs in code, and builds a Global API inventory, along with API documentation risk by automatically scanning source code at check-in or code merge.
For API-first organizations, that means you can easily validate API documentation in design, then compare against implementation to identify discrepancies. Checkmarx API Security of course scans API documentation (i.e., Swagger, RAML) files before your developers start coding to ensure that security is added into the design phase. This helps enforce API design best practices and assesses your overall API design for misconfigurations, identifying risks in path definitions, authentication schema, and transport encryption. For code-first organizations, it means you can discover and inventory every API in source code without requiring proper documentation, first.
Change log to better leverage existing APIs
APIs allow developers to create modular software components that can be reused across different projects. Instead of rewriting the same code multiple times, developers can use an API to achieve the desired functionality. The problem we often see, is that without the full history or context behind a given API, developers may fear leveraging the API and modifying it for their needs. As a result, developers will often create a new API from scratch.
The change log provides a full history of every change made to a given API, giving developers the full confidence they need to leverage existing APIs. Beyond developers having the full history at their fingertips, AppSec managers can also leverage the change log to quickly identify, for example, if a given public-facing API has a recent change adding sensitive data. As a result, developers and AppSec teams can better align with the true spirit of APIs; their agility, and ability to be repurposed, by finally having all the context they need to confidently leverage and repurpose existing APIs.
A better developer experience
Checkmarx API Security integrates and automates scans in the tools developers use, enabling developers to remediate vulnerabilities in their favorite tools allowing them to kick off an application scan at any time using the CLI, and not wait until after code check-in to focus on security. It also provides guided remediation to help resolve vulnerabilities faster by prioritizing, recommending mitigation points, and surfacing just-in-time learning for discovered vulnerabilities.
Single view to manage all API risk
Providing AppSec managers a full view of all APIs, Checkmarx aggregates and correlates the results from all the different scan engines for a more accurate picture of your application security. The Global API Inventory is where all of your APIs from all of the different projects are viewable in one place. This view helps AppSec teams focus on the most critical issues by prioritizing API vulnerabilities based on their real impact and risk.
What's new in Checkmarx 3.0
Brand new this fall, we now have pre-production testing of all the APIs in DAST. This new capability complements our original shift-left approach with one that now also integrates right.The integration of DAST and API Security provides a more comprehensive view of API security risks, enabling customers to identify and remediate risks earlier in the development lifecycle. It works by DAST executing the API to evaluate the security risk. With a complete and up-to-date inventory, you can figure out the risk of the API before it goes into production.
Also new in the Checkmarx One 3.0 launch, Checkmarx API Security now automatically scans API documentation files, saving you time and effort vs. scanning API documentation files manually. This works when a user defines a rule in the project or globally using regex on the destination of the swagger files, so that every API security scan will scan the same swaggers without having to upload them manually. For example, a user could write a regex that scans all swagger files according to the *swagger.json regex. When someone adds a new swagger that matches this regex and pushes the code, the engine will run API Security with the new swagger.
You can't secure what you can't see
Checkmarx API Security provides complete API visibility, providing the most accurate and up-to-date view of the entire API attack surface, eliminating the problem of shadow and zombie APIs.
A true shift-left approach means we discover APIs at the source, to find every API that’s written in the code, to identify and fix problems earlier and faster in the SDLC.
Prioritized remediation helps developers and AppSec teams focus on the most critical issues.
The total result is a holistic view of application security risk, scanning the entire application with a single solution, and removing the need for additional API-specific tools.
While scanning source code and identifying shadow and zombie APIs is a big leap for API Security, we’re just getting started. Stay tuned for an upcoming announcement to correlate source code with runtime to better prioritize risk and improve accuracy. If you’d like to learn more about Checkmarx API Security, register for the upcoming webinar "Shift Everywhere to Secure APIs" on October 30th, where you’ll hear from Checkmarx API Security Product Manager Liad Levy.
如有侵权请联系:admin#unsafe.sh