Reprinted from Weixin Consulting : https://mp.weixin.qq.com/s/SqKrWM5KpBZGQKHB0lxHTw
foreword
In recent years, security issues caused by open source components have occurred frequently: in 2017, Equifax, an American credit reporting company, failed to fix the vulnerabilities in Apache Struts, which led to a large-scale leakage of personal information; in 2020, SolarWinds was hacked, directly causing its customers to be attacked Threats; the exposure of the Log4j vulnerability in 2021 has aroused concern among global companies, and the US Cyber Security Review Board believes that the vulnerability may last for ten years.
The issue of open source components has sparked a wave of concern about the security of the software supply chain. Software supply chain security is often linked to development security—which is somewhat understandable, since a large number of enterprises use open source components to develop the applications they need in their environments. With the emergence of the concept of DevOps, "development" itself is only a part of the business, and development and operation are gradually integrated to form a closed loop - and this closed loop revolves around the application itself of the enterprise.
The security of open source and the integration of development and operation have brought about new changes in security concepts and solutions for applications. Whether it is software supply chain security, DevOps, or DevSecOps based on DevOps, it has brought a certain impact on the field of application security, and even formed some confusion in various concepts and concepts. Therefore, this report does not completely start from a specific security field, but combines the mainstream tools of enterprises between application development and application launch into one report based on their commonalities.
key findings
· Players in the current application security testing and analysis market have their own distinctive competitive products, but there is no solution that can cover all product types; an application security integration platform that can combine products from multiple suppliers will become a major player need.
· Although application security is not the same as software supply chain security, the popularity of software supply chain security has indeed brought great attention to application security. Especially in the field of SCA products, in view of the frequent occurrence of attack accidents based on the software supply chain at home and abroad in recent years, the security management of open source components has gradually become an event that enterprises have to pay attention to.
· The current application security testing and analysis product market is still the largest in SAST products. SCA products have developed rapidly in the past two years, and their proportion is second only to SAST products. In the future, fuzz testing and application security platform products are also worthy of attention.
Whether it is SAST or SCA products, there are still many technical imperfections: for example, SAST needs to reduce the false positive rate while ensuring a low false negative rate, and SCA needs to be able to identify open source based on code fragments more quickly risk and so on.
Application Security Testing and Analysis Overview
Scope of application security testing and analysis
Application security testing and analysis in this report specifically refers to the testing and analysis of the codes in the application and the interaction of the application, so as to ensure the security of the application developed by the enterprise itself; related products include but are not limited to SAST, DAST, IAST, SCA, fuzz testing, application security management platform, etc. However, security products such as RASP that protect the application (rather than detect the security of the application itself) are not included.
Application security testing and analysis, code security, and software supply chain security
The several tools covered by application security testing and analysis are often associated with code security and software supply chain security, and in many cases, various inclusion and inclusion relationships are formed among the three. However, in reality, there are still differences between the three.
Although applications are made up of code, application security testing and analysis is not the same as code security.
Traditional code security is to directly detect and analyze the code in the application to find the loopholes in the code - this part of the function can currently be performed by SAST and SCA. However, relying solely on the security detection of the code is not enough in the current environment: the absence of vulnerabilities in the code itself does not mean that the final application implemented by the code is safe - when the application is running, there may be vulnerabilities in the logic on which the application is based. Vulnerabilities, resulting in the risk of being attacked.
Therefore, judging whether an application is secure only through code is not enough to meet the current needs; a complete application security inspection should also include testing the runtime application, that is, the test needs to be based on the application, not the code.
On the other hand, since the number of attacks caused by open source components and third-party components has increased significantly in recent years and has a huge impact, software supply chain security is often associated with development security. In fact, this understanding of software supply chain security is undoubtedly narrow.
From the perspective of the downstream of the software supply chain, the end user of the software needs to ensure that the relevant software or components can operate normally in their own business environment, and there will be no security risks—this should also include systems based on open source components, and Software provided entirely by third-party vendors. On the other hand, from this year’s Russia-Ukraine war, we must notice that technology also has borders—whether it is open source communities, open source components, or software from third-party suppliers, even if they are currently safe, once If it is not available, it will still cause the organization to be seriously affected. During the Russo-Ukraine War, many European and American companies and organizations interrupted their business and support in Russia, which caused the business interruption of related Russian organizations to be caused by the software supply chain. means to solve.
At the same time, the upstream supplier side of software supply chain security not only ensures the security of products and components from the perspective of development security, but also needs to ensure the security of the whole link from development to delivery, and even operation and maintenance. And when the safety awareness of downstream customers is getting stronger and stronger, whether the supplier can actively provide the safety certificate and ingredient list of related products will also become a factor that must be considered.
Taking the SolarWinds attack as an example, the SolarWinds attack can be regarded as an APT attack based on the software supply chain. SolarWinds itself has ensured the security of its own code in every link and has done testing—however, when the final test was completed and entered the distribution stage, an attacker sneaked in and tampered with the code. This attack is obviously located in the blind spot of the development security field, requiring other security protection mechanisms in the enterprise to discover and block the attack. For SolarWinds users, after knowing that there is malicious code in SolarWinds, how to quickly locate their affected business systems, how to judge whether they have been attacked, and how to respond and defend, this series of behaviors involves security in multiple fields Products - but all because of hidden dangers in the software supply chain. Therefore, software supply chain security is definitely not an area that can be covered by a few security products.
For software supply chain security, application security testing and analysis related products mainly cover the security of the application itself from the development stage to the online stage. Mainly from the perspective of developers to ensure the security of developed applications. However, from the perspective of future development, SCA may open up the relationship between the upstream and downstream of the software supply chain: downstream users can more completely grasp the usage of third-party suppliers' components, so that they can deal with software supply more comprehensively chain of risks.
From development security to application security
In waterfall development and traditional agile development models, the main goal is the completion of software development. When DevOps appears, development and operation are gradually combined—at this time, the protection and detection of applications is not limited to development: for example, IAST is often used in the testing process, and this scenario can already be regarded as the end of the traditional development model. The process of transitioning from a development environment to an operational scenario; for example, RASP (Runtime Application Self-Protection, Runtime Application Self-Protection), which is not mentioned in this report, is also aimed at the protection of applications during actual runtime and is used in operational scenarios security capabilities. In a broad sense, development security guarantees the security of the application during the development phase, but after the application itself is developed, there are real usage scenarios that also need security protection. Therefore, the ultimate protection goal is not to ensure the security of development scenarios, but to achieve comprehensive security from design, project establishment to operation around the developed applications.
Enterprises' choice of development model will vary according to their own business needs; in terms of specific implementation, it will also vary according to the enterprise's environment and IT capabilities—however, there are often many commonalities in application security requirements. Therefore, no matter what development model an enterprise uses, the choice of application security tools will still cover mainstream application security tools.
For different types of application security testing and analysis tools, there is no absolute distinction between good and bad. Each tool itself exists in different development or operation scenarios to solve specific security requirements. What enterprises need to do is to deploy corresponding application security tools at appropriate positions and stages based on application security requirements to achieve continuous security protection for applications.
Application Security Testing and Analysis Current Market Situation
· Application security testing and analysis products are basically in the heat zone of the digital security maturity ladder in 2022: SAST, IAST and SCA are all in the fields of "integrated innovation" and "development market"; fuzz testing is in the field of "integrated innovation" ” and “Emerging Markets”; while DAST is in the stagnation zone.
In the China Digital Security Capability Map 2022 of Data World Consulting, they are all located in "Application Scenario Security" and under the direction of "Development and Application Security".
·In the past two years, due to the increased emphasis on software supply chain security, the overall market size of application security has grown rapidly. Next year, the domestic market for application security testing and analysis products is expected to reach 1.2 billion yuan.
· Judging from the current market, SAST is still the main product in the application security testing and analysis market. It can be said that for enterprises, SAST is a must-have product in application security testing and analysis products. On the other hand, although SCA has not started for a long time, the market response has surpassed SCA, and from the perspective of future demand, it is likely to become the standard configuration in the application security system like SAST. In addition, in the "Others" category, although the current income of application security platform products is not high, the demand will increase in the future; Fuzzing, or Fuzz Testing in "Others", that is, fuzz testing, in the short term It may still not cause large-scale market response, but in the long run, it will also become one of the security tools that enterprises pay attention to.
· From the perspective of customer market regions, East China and South China are the two regions with the highest proportion, both around 30%. The main reason for the large size of the regional market. North China is third, accounting for about 25%.
Comments from some manufacturers
Haiyunan: Haiyunan's SAST incorporates the "agile" methodology, and is the first to propose the concept of "agile white box" to match the development trend of the entire agile development process.
Kude Woodpecker: The main product of Kude Woodpecker is SAST, which is one of the earliest SAST products in China. Its unique flaw algorithm analysis can efficiently detect the loopholes in the source code that may lead to serious flaws, and locate and warn.
Moan Technology: Moan is one of the earliest security vendors in China to promote the concept of DevSecOps. In addition to the basic security detection, Mo'an's IAST also has the detection capability of personal privacy information; its SCA can support two detection modes of source code and binary, and has the component library access and security blocking capabilities. On the other hand, based on its multiple application security capabilities, Moan helps enterprises realize the integrated management of development tools through an integrated platform.
Qi Anxin: As a comprehensive large-scale enterprise that entered application security earlier in China, Qi Anxin has a considerable accumulation in application security. Qi Anxin's application security testing and analysis products are mainly SAST and SCA, both of which have the largest market share in the domestic market.
Sike Cloud: SAST of Sike Cloud can successfully reduce the number of false alarms of products through the "smart reduction" secondary noise reduction technology based on project scenarios; at the same time, its leading incremental testing capabilities in China can also greatly reduce Reduce the number of missed reports of vulnerabilities caused by incremental code. Based on hundreds of millions of open source components and open source code data volume, Sike Cloud's SCA analyzes and matches codes with ten-byte-level code fingerprints, taking into account the two major functional requirements of open source security and homology analysis
Xiaodao Technology: Xiaodao Technology connects the three major software supply chain security atomic capabilities of IAST, SCA, and RASP with a single probe, integrates the "All in one" three-in-one platform, and conducts pilot practice in the production environment of financial institutions to achieve application security. Lifecycle support capabilities.
Suspension Mirror Security: Suspension Mirror Security is one of the main manufacturers promoting DevSecOps and software supply chain security in China. The IAST product of Xuanjing can be combined with the enterprise's DevOps platform to fill the needs of rapid security testing in the CI/CD pipeline; its SCA product can use the ability of Xuanjing's IAST to detect open source components in the running state. In addition to commercial SCA products, Xuanjing's open source SCA products have also raised the security awareness of a large number of developers and used open source components more securely. In addition, the Fuzi platform of Xuanjing Security can provide enterprises with full-process DevSecOps security management capabilities in a platform manner.
In addition, since the dot matrix of capabilities such as platform products and fuzz testing is not included this time, the following companies are still worthy of attention:
Billion Technology: Among all development security suppliers, Billion Technology is characterized by being a platform. Through the ASOC platform, SCA, SAST, IAST, DAST, Fuzzing and RASP and other development and application security tools are integrated and linked. The concept of "continuous application security" system proposed by World Consulting. This concept has been quickly accepted by many manufacturers and users of development and application security, and will be one of the important development trends in this field.
Yunqi Wuxian: Yunqi Wujian focuses on fuzz testing, and the importance of fuzz testing has attracted the attention of the industry. For example, in response to the executive order of the President of the United States, the National Institute of Standards and Standards of the United States included fuzz testing as the minimum testing requirement before software leaves the factory.
SAST
SAST (Static Application Security Test) refers to scanning the source code of the application without running the application to find potential security risks. Through SAST, enterprises can automate code security analysis, integrate with their own development process, discover security vulnerabilities in advance and try to fix them.
Generally speaking, SAST is a security tool for developers.
SAST capability dot matrix
The dot matrix divides SAST manufacturers into three types:
Fusion sources: Comprehensive security vendors with many different security product capabilities.
Capability source: A manufacturer that is more prominent in a certain technical feature, or enters the field of application security testing and analysis from a unique track.
Source of focus: Vendors with application security testing and analysis capabilities as their main capabilities.
·A total of 8 manufacturers finally participated in and entered the SAST bitmap, namely: Ai Encryption, Haiyunan, Kaiyuan Wangan, Kude Woodpecker, Moan Technology, Qi Anxin, Think Cloud, and Xiaodao Technology.
Value and limitations of SAST
The value of SAST is pretty obvious:
· Wide range of detectable languages.
·Be able to conduct overall and comprehensive detection on the source code of the application.
· Early detection of vulnerabilities, thereby reducing the cost of remediation.
However, SAST has also been criticized for having too many false positives. There are many reasons for SAST false positives: For example, SAST may lack analysis of the overall application, but some "vulnerabilities" may have been fixed in other parts of the application or related risks have been limited, thus forming false positives; another On the one hand, some SAST tools also have deficiencies in the formulation of detection rules, resulting in false positives.
In the current domestic market, the mainstream way to reduce false positives is still to adjust the vulnerability rules and vulnerability types: to reduce the false positive rate by only alerting the vulnerabilities with very clear judgment conditions, or only the vulnerabilities that have a greater impact on users ; At the same time, mark and retain other potential loopholes for easy query and review. Although this method can reduce false alarms and generate excessive alarms, it also leaves a certain hidden danger of false negatives, and the final balance still needs to be performed by the user.
Another way to solve false positives is to change the existing SAST mechanism-it is no longer to find vulnerabilities through line-by-line scanning, but based on machine learning, artificial intelligence, semantic analysis and other methods, which have a certain impact on the application itself. On the basis of understanding, vulnerability discovery and identification are carried out.
Since SAST itself performs security detection without running the application, SAST cannot find runtime or runtime environment-related vulnerabilities. However, the security of applications and development itself cannot be solved by a single tool. In addition to SAST, there are other security tools that can discover related hidden dangers.
SAST key capabilities
The security capabilities of SAST products can be measured from the following dimensions.
rule base coverage
A key value of SAST lies in the breadth of its monitoring: not only the breadth of the overall source code analysis, but also the breadth of language coverage. Therefore, a SAST product needs to pay attention to the richness of the development framework, quantity, and vulnerability types it supports, so as to ensure that its detection and analysis capabilities can fully cover the needs of the enterprise development environment.
Incremental testing
The amount of code in enterprise development projects is huge, and it is obvious that testing the entire code every time will consume a lot of time. Therefore, SAST often needs to analyze only the changed part of the code through incremental testing.
However, no matter the code is added or modified, it may be associated with the previous code to generate new vulnerabilities. Therefore, what incremental testing needs to do is not only to test the vulnerabilities generated by modification or addition, but also to be able to identify the correlation between the modified and newly added code and the previous code, and on this basis, detect whether there are new The generation of loopholes.
On the other hand, incremental testing also needs to take into account the problem of "vulnerability inheritance": that is, for codes that partially fix some vulnerabilities, whether it is necessary to re-detect and alert other previously detected vulnerabilities. If these vulnerabilities are not repeatedly alerted, there may be a risk of false negatives.
Vulnerability location and analysis
The current SAST products can basically locate the location of the vulnerability to the row. However, in fact, the position where the vulnerability is exploited may be in a certain line, but in fact the root cause of the vulnerability is the code context association. Therefore, the location of the vulnerability should not be limited to a certain line where the vulnerability occurs, but can locate and display the associated chain generated by the entire vulnerability, so that the vulnerability can be analyzed and repaired more effectively.
The balance of false positive rate and false negative rate
As mentioned above, the high rate of false positives is a major problem with SAST. Although some SAST products can reduce the false alarm rate by only alerting certain vulnerabilities, this will undoubtedly greatly increase the false negative rate.
There needs to be a balance between the false positive rate and the false negative rate. This balance is not only determined by the development team of the enterprise, the SAST product itself needs support. There is a huge gap between only reporting certain vulnerabilities and alerting all possible vulnerabilities. The current SAST product also needs to be able to smoothly support the transition of the alarm threshold between the two, so as to help the development team to distinguish between false positives and false negatives. find an acceptable balance. Different companies maximize the security of source code according to their own development and security capabilities.
Detection speed under DevOps
Although SAST's automated detection capabilities can be performed without human operation, so that detection can be performed outside non-working hours, some companies still want to detect problems in source code in a more real-time manner in DevOps scenarios. In this scenario, certain requirements will be placed on the detection speed of SAST.
SAST market situation
· SAST is the largest market area among application security testing and analysis products. However, the domestic market size in 2021 will only be 230 million yuan (the revenue of foreign manufacturers is not counted). In the next few years, there are two directions in the domestic SAST supplier market worthy of attention: First, in this survey, only Qi Anxin, a comprehensive security vendor, finally entered the dot matrix. However, during the survey, it was found that there are several other Comprehensive security vendors are also developing their own SAST-related products—by guiding customers to realize the security needs of development, these comprehensive vendors are expected to further expand the domestic market after their products are released; on the other hand, foreign development security suppliers are developing There is still a considerable market share in China, and with the requirement of localization, this part of the market will gradually be transformed.
·At present, the delivery mode of SAST is mainly a single standardized product, accounting for 74%. One of the current features of SAST is still the ability to quickly deploy to user environments and put it into use. Therefore, a single standardized and powerful SAST is easier to gain the trust of customers.
·From the perspective of sales methods, SAST's capabilities are mainly direct sales, accounting for 70%.
·SAST's current main market is in the financial sector, accounting for 45%. The financial industry itself has a huge scale, and has high requirements for business iteration and application updates. At the same time, it also takes the lead in the importance of digital security. Therefore, the financial industry is a major market in all fields of application security.
SAST case: T case of a large state-owned enterprise (this case is provided by Sikeyun)
scene introduction
T, a large state-owned enterprise, is the only enterprise that provides information services to the State-owned Assets Supervision and Administration Commission of the State Council, a world-class information and digital technology platform provider, a model of safe production, and nearly 60 subsidiaries all over the world. There is an extreme pursuit of the quality, reliability and security of the business information system. In the process of continuous business expansion and accelerated development, how to ensure the safety, stability and reliability of the information business system is the top priority for the company to achieve rapid development.
client needs
Large state-owned enterprises have many T development projects. The three major R&D centers are located in Beijing, Chongqing, and Shenyang. The level of developers is uneven. After many businesses go online, various code-level security loopholes are found. Not only do developers spend a lot of time and energy on repairs, but the security risk of business systems being attacked may also affect normal external services, resulting in damage to corporate reputation and economic losses.
T, a large central enterprise, actively embraces the security concept of "shifting security to the left", hoping to prevent code security vulnerabilities, code quality and performance problems under the agile development mode, and reduce the risks caused by security vulnerabilities in the source code before the system goes online. Reduce security risks and reduce vulnerability repair costs.
Large-scale state-owned enterprises T plan to build a complete development security system, focusing on secure coding standards and source code security testing standards, and require SAST tools to be seamlessly integrated with CI/CD systems, version management, mail systems and other platforms to realize from code Acquisition, test execution, distribution of test results, email notification, and full automation to achieve efficient "unattended" code security testing. At the same time, establish and implement a security development capability training plan for developers to reduce application security risks from the root.
solution
According to the development project management system of large central enterprise T, Sike Cloud integrates its own SAST detection tools with the existing tool chain, assists customers to formulate and improve relevant processes and specifications in the development process, and supplements safety training to improve personnel safety development capabilities , Build a complete, standard, traceable, and measurable code security management system.
(Picture: Sikeyun’s source code security implementation plan)
•Security test management standards: Sikeyun assists large central enterprises T to formulate their own source code security test standards according to the characteristics of their own business information systems, and directly configure them into the Starling SAST system to form a landing and executable base of safety (safety gate).
• Secure coding specification : Sikeyun combines the internal personnel training system of the enterprise, corresponds to the security testing standard, provides secure coding specification, and provides secure coding guidance for developers. By consulting this guide, developers can quickly grasp the avoidance methods of common security vulnerabilities and the repair methods of the vulnerabilities, improve the security programming ability, and improve the efficiency of vulnerability repair.
Fully automated testing system: Sike Cloud Technology integrates its own SAST into the existing CI/CD (Jenkins) tool chain according to the existing development and testing process of the large central enterprise T, and improves the security management of the agile development platform to provide , Testing and security management personnel provide a fully automated solution to achieve full automation from code acquisition, test execution, test result distribution, email notification, and efficient "unattended" code security testing.
· Secure coding knowledge system : Sikeyun also assists large state-owned enterprise T to establish a secure coding knowledge platform, secure coding standards, and organize multi-form and multi-type security knowledge training. Provide targeted security empowerment for development, testing, and security personnel. The training content includes development security awareness, security design, security coding, security testing, security vulnerability repair, etc., to help them improve their security development capabilities.
(Figure: Sikeyun's source code security management system)
program value
ØLiberation of manpower : Source code security testing is fully automated, including start-up testing, issuing reports, security audits, data statistics, sending notification emails, and other tasks. Basically, "unattended" testing can be realized.
Ø Discovering vulnerabilities "in the first place" : When source code security testing becomes simple, convenient, and low-cost, security testing can be advanced to the earliest stage of project development to realize "developer" testing, increase testing intensity and frequency, The first time to find security holes.
ØImplementing the system : Establishing a source code security management system and making the system instrumental can effectively implement the security testing standards formulated by the enterprise in the testing process from paper.
ØCollaborative auditing : Multi-departmental and multi-role collaborative auditing of security vulnerabilities can be carried out, reducing communication costs between various departments, speeding up auditing, and submitting vulnerability repair efficiency.
ØSecure coding : formulate secure coding specifications, combine secure coding with security testing, use test-driven development, fix vulnerabilities with specifications, and continuously iterate, greatly improve the level of secure coding of all developers, and solve security problems from the source.
Customer Reviews
"Sike Cloud's SAST code security fully automated testing solution, based on our actual needs, implements every link of code security testing. The plan combines "safety testing standards", "automated testing tools", "secure coding "Guide" is a three-in-one system that assisted us in completing the basic concept of "shifting security to the left". It not only met the security management requirements of the Cyber Security Law and the Ministry of Security 2.0 and above, but also discovered and repaired a large number of security loopholes very early. Improve the efficiency of vulnerability repair, greatly reduce the incidence of security incidents after the business information system goes online, and reduce security risks.”
——Director of the Safety Testing Division of this large state-owned enterprise
IAST
IAST (Interactive Application Security Test) identifies potential attack threats and application vulnerabilities by monitoring information about the environment in the application's running state, and is usually used in the testing phase.
In general, IAST has three deployment modes:
·Bypass traffic: The mode of bypass traffic is technically biased towards the black box scanner mode of the Web. Although there is no need to configure the agent in the target application of the test, this method is prone to generate a large amount of dirty data and reduce the development efficiency in CI/CD.
·Active instrumentation: Active instrumentation injects the agent into the target application of the test, and collects information on the position where the data entered from the outside may eventually trigger the vulnerability, so as to monitor whether there is a vulnerability. The active instrumentation technology may cause many traffic replay problems, so dirty data may also occur. At the same time, the active instrumentation technology may also consume a lot of time. Although it can detect known vulnerabilities with low false positives, it is not suitable for the rhythm of CI/CD.
·Passive instrumentation: Passive instrumentation can make up for the defects of active instrumentation. Passive instrumentation also needs to deploy an agent in the target application of the test, but the passive instrumentation technology remains silent during the test, and only collects the changes and flow behavior of the incoming external data stream in the internal application to analyze whether there are security risks. Since there will be no packet replay, tampering, etc., the passive instrumentation mode can quickly test the application and will not generate dirty data.
From the perspective of the future, IAST will eventually focus on passive instrumentation.
IAST bitmap
The dot matrix divides IAST manufacturers into two types:
Capability source: A manufacturer that is more prominent in a certain technical feature, or enters the field of application security testing and analysis from a unique track.
Source of focus: Vendors with application security testing and analysis capabilities as their main capabilities.
·A total of 6 manufacturers participated in and entered the IAST dot matrix this time, namely: Haiyun Security, FireWire Security, Kaiyuan Network Security, Mo'an Technology, Xiaodao Technology, and Xuanjing Security.
IAST value and limitations
IAST is currently a popular product in the domestic application security market, and its advantages are very obvious: the passive instrumentation mode can meet the fast pace of CI/CD, and at the same time, the relatively low false positive rate allows enterprises to focus on those real problems— —Especially if these problems do exist in actual usage scenarios.
At the same time, SAST detection cannot cover runtime vulnerabilities, but IAST detects vulnerabilities by testing applications in the running state, and the two can make up for each other.
On the other hand, IAST can also provide a complete tracking chain for vulnerabilities, helping relevant personnel to fully analyze the associated functions, so as to take the most appropriate repair measures.
However, the limitations of IAST are also obvious. The biggest problem is that the number of languages supported by IAST is very small, and currently only supports tests in a few mainstream languages. In addition, the implementation of IAST also relies on a relatively mature development environment, which requires developers to be able to design various test cases to cover the complete application runtime-related functions, otherwise there may be false positives.
IAST Key Capabilities
The selection of IAST tools can consider the following three aspects.
language coverage
Although the small number of languages supported by IAST is a major weakness of IAST, for some large-scale development projects, it is very likely that many different languages will be used. Therefore, IAST suppliers need to ensure that they can provide as many IAST language support as possible. Currently, domestic mainstream IAST manufacturers can cover Java, PHP, Python, Node.js, Go, .NET (including .NET Framework and .NET Core). Enterprises need to start from their own business needs, try to ensure that IAST suppliers can cover the language used in their own development environment, and understand the future language support plans of IAST suppliers to meet their own business needs.
Vulnerability detection efficiency and effect
The early deployment of IAST is relatively more complicated than that of SAST, because IAST testing requires a certain amount of manual work. Therefore, the templates provided by IAST suppliers in the products and the services provided in the whole process are extremely important. Rich and practical templates and high-quality services can help enterprises put IAST into their own environment as soon as possible and play a role.
On the other hand, the use effect of IAST not only needs to be based on the detection data of vulnerabilities, but also needs to consider the detection and analysis of vulnerabilities. IAST is still a developer-oriented security tool, so it needs to be able to guide developers to fix vulnerabilities through vulnerability reports that developers can understand, including the impact chain of the vulnerability, the scope of the vulnerability, and the specific threat situation. wait.
IAST market conditions
· IAST's market will exceed 100 million in 2021. However, since there are fewer security vendors focusing on this field, the market size itself will be limited to a certain extent by the capabilities of vendors. On the other hand, IAST also has certain requirements on the IT construction level of enterprises, which will also become one of the restrictions on the promotion of IAST.
·At present, the delivery mode of IAST is dominated by a single standardized product, accounting for 82%.
·From the perspective of sales methods, IAST's capabilities are mainly direct sales, accounting for 83%, and the number of OEMs is very small.
·IAST's current main market is also in the financial sector, accounting for 36%. The financial industry has a high degree of ITization, and the demand for more flexible and efficient testing products is more urgent. The operator field also has a similar demand, accounting for 19%.
SCA
SCA, Software Composition Analysis, software composition analysis, is a tool to analyze the components in the target software to identify the relevant information of the open source components and further demonstrate its security.
SCA can be said to be a product of the open source ecosystem: when more than 90% of the code in the enterprise development environment comes from open source components, the security of these open source components needs to be verified and tracked. Nevertheless, the analysis of open source components in its own projects is only part of the value of SCA; from the perspective of the software supply chain, ideally, SCA should also have the ability to analyze the components of related software provided by third-party suppliers—— Because third-party suppliers themselves are also an important part of the enterprise software supply chain.
However, there are still many problems in the current implementation of SCA, and the future technological development deserves attention.
SCA bitmap
The dot matrix divides SCA vendors into three types:
Fusion sources: Comprehensive security vendors with many different security product capabilities.
Capability source: A manufacturer that is more prominent in a certain technical feature, or enters the field of application security testing and analysis from a unique track.
Source of focus: Vendors with application security testing and analysis capabilities as their main capabilities.
·A total of 8 manufacturers participated in and entered the SCA dot matrix this time, namely: Haiyunan, Kaiyuan Wangan, Moan Technology, Qi Anxin, Sike Cloud, Xiaodao Technology, Xuanjing Security, and Yunyi Technology.
SCA core value
Homology analysis
SBOM (Software Bill of Materials, Software Bill of Materials) is a list of recorded software components, including third-party software and open source components used and their versions, credentials, vulnerabilities and other information. Through SBOM, SCA can output the analyzed and sorted information through formatted documents, helping enterprises to carry out "asset management" at the software level.
Considering that the existing environment of the enterprise already contains a large number of open source components - and there is a high probability that the open source components used are not recorded, the first task of SCA for most enterprises is to clarify the use of open source components in the current environment and source and collate output SBOM documents. Enterprises first need to use SCA to discover existing open source components in their environment, especially components with outdated versions, components that have stopped updating and maintenance, open source components with unknown sources, and components that are no longer used in the latest business systems, etc. The software component of the direct threat. Through SCA to output SBOM documents for existing software components, enterprises can have a more comprehensive understanding of the security status of their current enterprise IT environment, so that they can start to deal with existing threats.
After sorting out the software components currently used by enterprises, the next step is to normalize open source component management. By integrating SCA tools into the development process, it is possible to standardize the reference of open source components, track and confirm the open source components used, so as to continuously grasp the software components used by enterprises and avoid blind spots in the use of open source components during the development process.
Security Analysis and Management
After gaining a clear understanding of the components within the environment, the next step for an organization is to discover and manage security vulnerabilities within the components. This capability is not only to discover which vulnerabilities exist in known components, but also to manage these vulnerabilities: including prioritizing the severity of vulnerabilities based on their own environment and business, and providing disposal suggestions (such as updating to a certain version )wait.
The security analysis and management of software components is also a continuous task, and open source components and software from third-party suppliers will also be updated or new vulnerabilities will be discovered. SCA also needs to be able to provide organizations with up-to-date software component security information and disposition recommendations.
Dependency and business association analysis
In addition to security, dependencies between components (dependencies) is also an important value of SCA.
Since today's software components are composed of a large number of open source components, there are mutual dependencies between components. Once a component has a vulnerability, it often affects other components and systems associated with it. Therefore, enterprises need not only a list of third-party software and open source components in their own environment, but also need to understand the dependencies between components and software, so as to quickly understand the impact of vulnerabilities in specific components and software on the IT environment .
On top of this, Digital World Consulting believes that the ultimate goal of enterprises developing business applications and purchasing third-party software is to ensure the smooth operation of enterprise business. Therefore, the management of open source components and third-party software should not be limited to the technical level, but also need to cover the business level: based on the dependencies between components, further linking components and business, can have the opportunity to quantify the software supply chain from the business level risks and impacts, and build corresponding response plans.
open source compliance
Compliance issues with open source components also deserve attention. Different open source components have different open source licenses, and have different requirements for the usage specifications of open source components. For the consideration of legal compliance, enterprises need to abide by the provisions of open source licenses when using related open source components. SCA can provide compliance-level suggestions and audits on the way enterprises use open source components, helping enterprises avoid hidden dangers caused by illegal use of open source components; this aspect is particularly important for business systems related to overseas business.
SCA key capabilities
open source knowledge base
The first task of SCA is to sort out the source of each component in the software. Therefore, SCA itself must have a huge knowledge base in order to correspond to the software components in the enterprise environment: this includes the open source component library to have the basis for identifying the source of open source components, and the vulnerability library to analyze the security of the components and license them. The certificate library can meet the requirements of open source compliance.
Component Identification and Analysis
Based on the open source knowledge base, SCA needs to be able to identify the specific components used in the application, so as to find out whether the application has risks caused by open source components.
The current component identification methods are source code and binary. Source code identification starts directly from the code to discover the source of components; while binary identification analyzes the binary files formed after the developed application has been compiled.
Binary identification can be used at a later stage than source code identification. Since the analysis is based on the final binary file, files that have been tampered with during development or maliciously introduced can be checked. On the other hand, from the perspective of future development, it will become more and more important for enterprises to self-check the usage of components of software suppliers, and the software provided by software suppliers is often the final binary file, which makes binary recognition technology become more critical. However, at present, compared with source code recognition, there is still a big gap in the technical maturity of binary recognition, and it will take some time to break through.
Visualization ability
After SCA clarifies the components used in the organization's IT environment, the next step is to analyze the dependency relationship between different components. However, it is obviously not enough to clarify the dependency relationship from the system level. The ultimate goal of security tools is to help security personnel achieve the required security goals: therefore, it is necessary for security personnel to be able to clearly grasp the relationship between different components in the environment. Relationships are the value of SCA in clarifying dependencies—that is, the ability to visualize related components in the environment through SCA.
Through the visualization capability of SCA, the organization can understand the impact of different components and the software where the components are located on the business, so that they can more accurately assess the risks they face. On the other hand, after some significant vulnerability information, if there is Supported by component visualization capabilities, organizations can immediately locate the scope of impact of relevant vulnerabilities in their own environment and business impact, and respond to relevant vulnerabilities based on their own conditions.
Difficulties in implementing SCA
Use of open source knowledge bases
At deployment time, the use of open source knowledge bases may not be satisfactory: even if the SCA vendor itself has a large amount of open source component information, it may not be fully available to users.
The main reason is that many companies still require suppliers to provide products through local deployment or private cloud deployment, rather than the supplier's own cloud for empowerment. Therefore, SCA providers need to deploy their massive data locally to the user side. In each update, it is also necessary to replace a large number of physical hard disks, which will cause great difficulties in the deployment and update of SCA.
At present, there are two solutions to this problem, but both require users to change themselves.
The first way is that users gradually accept SCA providers to provide services in the cloud, thereby avoiding a lot of inconvenience caused by local deployment.
Another way is that users need to establish a good usage specification of open source components during the development phase, such as only using open source components from fixed and trusted sources. The lack of standard development of open source components will lead to the introduction of a large number of open source components from unknown sources into the project, so that the SCA open source knowledge base is blindly pursued to be large, wide and complete, potentially adding a lot of unnecessary open source component information. Once the use of open source components in the development environment can be standardized, the requirements for the number of open source component libraries can be greatly reduced. With compression technology, the size of the open source knowledge base can be reduced to less than 20Tb, and each incremental update can Do it within 1Tb.
Code fragment recognition ability
One of the challenges SCA currently faces technically is code fragment detection capabilities. If the developer directly references the entire open source component to the project, then the referenced component can be identified through the package manager. However, developers will also only refer to a part of the code in the open source component. At this time, it is necessary to identify the source of the open source component through code fragments to avoid related risks.
In addition to the ability to identify code fragments accurately and effectively identify code sources, the granularity of identifiable code fragments and recognition speed are equally important. However, overall, open source component identification technology through code fragments is still in the development stage.
Binary Detection Capability
Binary detection capability is another technical development challenge for SCA. Detection from binary files can perform secondary detection on compiled applications, and discover tampered behaviors of open source components after they are stored in the library. On the other hand, mature binary detection capabilities can also detect software from enterprise software suppliers to clarify the security of related components used.
Although the usage scenarios of binary detection technology are very valuable, the technology of binary detection itself is currently in the development stage, and neither the detection speed nor the accuracy is very ideal.
SCA market situation
· As the security of the software supply chain has been paid more and more attention in recent years, SCA, as an important tool for open source component governance, is also rapidly expanding its market size. The earliest batch of SCA customers were mainly foreign manufacturers' products; with the requirement of localization, domestic manufacturers are expected to transform this market.
·The delivery mode of SCA single sign is mainly based on a single standardized product, accounting for 71%. The amount of difference between the customized product and the operating mode and as a certain functional mode in the project is close.
·From the perspective of sales methods, SCA's ability is mainly based on direct sales, accounting for 79%.
·SCA's current major customers are also in the financial sector, accounting for 42%. Followed by operators and the Internet industry. The Internet industry has a large demand for SCA, but the Internet industry itself has many excellent IT talents and security talents, and is often self-sufficient; in addition, the Internet industry also tends to use foreign SCA products.
Practice of open source governance in a large national comprehensive securities company (this case is provided by Xuanjing Security)
customer background
A national large-scale comprehensive securities company adheres to the value of "leading business with technology and being customer-oriented", vigorously develops financial technology, builds core competitiveness in information technology, and comprehensively applies emerging technologies such as artificial intelligence, big data, and cloud computing. Independent control and innovation are the corporate IT culture, and we will continue to optimize the construction of information systems, provide customers with high-quality services, and help the rapid development of business.
client needs
In recent years, open source technology has developed rapidly. While the wide application of open source technology provides convenience for enterprises, it also brings risks such as open source vulnerabilities, open source licenses/intellectual property compliance, etc. Enterprise software applications include various sources such as outsourcing, self-research, and cooperative development, including traditional CS, BS, microservices, and other architecture types, and involve C, C++, Java, JS, and other development language source code management. For complex application environments, open source governance tools need to have strong compatibility and adaptability. How to quickly identify the existing vulnerabilities, software licensing issues, and malicious code issues in the third-party components of the application, so as to prevent the application system from being attacked and damaged. At the same time, there may be some unknown and unpublished issues in the use of the old third-party components. , and the 0day problem that has been fixed has become a pain point for enterprises.
Program realization
In order to ensure the safety of products that introduce open source components, the securities company established an internal open source governance system based on the characteristics of open source software and combined with the actual business situation to ensure the security of the software supply chain from the source. The information technology department is responsible for the introduction of open source software, detection of open source software, management of open source licenses, risk assessment, security training and other security risk management during the use and operation of open source software.
In order to achieve the effective implementation of open source governance, the securities company designed corresponding control mechanisms in the links of software supplier management, open source software introduction, security risk detection, security threat intelligence monitoring, and open source software withdrawal management.
uSupplier access mechanism : For purchased commercial software, it is necessary to evaluate the qualification and level of the supplier, and set the access threshold according to the level;
u Open source software introduction management mechanism : formulate and maintain software version baselines and black and white lists, and the introduction of open source software needs to meet the requirements of the baseline and black and white lists.
u Open source software security risk detection mechanism : The application system needs to scan the open source software risk before going online and during operation. Before going online, perform scans at the stuck points in the requirements development management process and application change management process, and prohibit applications with open source software vulnerabilities from going online; during operation, regularly conduct open source software security risk scans, push relevant vulnerability work orders and deal with security vulnerabilities.
uOpen source software security risk monitoring mechanism : Unify open source software information records to form a bill of materials for open source software, and at the same time carry out normalized threat intelligence tracking. When new compliance issues or vulnerability risks break out in software, timely warnings can be made to carry out risk management and control.
uOpen source software exit management mechanism : For software that is old, no longer maintained, or has security risks, it will be exited after evaluation by the technical and security teams, and the software version baseline and black and white lists will be updated synchronously.
(Open source risk governance process of a securities institution)
Specific practical steps:
The securities company's open source governance work is highly integrated with its own DevOps-related processes, platforms, and tools. Actions such as open source software introduction detection, license detection, and vulnerability detection are all embedded in the application requirements development management process and continuous delivery pipeline.
Among them, the use of product tools to record the basic information of product construction improves the traceability of software construction, and can perform reverse dependency analysis based on dependency information, quickly locate the scope of impact of component changes, and provide risk assessment capabilities.
Use the Yuanjian OSS open source threat management and control platform (referred to as "Yuanjian OSS") of Xuanjing Security to conduct security risk management of open source components during the development and testing phase. Based on core capabilities such as open source application defect detection, multi-level open source dependency mining, and in-depth code homology detection, Yuan Jian OSS accurately identifies third-party open source components referenced in the application development process, and deeply explores various security vulnerabilities and open source protocols hidden in components. risk. Source Jian OSS focuses on the third-party components and dependencies dynamically loaded during the actual operation of the application system, and conducts in-depth and more effective threat analysis on this basis. Embed source identification OSS into the process of requirements management and development testing, automatically trigger OSS component scanning after the coding is completed, push defect work orders according to the scanning results, and completely block the source of the introduced vulnerable components.
(Source Jian OSS DevSecOps deployment diagram)
Use the HIDS online production environment to manage the security risk of open source components during the operation phase, scan all hosts in the online environment in real time, and detect the introduced risk components. After the vulnerability management platform synchronizes the detection data, it pushes a work order to supervise the completion of component vulnerability repair.
Program effect
Since the securities company launched the open source governance work, it has built a relatively complete open source governance system. In the daily research and development process, the securities company highly relies on nearly 10,000 open source components, and even built a distributed core securities business system based on open source technology. At the same time of delivery, good open source risk governance effects have been harvested.
u Integrate with the R&D pipeline to form a closed-loop risk management of open source software
The entire open source security risk management system is based on the GitLab source code library, JIRA development requirements management process, continuous integration pipeline, and continuous delivery product library. Through open source software risk detection tools such as Xuanjing OSS and product detection, the risks of open source software are discovered. Governance capabilities such as governance, repair, and record tracking are embedded in the application lifecycle management process to achieve endogenous security. At present , the open-source software risk closed-loop management process has covered all application systems of the securities company , tracking nearly 10,000 open-source software, and the vulnerability detection effect is remarkable .
u Carry out security card point management in the R&D process, and the vulnerability repair efficiency and repair rate are high
The securities company has been conducting threat intelligence tracking and open source software vulnerability management for a long time. When an open source software security vulnerability warning occurs, the information security team can initiate a vulnerability scan in a timely manner, and push a work order through the vulnerability management platform for follow-up repairs. From vulnerability warning to work order push , the whole process is completed within 24 hours . The daily vulnerability tracking and repair rate is as high as 95%, realizing efficient and high-quality open source software security vulnerability risk management .
u Improve the security governance and operation level of the software supply chain
After the securities company introduced the open source governance detection tool, on the one hand, it discovered the security risks of a large number of third-party open source components; SBOM software bill of materials, etc., to improve the security governance and operation level of its own software supply chain.
(Yuanjian OSS application scenario for securities users)
Customer Reviews
The construction of the company's open source governance system will continue to develop from point to point, and continue to strengthen the organizational management system and risk management mechanism in the governance process of software testing and selection, technology use management, technology operation and maintenance management, regular health assessment, and software exit management. As a leading manufacturer in the field of software supply chain security, Xuanjing Security has innovative and advanced technical products and stable and complete solutions in open source governance. In the practice of the open source governance system, Xuanjing Security actively communicated with various departments of the company, continuously polished the OSS deployment process of Yuanjian, and finally realized the soft implementation of the SCA open source governance tool within the company. In the future, we are very willing to conduct in-depth discussions and reach a cooperation upgrade with Xuanjing Security on the security governance and operation of the software supply chain.
other
Application security testing and analysis products are not limited to the above-mentioned three types: SAST, IAST and SCA. However, other products are relatively small in market, therefore, no research was carried out. However, the following three application security testing and analysis products are still worth mentioning.
DAST
DAST (Dynamic Application Security Test, Dynamic Application Security Test) conducts security testing in the running state of the application to discover potential security risks. Generally speaking, DAST is used to test the basically completed applications before the application goes online and in operation status.
DAST tools do not need to know the source code of the application to test, and it does not depend on the type of application. On the other hand, DAST's testing method is closer to the tools used by actual attackers, so it can more realistically simulate real-world attack scenarios.
However, the actual use of DAST is not ideal. Although the testing method of DAST will be closer to the attack scenario, the scope of its testing is largely limited to common attack types, and the coverage of vulnerability detection is very insufficient, which is prone to a large number of false negatives. At the same time, DAST has higher requirements for users, and a certain amount of security knowledge is required to use DAST and understand the reports generated by DAST. Finally, even if a vulnerability is discovered through DAST, it is still difficult to locate the vulnerability.
Fuzz Testing/Fuzzing
Fuzz Testing, or Fuzzing, is fuzz testing, by inputting meaningless and random information into the application and observing the response of the application to discover security risks. Fuzzing tests whether the application may be attacked if it is not used in the intended way.
Fuzzing, like DAST, has higher requirements for users. Although fuzzing is tested by inputting random information, it is still necessary to balance pure random information and random information generated by the application itself. On the other hand, Fuzzing is also easy to spend a lot of time on testing and in-depth analysis of the results, which may have some concerns for some companies that are currently promoting DevOps.
However, considering that Fuzzing has the opportunity to discover security risks that other application security testing and analysis products miss, as Fuzzing's own technology and enterprise IT capabilities become increasingly mature, related products deserve attention.
Application Security Platform
As the products of application security testing and analysis gradually mature, more and more related tools can be used by enterprises. As mentioned above, different products are suitable for different states of application development and operation, and enterprises also begin to need a platform to integrate and manage application security testing and analysis products.
The application security platform still serves the application development and operation of the enterprise, so it needs to be able to be integrated into the application development and operation process of the enterprise, and it needs to be able to connect with the relevant development platform of the enterprise technically. On the other hand, for enterprises using DevOps, the application security platform covers not only the security requirements in the development phase, but also security detection and protection in the application use state. Therefore, the application security platform manages not only application security testing and analysis products, but also security capabilities including RASP and other operational scenarios.
future trend
Application is an important carrier of enterprise digital business, so the security of application is directly related to the operation and development of enterprise digital business. Enterprises must pay more and more attention to application security: whether it is an application developed and used within the enterprise or an application purchased from a supplier, it will eventually need to pass the security inspection. From this point of view, application software suppliers will also increase investment in the security level of their own application development because they will face security challenges from customers in the future.
Application security testing and analysis is only one part of the overall application security. From the perspective of the future, whether it is the technical depth of these products or the overall application security, or even the security of the software supply chain, there will be different trends.
SAST intelligence
There will always be a need for overall testing of application source code, and the importance of SAST is self-evident in the application development process. As the amount of codes increases, the accuracy requirements for SAST detection become higher and higher. Reducing the false alarm rate by changing the alarm standard is currently a means to improve the efficiency of SAST use, but for the development team, it is still an indicator rather than a permanent cure - because this will increase the false negative rate of SAST.
To solve the problem of high false positive rate of SAST, it is still necessary to start with the SAST engine in essence. Through technologies such as artificial intelligence, SAST tools can understand the source code more globally, thereby reducing the occurrence of false positives.
IAST Multilingualization
One of the limitations currently faced by IAST is that it supports fewer languages. Compared with the language types supported by SAST and SCA, IAST, which can only support several languages, has certain limitations in the use scenarios. With the popularity of IAST and the development of related businesses, the types of languages that IAST can support will gradually increase.
SCA generalization
As a particularly popular field in recent years, SCA plays a significant role in the security of the software supply chain. The current usage scenarios of SCA are still focused on enterprises managing the open source components used in their own development environment and ensuring their security, but from the perspective of development, SCA can do more.
When the security of the software supply chain is getting more and more attention, enterprises not only care about the open source components used in their own development, but also need to know which components are used in other software supplier partners. Of course, when the binary detection capability matures, enterprises can use the binary SCA detection capability to identify the components used by suppliers, but obviously it will consume a lot of time. Only by "governing the chain with the chain" can the relevant open source components be managed more efficiently: that is, when the enterprise purchases and uses the software of the supplier partner, it also requires the relevant supplier partner to issue accurate SBOM information so that Enterprises manage software assets.
Therefore, as the security of the software supply chain is getting more and more attention, the value of SCA will not only exist in the security of its own development and application, but also will be a powerful means to prove the security of its own production software to downstream customers.
Securing the development team
Although DevSecOps is not the optimal development model for all projects, its idea of integrating security into the development and operation process is worth learning. In fact, application security should not only "shift security to the left", but should run through the entire life cycle of the application, so that security detection, vulnerability repair, attack protection and other measures can be carried out on the application at any stage.
Securing the development team does not mean requiring the security team to integrate into the development team, but to enhance the security development awareness and capabilities of the original development team. Because the development team is the one who knows the application best, the improvement of the development team's security capabilities can not only effectively reduce the conflict between the security team and the business team, but also improve the efficiency of repairing application security risks and increase the use value of application security capabilities.
Application security platform
The construction of application security is inseparable from the maturity of the application development and operation system. When the application development and operation system is mature, the enterprise will have a complete set of processes around application development and operation—and this process will often have an application platform for overall management. In this scenario, for different application development and operation periods, there will be different risks, and the corresponding security capabilities can be properly embedded in different stages. The platform also needs to monitor and analyze the security situation of the entire application stage, and continuously output application security capabilities.
Continuous Application Security (CAS) is proposed based on this idea. It integrates security capabilities such as SCA, SAST, IAST, DAST, FUZZING, RASP, and mobile application security testing through a platform for security issues in different application development and operation periods. And analyze the security data, and finally achieve the purpose of helping users reduce resource investment, integrate security capabilities and improve security efficiency.