Technology cloud report original.
Software supply chain security has now become a worldwide problem. Since the Apache Log4j "nuclear bomb level" risk broke out at the end of 2021, the impact still exists today, and ensuring the security of the software supply chain has become the focus of the industry.
However, nearly two years have passed, and the software supply chain security problem does not seem to be alleviated. Security incidents are emerging one after another, and the risk of open source vulnerabilities is increasing day by day.
According to Venafi's survey of 1,000 CIOs from different companies around the world, 82% of them said their organizations were vulnerable to cyber attacks targeting the software supply chain.
Qi Anxin's "2023 China Software Supply Chain Security Analysis Report" shows that open source project maintainers pay less attention to security issues and are less motivated to fix them.
At the same time, open source software that is inactive (has not been updated and released for more than a year), once a security vulnerability occurs, it is difficult to be repaired in time.
Why is it that everyone knows that software supply chain security is an important issue, but it is so difficult to solve?
Software supply chain security goes hand in hand with open source
To understand the crux of software supply chain security, we must first clarify its meaning.
Based on the definition of China Academy of Information and Communications Technology, software supply chain security refers to "the security of codes, modules and services from its own coding process, tools, equipment or upstream of the supply chain in each stage of software design and development on the software supply chain, as well as the security of software The sum of the delivery channel and the safety of the use process."
Here, the software supply chain security is divided into two parts: one is the supply chain security of the software itself, and the other is the security management of the software supply chain interface.
The supply chain of the software itself can be simply understood as the code source of the application. The code source of the application mainly has two parts: one is the code written by the product development itself, and the other is the imported third-party open source component code. Security testing for these two is also what we often call development security.
The software supply chain interface is aimed at open source software or commercially purchased third-party software.
This part of the supply chain security management is mainly to carry out relevant access inspections during the delivery and use process, and to form a standardized and traceable software bill of materials.
In fact, the increasing importance of software supply chain security is closely related to the general trend of open source.
The trend of software open source is a cumulative process. It has gone through a stage of quantitative change to qualitative change in more than ten years. Now developers around the world are relying on open source components for application development. Most modern code bases contain open source components. components.
But the prosperity of open source itself is based on a series of free license agreements and exemption clauses-including risk exemption. "Users take their own risks" is the consensus of the open source community.
In recent years, the security situation of open source software itself has continued to decline, and the security risks introduced by the use of open source software in enterprise software development have become even worse, such as: the use of dangerous open source components, the introduction of self-developed code defects and vulnerabilities, the introduction of container image vulnerabilities, etc. These risks make the overall security protection of software systems more and more difficult.
Therefore, there is a long way to go for open source software supply chain security risk governance.
Facing the challenges of software supply chain security governance
Although the industry has generally recognized the importance of software supply chain security, governance still faces numerous challenges.
Liu Tianyong, a security expert at Tencent security development, said that from a technical point of view, the difficulties in the governance of software supply chain security can be divided into three parts:
One is the high detection threshold.
The source of open source components is complex, and it is difficult to achieve comprehensive coverage by relying on a single technical means.
The common open source component detection technology on the market is SCA analysis based on source code, but it is difficult for SCA based on source code to cover the finished third-party software at the software supply chain interface.
Second, the repair cost is high.
When enterprises start risk management of open source components, a large number of vulnerabilities are often found in existing businesses, but most of these businesses are in the stage of online operation, and the repair process is a large consumption of R&D resources. It is said to be a relatively large push resistance.
Third, the attack has a wide range of influence.
The use of third-party open source components indirectly expands the attack surface of the software. The vulnerability mining and malicious exploitation of upstream supply chain links can quickly cover a large number of downstream software. At the same time, related attacks are highly concealed. Detection methods are difficult to carry out comprehensive defense. At present, software supply chain attacks have become a very common attack method in offensive and defensive drills.
In addition, suppliers do not pay enough attention to product security, and developers have limited security development capabilities, resulting in uneven product security and quality of third-party suppliers, which also increases the difficulty of software supply chain security governance.
So, how can companies address these challenges? Is there a corresponding technical solution?
SCA and SBOM
At present, SCA (Software Composition Analysis) is the main method in the industry to solve the risk detection of open source components.
SCA is a general term for a class of tools that can identify open source component information (name, version, check value), component vulnerabilities, open source protocols, and other information referenced by analyzing source code, thereby helping developers and security personnel to quickly identify information in enterprise code. Identify open source risks.
As supply chain security began to gain more attention, SCA tools built in deeper analysis and management of vulnerabilities and security risks associated with tracked components and became one of the primary methods for enterprises to generate SBOMs and manage their open source usage.
A recent Linux Foundation survey found that awareness of SBOM is high, with 47% of IT vendors, service providers and regulated industries currently using SBOM, and 88% of respondents expecting to use it by 2023 SBOM.
Code scanning and penetration testing
At its core, securing the software supply chain is an application security concern, so traditional application security code scanning tools will play an important role in this solution stack.
Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Runtime Application Scanning Protection (RASP) tools, along with judicious use of penetration testing, can help businesses test their own internal code and provide further checks on third-party code as a backstop against risk.
In contrast to SCA and SBOM products that rely on known, previously discovered vulnerabilities, a thorough application penetration assessment may identify vulnerable code usage when examining third-party libraries and frameworks that may have previously been elsewhere None reported.
Additionally, shared secret scanning and management is rapidly transitioning from a separate tool category to a feature that is being integrated into every aspect of software supply chain security tools.
This is because cyberattacks against confidential data embedded in source code, configuration files, and infrastructure code are still rampant in both development and live environments, and there is an urgent need to address this issue.
In addition, dependency management and analysis, trusted repositories and registries, secure code signing, CI/CD pipeline security, third-party risk management platforms, IaC security, and CNAPP are all software supply chain security governance that should focus on object.
As Dale Gardner, senior director and application security analyst at Gartner, said: "When people look at supply chain security, they look at tools like SCA, SBOM, etc., and those are very important parts of the solution, but they actually The above is only an incomplete solution."
Software supply chain security governance is not a purely technical issue
In fact, the software supply chain security problem is a problem of people, process and knowledge, rather than a purely technical problem.
When solving supply chain security issues in the software development process, it is necessary to consider supply chain security risks in line with SDLC (Software Development Life Cycle).
To this end, Goolge proposed the SLSA (Supply-chain Levels for Software Artifacts) framework, Microsoft proposed the SCIM (Supply Chain Integrity Model) framework and the CNCF (Cloud Native Computing Foundation) software supply chain best practices, all three frameworks Emphasize the security of source code, third-party dependencies, build systems, artifacts, releases, and deployments.
Take, for example, the SLSA framework, a standard inventory and control framework for mitigating supply chain risk for code and software packages in software projects.
The SLSA framework evaluates the security level of the software supply chain from three aspects, namely source code, construction and dependency, and can be divided into four levels:
Level 1: The build process is fully scripted or automated, and the source code can be identified based on the results;
Level 2: Use version control and hosting services with authentication capabilities to ensure that the build source is trusted;
Level 3: The source code and construction platform meet auditable standards, and the integrity of the finished product is guaranteed;
Level 4: All changes are reviewed by two people, and there is a closed, repeatable build process.
Taking Level 4 requirements as an example, enterprises need to practice the following four points during the software construction process: verifiable version control, double review, safe automated construction process/environment, and repeatable construction process.
epilogue
The security issues of every link in the software supply chain may become the entry point for hacker attacks. The embankment of a thousand miles is destroyed by an ant's nest, and every checkpoint in the software supply chain should be controlled, and small loopholes should not become scourges.
[About Science and Technology Cloud Report]
Focus on original enterprise-level content experts - technology cloud reports. Founded in 2015, it is the top 10 media in the cutting-edge enterprise IT field. Recognized by the Ministry of Industry and Information Technology, Trusted Cloud, one of the official media designated by the Global Cloud Computing Conference. In-depth original reports on cloud computing, big data, artificial intelligence, blockchain and other fields.