Organizations from all walks of life, regardless of size, use open source applications, and this trend continues unabated. In the development stage, embedding the source code in the software is both economical and efficient. With the help of other resources,
DevOps can focus more on the internal code of the organization. But the problems of DevSecOps cannot be ignored.
According to a GitHub survey, 94% of the respondents indicated that they would use open source applications at least from time to time, while 81% used it frequently. In fact, 82% of developers revealed that their organization accepts the use of open source software, while 84% of people are encouraged to use open source code in their applications.
Although using open source code still needs to ensure security in continuous delivery
Although open source components can save time and costs, the relevant responsibilities are specified in their license agreements. In addition, 1/16 of the open source software requested to download has a known vulnerability.
In the waterfall development model, the vulnerability of open source components is obviously a headache, but it is far less serious than it is now. Agile development is fast, and every end of the cycle should deliver usable, safe products for sale. While requiring continuous and agile development, how can we ensure that there are no open source vulnerabilities in the solution?
Insist on discovering vulnerabilities in the development stage and strengthening security testing
But what about open source code? These codes are now more common in organization's product codes than private codes. Gartner mentioned in the Magic Quadrant for
Application Security Testing released in February 2017
"By 2019, 80% of application security testing vendors will include software composition analysis in their products, compared to the current 40%."
This shows an increase of 40 percentage points in just two years. In addition to the static analysis security test (SAST), dynamic analysis security test (DAST) and interactive application security test (IAST) programs, the normal application security products include software composition analysis (SCA), which means to customers what? Overall, Gartner’s predictions indicate that customers may use vendor’s package to test their old, modern, mobile or combined applications.
Three steps to prevent code vulnerabilities
Today, application security tools are appearing in the software development life cycle (SDLC) earlier and earlier. Ideally, they will be tied to the organization's build tools. If there are vulnerable parts, the build will fail, or at least the release manager of the relevant vulnerable parts will be notified.
For development managers and chief security officers (CSOs), such daily practices can meet five of the six DevOps security requirements: automation, speed, coverage, detection, and remediation.
But what about the sixth requirement, "prevention"? This is where future best practices come into play: let developers prevent vulnerable open source components from entering the code. For this purpose, the safety supervisor should take the following steps:
Define open source strategies that need to be
automatically implemented. Ideally, you can use the company's SCA tool to set any strategy, including the severity of security vulnerabilities, the licensing team, the level of vulnerabilities, and the number of years of storage.
Developers are required to download only secure parts. Using browser extensions, developers are warned when they want to download vulnerable open source components.
Use collective wisdom to adopt strategies already implemented by similar companies, including those implemented by developers in similar vertical industries (such as health and financial services). You can also use strategies implemented by organizations of the same size. Learn from the experience of others, take the initiative, and reject security holes outside the code.
Careful planning Practice safety development life cycle SDL to ensure safety
Continuous delivery and the security of combined applications will soon become daily activities. Make sure that the next best practice—the ability to move left to the developer eventually, prevents security holes from entering the code. In this regard, NSFOCUS has summarized and implemented a set of safety development life cycle SDL
Not only do we hope that we will encounter fewer risks, we also hope that we will be able to cope with them after encountering risks. For an enterprise, developers should have sufficient security risk awareness and
security development capabilities through security training. For enterprise safety management, it is necessary to have a sound safety development specification system and system operation safety process. Before an Internet finance project goes live, it is necessary to make sound security preparations, establish security lines at all levels, introduce security controls from all stages of the project, and avoid security risks from the source. A perfect development project should introduce the SDL (Security Development Lifecycle, Security Development Lifecycle) process to avoid security risks from the perspective of security risk management.
SDL introduces security management from the requirements phase, design phase, implementation phase, testing phase, and release response phase.
