5/5 - (1 vote)

Organizations today face cybersecurity threats that are becoming ever more diverse, complex and sophisticated. At the same time, not every company has a department of cybersecurity specialists. But any modern IT company should think about the security of its products. The solution could be tools to automate security processes to deploy security solutions faster and not have a large cybersecurity department.

In practice, the main causes of security breaches are flaws in the implementation of protection mechanisms, vulnerabilities in the application code, and configuration flaws. Very often, control by the information security service is carried out at the last stages of the application life cycle. This scenario is incompatible with current DevOps and Agile practices that reduce software delivery cycle times to weeks.

There are several approaches to software security analysis, such as the white box and black (grey) box method. At the same time, the analysis of the source code using the white box method allows you to detect more vulnerabilities of a critical level, in comparison with the black box method, which analyzes the behavior of an already assembled application.

Fixing bugs during the operational or implementation phases is much more expensive than fixing vulnerabilities earlier. The earlier a vulnerability is identified, the cheaper it will cost a company to fix it. The Shift Security Left principle plays an important economic role.

The cost of fixing vulnerabilities in applications can be 1,000 times cheaper during the development phase than after the product is released to market.

COST OF FIXING VULNERABILITIES

The implementation of security processes earlier in the life cycle can be implemented in the following ways:

Implementation of code acceptance, implementation of internal audit, implementation of a secure development process (DevSecOps). At the same time, DevSecOps includes all other points and is the most effective approach to ensuring security.

Benefits of DevSecOps 

  1. DevSecOps integrates application and infrastructure security concerns into Agile and DevOps processes and tools.As with Agile tools, DevSecOps includes versatile, synergistic practices such as continuous integration and continuous delivery (CI/CD) that encourage and support frequent code reviews, version control, intelligent test automation, low-cost continuous releases. level of risk and feedback. In a DevSecOps environment, businesses can benefit from these practices by saving resources through improved operations, reduced rework, increased quality through automated testing and monitoring, and faster delivery of projects/products to the customer.
  2. Addresses security issues as they arise, when they can be done with less time and cost.This approach allows you to check, audit, scan and test the code for security at every stage of the development cycle. Security issues are fixed as soon as they are discovered. This eliminates the introduction of additional dependencies and increases the speed of fixing discovered security vulnerabilities. Development speed, security and code quality are increasing while costs are decreasing.
  3. Allows you to share responsibility for the security of applications and infrastructure between specialists in the development, security and operation of IT systems. Covers questions such as:– who is looking for vulnerabilities;

    – who fixes vulnerabilities;

    – who checks the correctness and completeness of the correction;

    – how to ensure communication between departments.

    The DevSecOps approach ensures that members of the Operations and Security team are involved in development from the very beginning. An important role in DevSecOps is the distribution of security responsibilities among product and process owners. Thus, engineers and developers become owners of the processes and take responsibility for their work.

  4. Integration with CI/CD pipelines. Cybersecurity testing can be integrated into automated test suites.Modern programs for automatic vulnerability search allow you to analyze the source code directly through CI / CD pipelines, such as Jenkins or TeamCity, and, based on the results of the work, generate tickets with a task to fix the vulnerability. In automatic tests, you can set the necessary scanning parameters for a specific project, thus taking into account the specifics and features of each product, depending on its purpose. For example, if an application uses third-party libraries, third-party component analysis (SCA) can be enabled to identify vulnerabilities in third-party code. Automation allows you to make sure that the product has successfully passed the stage of security unit testing. Besides,

DevSecOps Methods

Despite all the advantages of DevSecOps, companies often face a common set of challenges when moving from DevOps to DevSecOps, which can be solved using the following methods.

  • Promoting a DevSecOps culture among development teams. Teams need to be able to build security into the software development life cycle (SDLC). The challenge for organizations is to bring together development, operations, and compliance professionals into one community so that every employee understands corporate security and follows the same standards. All participants in the delivery lifecycle should be familiar with the basic principles of application security, the OWASP (Open Web Application Security Project) top 10 vulnerabilities list, application security testing methods, and other design approaches. Developers must have a good understanding of threat models, compliance checks, and practical skills in risk assessment,
  • It is good practice to have developers trained in secure coding and perform security testing before the code is committed. For example, one way is to use scanners based on integrated development environments (hereinafter referred to as IDEs) to detect unsafe code right on the developer’s workstation.
  • Developers must approve checkpoints in advance when to perform security actions. Consideration needs to be given to when security activities are performed in the SDLC. As mentioned in the previous point, experienced developers conduct security testing before code is committed. This prevents developers from reviewing unsecured code. For other organizations, the earliest starting point for a security scan may be their central integration pipelines, which typically run immediately after merging source code from dev branches into the master branch. It’s always worth remembering that it’s best to scan security early in development.
  • Automation is key to balancing security integration with speed and scale. Modern analyzers are effectively built into SDLC, and continuous integration systems such as Jenkins allow you to integrate with programs to automatically find vulnerabilities in source code.
  • When scanners are first introduced into a DevSecOps pipeline, a large number of rule sets and scan configurations are typically included. This hinders the adoption of DevSecOps, as development teams suddenly find many security issues in their queues, making it impossible to fix them in a short time. Therefore, it is important to start with small changes, for example, teams should limit the rule set to the top five vulnerabilities and run deeper scans later.
  • When introducing automated scanning methods, do not forget about unscheduled checks that help balance security requirements. Based on the results of these checks, you can customize security tools by analyzing historical data and application information. For example, you can switch scanning to manual mode in case of abnormal events in static code analysis, or analyze third-party components when a critical vulnerability is found.
  • Implementing DevSecOps also involves automating management activities. When choosing a tool for automation, it is necessary to take into account the presence of a sufficient number of interfaces for its integration with other subsystems. For example, to allow developers to scan in the IDE, you need to use a tool that supports common IDE software. For example, the SonarJava analyzer is integrated into the Gradle build system, Maven and launched in various IDEs via the SonarLint plugin.
  • The principles of “governance-as-code” and “configuration-as-code” provide the ability to manage through configuration files, rather than through interactive interaction. This accelerates product development and time to market and determines the level of automation that can be achieved throughout the SDLC. The ability to automatically check the software delivery pipeline does not eliminate the need for manual intervention to handle exceptions and adjust controls.
  • It is important to collect feedback from the development team when implementing new security features. Collaborating, gaining approval, and empowering development teams is key to ensuring that the governance model is inclusive and easy to use.

By following some simple rules, the implementation of the secure development process will be the most effective for the company and will take much less time.

Security Analysis Tools

A well-known approach to identifying vulnerabilities is pentesting. The purpose of a penetration test is to hack an application, that is, to find a weak spot in an application from which an attacker can develop an attack vector. But pentesting does not provide confidence that all vulnerabilities in the code have been found and verified.

Manual code analysis is time consuming and expensive; existing analysis solutions require an information security department. There are free open-source solutions. For example, Reshift is a vulnerability management software that includes features such as asset tagging, patch management, policy management, prioritization, vulnerability assessment, and web scanning. Supports five programming languages.

Advantages of this analyzer:

  • Can be installed as an extension for many IDEs;
  • Can be installed as a GitHub plugin.

Another analyzer LGTM is a code analysis platform for finding zero-day vulnerabilities and preventing critical vulnerabilities. LGTM was developed by the GitHub lab together with the creator of another CodeQL analyzer, which made it possible to combine static analysis and analysis through a special query language. Supports five programming languages ​​and is an extension for GitHub.

It is worth noting that free analyzers have a number of disadvantages: firstly, they have limited functionality, which is expanded by a paid subscription, and secondly, some of them do not currently have support and have not been updated for a long time.

Application analyzers use automated solutions: SAST (static analysis), DAST (dynamic analysis), IAST (interactive analysis), SCA (third-party component analysis).

Static analysis is a white box technology that analyzes and finds vulnerabilities right in the source code at the development stage.

Dynamic analysis is a “black box” technology that checks the finished application. Feeds various data to the input of the application and analyzes what the application produces at the output at the testing stage.

Interactive analysis is an approach, the purpose of which is to find vulnerabilities during code execution at the development stage.

Third party component analysis – analysis of 3rd party code, third party libraries and dependencies. It can be applied at any stage of the application life cycle.

Many existing solutions use either one of the application security analysis approaches (SAST or DAST), or some combination of them (SAST + SCA). But these approaches are not interchangeable, so excluding one of them, we can miss the vulnerability.

The most reliable is currently recognized as instrumental analysis, which is aimed at finding all vulnerabilities in the code. In general, instrumental analysis should include static analysis, dynamic analysis, search for weak libraries and configurations.

Application Inspector

An example of an instrumental approach to security analysis is the Application Inspector solution from Positive Technologies (AI PT).

AI PT combines all code analyzers and provides the following benefits:

  • Certification;
  • Code quality assessment;
  • Search for vulnerabilities in different programming languages;
  • Generation of exploits and vulnerability exploitation conditions. (Algorithm of abstract interpretation);
  • Creation of templates and tickets in CI/CD systems.

Application Inspector has 2 versions: AI Desktop Edition and AI Enterprise Edition.

AI Desktop Edition is used for the classic code acceptance task and is licensed per scan language and per project scanned.

AI Enterprise Edition has a scan server and scan agents, which allows you to embed the code analysis process into an existing CI / CD pipeline. This version is licensed by the number of scanning agents, as well as by the number of scanning languages.

Compared to other commercial and free analyzers, PT Application Inspector has additional features that are shown in the table.

Compared to free engines, PT AI has Taint-analysis, that is, the search for zero-day vulnerabilities. And in comparison with commercial products, PT AI has abstract interpretation capabilities, which allows you to calculate the conditions for exploiting a vulnerability and generate exploits. That is, a developer can emulate in the code analyzer interface that part of the program that has a vulnerability.

The pattern search algorithm allows you to search for known signatures in the database of vulnerabilities (CVE, internal databases) and build data flow diagrams.

One of the features of PT AI is the generation of reports in different formats. For example, the HTML format is easy to read for a developer, and on the basis of a report in JSON format, you can conduct independent analysis and build graphs.

Conclusion

The purpose of this article was to convince you that the transition to secure development is an important step in the evolution of IT companies. It is worth thinking about security not in hindsight, but from the very first step of the project life cycle. It’s worth noting that transforming your organization into DevSecOps is a massive undertaking with many known and unknown challenges. It’s important to remember that DevSecOps is not a turnkey tool or a golden pipeline. It will take a roadmap to become a reality for any organization. But in the end, the implementation of secure development will reduce the company’s costs for fixing errors, save development time, make interaction among employees better, where everyone clearly understands their role, and most importantly, help create better and safer products for users.