next holy grail

Posted by deaguero at 2020-03-13

This year's Holy Grail article has been delayed for a long time, because the company is also making products in this direction, so it is deliberately delayed for several months: first, see whether the market has followers and their understanding. After all, start-up companies have to work hard to make a living, and the competition situation needs to be paid attention to all the time. The annual Holy Grail article predicts new safety products that will be successful in the next two years. This year, the direction chosen by the author is bound to be a red sea; start-ups should enter cautiously, because they are bound to face the fierce competition launched by large factories.

Development of application security

In the past decade, application security has never been absent from the industry's focus. The official account message is hoping that the author's request for application security has never been interrupted. Remember the article on new security trends in 2015? Data is the new center, identity is the new boundary, behavior is the new control, intelligence is the new service. Every point represents the market opportunities for startups. Only there is no application security. Is application security not important? Of course not. Software defines the world, no one will deny the importance of software security. Unfortunately, in 2015, the author did not see the application security emerging new technology changes. The evolution of infrastructure brings new opportunities to the application security market, but also changes in the delivery mode, resulting in most of the new capacity being divided up by large cloud infrastructure factories. In the past few years, the lack of technological change, but also in the face of CSP gradually nibbling share, application security manufacturers feel the pressure mountain, are worried about how to make a bright spot of poor products. In this environment, it is difficult for start-ups that focus on technological innovation to hatch stars.

In order to support this conclusion, we might as well compare the changes of OWASP top 10 in 2004 and 2017. In the figure below, the author uses arrows to draw the corresponding relationship between the two lists with a difference of 13 years. Look at the essence through the appearance: carefully study its detailed explanation, we will find that in addition to some differences in the text expression of the list title, almost one specific security control point can be found in two documents without landing.

For example, the first point in the specific explanation of 2004 A10 secure configuration management explicitly refers to unpatched security flags in the server software, which is no essential difference from 2017 A9 using components with known vulnerabilities. 2017 A4 xxE is a new entry, naturally caused by the wide application of XML, but let's take a look at the explanation of 2004 A1 unvalidated input: attackers can tamper with any part of an HTTP request, including the URL, querystring, headers, cookies, form fields, and hidden fields, To try to bypass the site's security mechanisms. Instead of buffer overflow, deserialization vulnerability reveals the change of application system architecture, and Java and other development languages gradually dominate. Disappeared in the top ten of 2004 A9 application denial of service, moved it to the position of 2017 a11, I believe most readers have no objection. In 2017, there is only one new entry: A10 institutional Logging & monitoring, which is just the understanding of the whole security industry for the fundamental change of defense and detection mentality.

I don't know if you are as surprised as I was at that time. Let's say you have mastered the basic knowledge of Web attack and fully practiced it in 2004. Congratulations. After more than ten years, even if you don't work hard to learn new technologies, even if you keep standing still, you won't be ruthlessly eliminated. It's incredible in the fast-growing computer field. For example, in the same 15 years, the security of operating systems and other software has reached at least four or five major steps. If you can't keep up with the development of new technologies, the horizontal movement of the intranet will inevitably be difficult.

Looking back on the development of WAF, a benchmark product in the field of application security, we can see similar phenomena. Open source ModSecurity was released in 2002. Although it is not as easy to use and supportive as commercial products, it has always represented the technical development level in this field. When I put the time back to 2015, the only innovation I can see is the lexical analysis of SQL injection, which started with the open-source libinjection in 2012. Currently, WAF manufacturers are also focusing on the promotion of new features, ModSecurity has been integrated and provided in early 2013. In addition, as CTO, the author of libinjection co founded the eye-catching signal Sciences and became a rising star in the WAF market. After that, ModSecurity introduced the fuzzy hash method ssdeep to detect webshell in 2014. Ctph, the technology used by ModSecurity, came out as early as 2006. The actual effect is unsatisfactory and it is difficult to publicize. Since then, do you remember what new changes have taken place in WAF detection technology?

The author also observed an interesting phenomenon. No matter in the United States or in China, if you communicate with technical personnel of leading manufacturers in NGFW or other product directions, there will always be a feeling that they do not pay attention to WAF at all. In their talks, there is a hidden meaning that they think their technology is old and lack of barriers, the market scale is limited, so they are not willing to invest.

But the author attaches great importance to WAF market. Familiar friends all know that I have said many times in recent years that I regret that I did not firmly invest in WAF products after struggling for half a year in 2015. At that time, I saw the huge potential of WAF in the domestic market: the rare budget growth rate and budget share far exceed the security products in the US market, which is because at that time, the development speed of domestic e-commerce and online business showed signs of comprehensively surpassing the US. But I also saw the serious homogenization of products brought about by the lack of technological innovation, overestimated the product R & D and market attack execution of large factories, and the challenge of heavy investment in sales and different operation modes of the company at that time, and all kinds of seemingly correct reasons finally missed a market explosion opportunity. Three times a day, pay tuition fees to remember and avoid mistakes. In recent years, the author has been trying to find a breakthrough point in the field of application security.

As mentioned above, cloud increment is eaten by CSP. As early as 2015, the author believed that cloud WAF ranked the top three of cloud security products, and that the key direction of cloud providers should be the official account. "Safety is one of the core competitiveness of cloud infrastructure". That year, the industry was still debating whether cloud service providers should be safe or not. Four years later, the market gave a strong answer: this year, analysts report that half of the world's top ten WAF manufacturers are cloud infrastructure service providers. The new opportunities are caused by the change of delivery mode, not technological change, which leads to the development of WAF market not driven by innovation but driven by investment, so the head CSP can have a huge competitive advantage.

The demand for other areas of application security is also strong, but it is difficult to grow on a large scale and support a listed company independently. For example, rasp, waratek, the 2015 RSAC innovation sandbox champion, now also turns to the combination of rasp and WAF, taking the road of signal Sciences; ten years after its establishment, the scale is too much behind. In recent two years, manufacturers provide rasp and WAF integration to make up for their shortcomings. Shape security used to be a dynamic deformation, and its principle is also the number of rasp routes. It is also difficult to go to market. After trying to change direction, it has been changed to rasp + WAF + SDK. Imperva started with database security. The start-up of American WAF market is even a little slower than that of domestic market. Up to now, it has become the Red Sea, and the acquisition and integration are in progress. In addition, this year's innovation sandbox finalist, shiftleft, uses mathematical methods to assist in automatic code vulnerability mining. Although I like its technology very much, I also know that many American investors are not optimistic about code audit products, because they have invested in nearly two decades of code audit start-ups, and the best result is to be acquired. In the face of the dilemma, application security companies are actively looking for turning opportunities. Across half a step, it has become a common strategy for the security industry to expand its scale. The common ones are: threatening intelligence manufacturers to sell IDS, leaking manufacturers to enter SDL through DAST products, representing manufacturers such as rapid7, etc.

With more than two thousand words written, it's obviously not a waste of time, but a preparation for the central idea: Although many application security startups have emerged in the U.S. market in the past decade, there are few successful ones. At present, there is a rare entrepreneurial opportunity with huge market space in the field of application security: API security. New application risk, new security battlefield. Perhaps many readers have guessed this answer, because since the end of last year, the author has repeatedly introduced the basic knowledge of API security in small salons and large industry conferences. New infrastructure will inevitably bring new security product opportunities. As a way to connect all applications and deliver data and functions, API has become a key risk control point that the security team has to pay attention to.

New situation and new opportunities

In the past five years, cloud computing has penetrated into all aspects of the digital economic infrastructure. The huge changes in the market competition situation have led to the ups and downs of many manufacturers, many of which are unable to keep up with the trend and never recover. What will be the far-reaching technological architecture changes in the next five years? There are a thousand Hamlets in the heart of a thousand readers, so different interpretations are inevitable. However, microservices, serverless, and edge computing should be able to cover the answers in most readers' minds. There are three different directions, but they all have one thing in common: API is an essential basic module.

There is a misunderstanding in the industry. Microservices are often regarded as containers. In fact, containers only provide a convenient management method for large-scale deployment. Without microservices architecture, there will be no big development opportunities for containers, and microservices will continue to move forward rapidly without containers. The ease of use of containers will inevitably lead to additional resource consumption, performance fluctuation, governance complexity, and other corresponding limitations. Therefore, when deploying micro services, some enterprises are now experiencing the phenomenon of backtracking from containers to virtual machines or even physical machines. Or in the opposite direction, the more abstract and manageable computing mode is used to support microservices. Similar to serverless, which is used to build microservices, AWS has its own system: lambda, fargate, Aurora serverless, eventbridge, kinesis, etc. In fact, the core of microservice architecture is grid mesh, and the connection of grid is easily managed by API. Therefore, no kubernetes can use microservices, no API, no microservices. Some experts in the industry insist that microservices are nothing more than old bottles of SOA, which is quite the same as the saying that cloud computing is equivalent to virtualization, and will be proved wrong sooner or later. In my opinion, the data bus described by SOA is out of date and will be replaced by the data plane supporting mesh communication transmission. There are many reasons. Since it is the official account of the security industry, this article only points out from the point of view of security: the SOA data bus architecture can not meet the requirements of data security compliance. Only by upgrading to point-to-point service grid, using classified and hierarchical API, strictly authenticating identity and fully authenticating, and following the principle of minimum use of data, can we flexibly achieve the increasingly strict internal control goal of data assets. Let's borrow a diagram to illustrate the ubiquity of API in microservice architecture.

In the past two years, compared with AWS and azure, the capability of domestic cloud manufacturers is more and more far behind. Many people don't understand what a follower strategy is. It's not a new product released by friends today. We can get it done by sending a press release and writing a page PPT in 10 months. Some new products need at least a few years to develop. No matter how many R & D teams of Titan can create miracles. The real follower strategy is to identify the medium-term strategy of the friends three or five years in advance, restore their product planning roadmap, and then layout their resources investment to achieve the goal of following the leaders to launch new products one year behind. If you don't do the homework of competition analysis in a down-to-earth way, when other people's products have been released, you are in a hurry. At most, you need to learn something, make do with an interface, and put the cart before the horse in your face. Some people think that AWS is forced to release fargate by kubernetes. App mesh can't face istio. In fact, it can only be said that he doesn't understand cloud computing and AWS strategy at all, but parrots the banner. Kubernetes is very fierce, istio is very powerful, but just like ten years ago, you will talk about Xen and KVM. Now most of the customers on AWS cloud will not mention hypervisor but only know EC2. Five years later, as long as the customers can easily run containers on AWS and arrange the network connection between applications, they only need to know fargate and app Mesh, whether you use k8s / istio or any other architecture. Even Google, which masters k8s, has launched the same product cloud run. If you can't understand the strategies of the industry leaders, don't talk about follower strategies. Abstract computing, which has existed since the advent of computer, is inevitable and irresistible. There is no exception in the cloud. Serverless has been recognized as the general trend.

Serverless, or function-as-a-service (in fact, the scope is slightly different), is built on the API and provides function delivery in the way of API. All background computing servers are abstracted and invisible to users. Naturally, API plays an important role in it. There is no independent Island device for edge computing. All the interactions between edge computing nodes and the central server on the cloud are implemented through API.

Let's take a look at more popular application scenarios: AI platform capabilities are delivered through API, whether it's image recognition or anti fraud; this year's hot middle platform is essentially API standardization of back-end capabilities; data exchange in the supply chain, without doubt, is also API; there are many. In the process of digital transformation, API has become an indispensable infrastructure.

Since the wide application of API is the general trend, is it more promising to be an API management platform than an API security platform? Earlier last year, when I talked with several investment friends about the direction of the venture, I poured cold water. First of all, it's obviously too late to start last year. If you want to do it, you have to start before the giant can seize the market. As early as three or four years ago, foreign giants have begun to layout, see the table below. Secondly, API management services are significantly affected by customer diversion, and start-ups need to pay considerable customer acquisition costs. In this respect, giants have unparalleled advantages, whether it is Privatization deployment or cloud delivery. Third, the open-source solution has been very mature. Kong, wso2, Ambassador, tyk, zuul and so on have their own advantages, which greatly reduces the threshold of business self construction. Enterprises with certain self-study ability often do not choose to purchase.

The domestic market will face more challenges. In particular, it is inevitable to encounter the question of soul torture: how does the competitive advantage of the start-up company manifest after the giant enters the market? In this direction, it's difficult to establish effective technical barriers. Whether it's performance or function, if you want to break through the level of nginx derivative platform, it's really not something that three or five core team members can handle in a year or two. Do you want to customize the open source distribution? The decline of Hadoop's ecology is obvious. In addition, the standard products of cloud manufacturers will eat up the market share of most small and medium-sized enterprises. There are also successful business system developers who have accumulated the cost advantage in the early stage and will surely move half a step forward in the positive competition. Because API management platform is closely related to business system, customers have a high probability of requiring customized development, which is both an opportunity and a trap for startups. On the one hand, even if the giant gets the order, it may not be willing to do it and leave it to the small company. However, the delivery pressure of the order is high and the gross profit rate is low. On the other hand, direct selling often needs to pay high customer acquisition cost. Non standardized products with high delivery requirements are just wishful thinking. In short, the development speed of scale is limited and the profit space is worrying.

As long as there are changes in infrastructure evolution, there are opportunities for safe entrepreneurship. With API becoming the main channel between internal and external people and application services to exchange and use data, management is increasingly worried about the internal and external threats it brings. Because of the unique characteristics of security market segmentation, the competition situation of API security will be far better than that of general API management market. Although API management manufacturers will provide some basic security capabilities, such as usage restrictions, anti DDoS, anti BOT, identity authentication and authentication, they usually have no ability to go too far to grab the jobs of security manufacturers. In this case, the next thing to consider is how to cut into API security?

Cross segment and cross infrastructure

Although this article begins with application security, API security is not only limited to application security, but also across the fields of data security and identity security, which makes its entry points more and more scattered. Any API security product that only focuses on a specific domain is not complete. What the customer requires is a complete solution that can handle as many risks as possible in this scenario. According to the competitive advantages accumulated in their own history, startups can flexibly choose the entry mode, and then move horizontally to the adjacent subdivisions. For example, the API security products of our company start with data security, and then introduce the detection of risks related to authentication and authentication. At present, they cover the application security.

According to this logic, Imperva, a large WAF factory, is very natural to start with application security. API security has been listed as the top product line under its application security category, which is in parallel with WAF. In the field of Web attack and defense, many manufacturers have accumulated before. Naturally, the first propaganda will cause great harm to API attacks. Imperva product color page includes four key points: preventing API related serious attacks, building an active security model based on OpenAPI specification, integrating security to API life cycle management, and unifying security solutions for websites and APIs. Does it feel very simple? So Imperva is just beginning.

The figure above shows the location of API security in Imperva's defense in depth product system.

Web security has been a high-intensity confrontation for more than 15 years, but API confrontation is just beginning, programmers have not been through the actual practice, it is easy to appear various vulnerabilities. Therefore, in the current stage, it is easy to achieve satisfactory results by attacking API, and considerable output can be obtained by using the existing penetration testing tools. A typical a low hanging fruit, the red team that has made achievements at the end of the year might as well try.

The top ten list of API security of OWASP organization cannot be ignored here, as shown in the figure below. In my opinion, this list pays too much attention to attack and defense technology, lacks the understanding and support of business risks, and it is difficult for the security team to use similar caliber to report to the management. It takes a lot of trouble to apply for the project budget. Therefore, from the perspective of business risk, the author summarizes five API security threats that the management cares about, will cause clear business losses, and have mitigation measures implemented, which have been publicly introduced in many occasions. Limited to space, I won't elaborate here.

You may wish to compare the differences between OWASP top 10 and OWASP API top 10. The limited space will not be discussed in detail here.

This year, salt security, the shortlisted RSAC innovation sandbox manufacturer, is one of the sponsors of OWASP API top 10. It claims that it can detect the behavior of attackers in detecting API, and it is also the direction of application security from its perspective. Unfortunately, in the past year, I have been looking around in various exhibitions but I haven't seen the product demonstration. This situation is also very rare, which makes me wonder.

From identity security to API security is also a feasible way. API is inseparable from identity authentication and authentication. Iam manufacturers are born with ready-made customer base precipitation. The new product line that can be cross sold is the favorite of many management expansion strategies. Ping identity first provides customers with the authority control capability in the API through pingaccess. After finding the synergy, it further acquires elastic beam to improve the API security solution: it is packaged into the pingintelligence product line in the figure below.

The other part of the puzzle above is the monitoring of data flow during the use of API. The product line name is pingdatagovernance. I don't want to overstate the risk of data flow. Although our product has the function of data map five years ago, it has never been widely publicized or necessary to scare users. The reason is very simple. Regardless of the work of monitoring data flow, the ROI of investment is low, and it is not recommended for the security team with tight resources to consider ahead of time. There are quite a few seemingly simple and intuitive concepts in the safety industry. At first glance, they sound very reasonable. Everyone can understand and discuss them, but they can't stand scrutiny. Now, it's very difficult to have a simple and intuitive architecture, at least it's hard to originate from ordinary practitioners. In recent years, there have been hot new ideas such as zero trust and att & CK, which can be easily understood, which can be quickly implemented, and which can not be accumulated with huge investment for many years? In reality, the risk of most data flow scenarios of enterprises is very low. Blind detection is no different from searching for needles in the sea. In a short time, it may win some praise. Long term output is difficult to predict and measure, and cannot be recognized by the management. Trying to master the data flow in large enterprises? The security team may first clarify whether the budget, bandwidth, storage and computing power are sufficient. The most important thing is to have enough staff to ensure daily operation, and then consider whether the number of risks detected is enough to persuade the management to continue to support such a large investment. Think it's blue ocean innovation, in fact, it's a bottomless hole with high input and low output. For decades, it makes sense that the security budget should focus on border protection first, because that's where the ROI is the highest. Continue this idea, find out the risk of data flow, and if you want to achieve performance, the most important thing is to monitor the malicious technology and tactics at the border. The office network is naturally DLP, and the API in the business system field is the first to bear the brunt.

API security is also attractive to management from the perspective of data leakage prevention. In 2018, there were many well-known data security incidents caused by API problems. Venmo disclosed hundreds of thousands of transaction details, T-Mobile leaked 2.3 million user sensitive data, Facebook leaked more than 30 million accounts, and USPS leaked about 60 million accounts. In 2019, landmark, the largest real estate appraisal company in Australia White's API vulnerability resulted in the disclosure of real estate appraisal details and customer information; the investigation found that the root cause of the problem was that the API originally designed to be used only internally was accessed by the attacker from outside its domain; this event seriously damaged the company's reputation, and customers and bank partners competed to find alternative solutions, leading to the resignation of the CEO. Unfortunately, this kind of API data leakage problem is very common, which can not be found by permission detection, and often needs to rely on behavior analysis to capture.

In addition to spanning three sub domains, API security has more difficulties, which need to adapt to a variety of business applications with different architectures in different periods. Traditional industries have a lot of old soap based business systems, which do not follow the OpenAPI or even use rest API, but use WebSockets to transfer XML data. In addition, JSON, protobuf, graphql, RPC, http / 2 and so on. Many times, developers compare orange with apple, and the concept category cannot be aligned. API security products are more complex to handle. Most foreign start-ups only focus on one interface, but it may not work at home.

Is the title of the speech below dizzy? Can't bear to look straight at you? If there's an architect in the company who idolizes big factories and keeps trying to catch up with laboratory technology, the security team must have a feeling of being ruthlessly burned on the fire.

In addition, the API has a wide range of use scenarios, requiring manufacturers to have product capabilities covering a wide range of different infrastructures. The simplest way to deploy is naturally network traffic image. It's easy for everyone to restore rest API communication in HTTP traffic. However, there are not many manufacturers that can correctly respond to the restore when internal employees use TLS encrypted traffic of business system API. The data format that JSON can describe is simple, the business system needs to transmit a large number of PDF forms and office documents, and whether the content is sensitive also needs to be screened. Using S3 compatible object storage, CIFS / SMB, NFS and other storage facilities to transfer data also needs to be able to further identify. The traffic mirrored by the micro service sidecar needs to be able to catch up, and the API gateway also needs to provide plug-in support. The traffic probes distributed around the world need to consider how to gather a large number of logs, how to accurately find and locate the abnormalities in the behavior of 50000 regular employees plus 30000 outsourced computers, etc. all kinds of complex situations need to be considered, and the pressure of the manufacturer's product engineering is great.

Only monitor the data flow between the internal business systems of your company? That covers less than 5% of the risk area at best. The really important risk is not that simply marking the data transfer can be described clearly. For example, call center customer service virtual desktop system and background business order system transmit 1 million pieces of customer data every day. There should be data flow between the two systems and it seems completely normal, so there is no risk? The real threat is hidden in the process of using each API, and only 1% of the data exchange may be a risk. Malicious downloading by privileged users, account leakage and embezzlement, user privilege enhancement, lack of access authentication, accidental exposure of sensitive data, hidden back door interface and so on may cause serious consequences. This is not only to be found by looking at data flow, but also from identity, application Data can be detected effectively only from three aspects.

Ailing API security startups

First of all, we should choose the right direction to start a business, or we will cry. It's no surprise that chronicle was abandoned. Even if the industry tycoon born with a golden spoon tried to go against the trend in spite of the market rules, it would end badly. Similar stories are constantly staged in various industries. API security is not a new thing. It has a long history. It was seven or eight years ago, but it is not until this year that it has emerged. It is just needed and has huge market potential. It is a good opportunity for entrepreneurship. At the same time, API security is destined to be the Red Sea. If you choose this direction, you must seriously consider whether your team's core competence has the opportunity to run out of the leading position among thousands of troops. I have noticed that two American start-ups in this field have been disbanded and closed down, and most of the teams have experienced slow growth and financing difficulties. Therefore, I decided to invest resources at the end of last year. it is very difficult to start an undertaking. The relatively accurate prediction in the past few years does not mean that the author will not make mistakes this time. Readers who want to enter this direction should carefully consider and take risks on their own.

It's hard to do well in API security products. There are many and complex fields, a wide range of functions and a high threshold. Here, we have a rough look at the product directions of several startups mentioned by analysts. Readers can feel the differences between different manufacturers. In addition, we can also draw the conclusion that we should not blindly worship foreign manufacturers, because most of them do so in a very general way, and analysts' regional bias is very obvious.


It has a history of 4 years, focuses on OpenAPI, is headquartered in London, has rich experience in the team, and has experience in axway and IBM before, but the financing is not smooth. Its products offer three capabilities. First, according to the OpenAPI Standard Specification, check whether the submitted API definition meets the security requirements. Secondly, it dynamically checks whether the API service complies with the API definition, reports and summarizes the scanning contents and methods, including response time, received HTTP status code, and unexpected response status code, etc. Finally, API firewall, written in C, docker image and sidecar traction traffic are already standard configurations, which can only work in kubernetes environment, and must be connected to 42crunch platform. I've heard about several issues of its founding team, and I feel that they really have rich experience in API practice, but there are still many obstacles for this product form to enter the stage of large-scale promotion. It's hard for the author to see its future development well, and the team needs to take the initiative to find a turning point.


Founded in October 2017, located in Melbourne, the financing process is terrible. It uses AI to automatically detect and block the use of APIs that attempt to steal data and fraudulently. The next paragraph is the actual use case of machine learning promoted by aiculus.

The neural network model is trained by using the historical data of 8000 + user authentication and access log. Historical data consists of 13 features, including user property parameters collected when a user requests access to the system or enters a physical building. Using these data to train the machine learning engine, it can accurately predict the access allocation, access denial, re authentication and user intention on the platform.

"Into the physical building"? Access control really can barely relate to API. 8000 + users are a good case in Australia, which is really not the scale to boast in China. As you can see, aiculus cuts into the path choice of API security from identity security.

Data Theorem

There has always been a legend in the industry that a start-up company that can develop rapidly without financing is really powerful. Let's just listen and laugh. Don't take it seriously. If you don't burn money, you still want to grow at a high speed. Today's domestic security market is nothing more than a mirage. Most enterprise service companies can't burn money. But there must be exceptions. Data therom is amazing. It employs 300 people, but it doesn't see any public financing information. Founded in 2013, initially mobile security, now it has turned to application security, API security is the business focus. The founder is a 20-year serial entrepreneur with a history of two companies being acquired.

Data therom offers two products, API discover and API inspect. Discover can continuously and automatically discover new APIs in the public cloud infrastructure of customers, record changes of known APIs, and other cloud services related to these APIs. Discover also enables security and operations teams to discover the shadow API, and cloud based analysis engines constantly scan serverless applications, generating alerts and notifying security teams once discovered. The inspection analysis engine continuously evaluates the authentication, encryption, source code, and log of the API to ensure that the API operation function matches its definition, and reports critical vulnerability alerts.

The figure below shows the API security implementation steps recommended by data theorem. There is no common high-rise system of consulting agencies, so it can only be used as a practical reference for landing.


Israeli manufacturers who have raised so little money that they are living a miserable life. Its product introduction is not enough praise, the author is not interested in writing two more sentences. The following slide is about natural language processing recognition API pattern.

FX Labs / CyberSecuriti

Lonely Silicon Valley company, can not get money, the founding team has changed. Do you see that you have lost confidence in API security entrepreneurship? The company's products focus on vulnerability scanning.


Similar vulnerability scanning direction. Also a small team without money.

CloudVector / ArecaBay

This year's RSAC was founded in 2018 with rich experience in the industry. I participated in the founding of netskope. Before that, I was a team member acquired by McAfee. It wasn't until November that it announced $5 million in investment, the company changed its name, and the CEO and CFO were airborne. Its products mainly include three capabilities:

API inspection module aim: fully automatic micro sensor module continuously discovers all APIs connected to enterprise assets, including shadow APIs.

Dart: the depth monitoring module applies the verified machine learning to the specific API blueprint of the customer, drives the automatic identification of API risks, and more importantly, it can detect the behavior that the adversary tries to detect in real time.

API response module arm: the real-time response module can enforce security policies against API abuse, which is the only solution to completely solve OWASP API top 10.

Here's a picture of areca Bay's promotional materials in March this year. There's no more information for limited space.

Are you disappointed? You think the list of manufacturers recommended by analysts can brighten people's eyes. In fact, most of them are at the level of a three legged cat. If you take such a low completion product to cheat the domestic Party A, you can't be spitted out completely. It also shows from another perspective that the demand level of security industry is increasing day by day. If you want to make a good enterprise product, the minimum investment is at least 20 million US dollars in the United States and at least 40 million RMB in China, it is almost impossible to not finance. Want to refute, please don't use the open source project to fool the product by selling the example of hard plug to leave a message to the author. If you boast that a huge amount of financing costs a hundred million yuan to carve out a product, please also ask investors to polish their eyes to avoid entering the pit. The reason is very simple. The gross profit level of domestic security products simply can not support such extravagance.

After the research, the author found that on the quality of API security products, several large companies in the U.S. market are obviously superior to most of the start-ups. I'm afraid that the same situation will be faced in China. At least the top public cloud companies will definitely develop their own, use their own products and try to export them. Therefore, the entrepreneurial team should have a clear understanding of the potential competition, and have enough confidence to face the competition in the product.

The general trend of the market changes with each other. Making API security five years ago will undoubtedly become a wave ahead of being photographed on the beach. At that time, the opportunity was WAF. Now enter API security, with both opportunities and risks. Be prepared to face the front-line manufacturers with large capital investment. If a small company can pass the product barrier, even in the red sea of fierce competition, maybe luck will stand with you, and success is expected.