A Code Audit Is More Than Just a Bug Check

There are far more reasons to audit your code than just suspecting there are bugs overlooked by your development team. In fact, the code audit is a comprehensive analysis that assesses the health of your entire e-commerce platform. It gives you a reality check on the state of your code — including its quality, correctness, stability, and scalability — as well as helps you identify hidden bugs and security breaches.

Why do the audit?

One of the main benefits is to obtain a “second opinion” about the state of the SAP (Hybris) Commerce implementation. It may be that the current service provider made (and possibly is still making) implementation choices that are not fully beneficial to the customer, e.g.

• too much custom code,
• misusing the SAP (Hybris) Commerce platform,
• bad quality of the code, or
• wrong infrastructure setup.

All this can easily lead to very costly development and future maintenance of the solution.

Another important reason to perform an audit is a specific problem with the current solution. For example, it can be:

• a performance problem in the storefront in some specific case, or
• a problem with the long-running backend processes like a product import or order export.

Due to the complexity of enterprise solutions, it is not always straightforward to diagnose root causes of such problems. An audit of the overall solution can provide a fresh/outside perspective that is often helpful in many areas of the project.

 

When to do the audit?

Indisputably, frequent code reviews are an important part of the development process. Performed by your team on a regular basis, they let you maintain high-quality coding standards, ensure platform stability and eliminate potential security risks before they happen. But in some cases, an in-depth audit of the application code is indispensable — preferably conducted by an external auditor who can provide an independent and fresh look into your source code. Some of my suggestions for such an assessment include the following situations:

• When considering a major SAP (Hybris) Commerce platform upgrade — to make sure all potential risks of the upgrade are uncovered.
• When the development process begins to take more and more time even for relatively small changes.
• When devops processes are a bottleneck (e.g. deploying a new version takes a long time and/or a lot of manual effort).
• When the quality of deliverables is low (e.g. a lot of bugs, regressions, recurring performance or security issues).

 

How is the audit performed?

The auditing process is very flexible and can be adjusted to the needs of a specific customer/project. A rule of thumb is that the more access the auditors get, the more they can audit.

Usually, an audit starts with getting access to the current source code of the project — based on the code, a lot of activities can be performed. Any existing technical documentation for the solution can help during the process.

Getting additional access to the build/deployment environments enables more parts of the project to be reviewed.

 

What do you get from the audit?

In most cases, the code audit delivers a document that includes the following information:

• Management summary — short recap of the findings (max. one page), high level discussion on solution quality and future maintainability. It can also mention any urgent critical issues that need to be addressed.
• Identified issues — every issue is described in a separate section, always with the same structure:
  • Finding — a short summary of the issue, usually in a single sentence,
  • Description — details about the issue,
  • Recommendation — auditor recommendation for next steps to mitigate the issue,
  • Impact visualization — graphical representation of the impact of the issue on different aspects of the solution (e.g. testability, performance, maintenance).
• Static code analysis — some of the more critical issues found by SonarQube are described in the document with links to specific SonarQube rules that are violated.

 

What can you do after the audit?

Depending on the identified issues, there are different paths to take, including, for example:

• Remove custom code where it is not necessary and replace it with standard SAP (Hybris) Commerce functionalities.
• Refactor custom code to be more maintainable, secure, performant and resilient, depending on the identified issues.
• Upgrade the SAP (Hybris) Commerce platform to take advantage of new features and remove deprecated code from the solution. A code audit should always be a prerequisite to a platform upgrade.
• Modernize the infrastructure by introducing new technologies like build & test pipelines, containerization, Kubernetes. Possibly consider moving the infrastructure to the cloud.

 

What is the scope of the audit?

Even though the service is called “code review” or “code audit”, it often has a much broader scope, including:

• Code review — manual code analysis and automatic static code analysis (SonarQube), general code quality and correctness analysis.
• Architecture review — high level analysis of SAP (Hybris) Commerce extensions structure and dependencies, catalog setup, high level data model design, caching setup, review of SAP (Hybris) Commerce customizations.
• Integration review — analysis of interfaces to external systems, technology choices, integration types (sync vs async, full vs incremental).
• Security review — analysis of public-facing API endpoints, accessibility of SAP (Hybris) Commerce backend systems from the internet, testing cross-site scripting and other common attacks depending on the storefront implementation. Also supported by SonarQube’s static analysis for security vulnerabilities.
• Frontend review — analysis of the public-facing storefront with a focus on performance, web applications best practices, security, responsiveness etc. supported by tools like Lighthouse, YSlow and others.
• Testing review — analysis of testing practices in the project, i.e. level of automation, test coverage, maintainability of existing tests, whether they are passing/up-to-date.
• Infrastructure review — analysis of infrastructure setup, sizing, high availability, clustering, technologies (e.g. Solr Cloud), web server layer, load balancing, session management.
• Devops review — analysis of deployment and operations processes, technology stack (CI/CD tools, configuration management, environment provisioning), dynamic environments.
• Process review — analysis of the development process, documentation of requirements, release management, prioritization, planning, review and acceptance processes.

 

Code audit in practice

Default search replaced by a third-party custom solution

In one of the audits, we found that the project replaced the out-of-the-box SAP (Hybris) Commerce search engine (based on Apache Solr) with a third-party solution together with custom code. Business requirements for search in that project were rather standard and could be fulfilled without issues by the SAP (Hybris) Commerce platform. However, probably for commercial or other non-technical reasons, the third-party solution was integrated.

As it was a commercial and closed-source solution, it required specialist know-how to be maintained and supported. In addition, the customer lost all potential benefits from the search functionality offered by the SAP (Hybris) Commerce platform, including future enhancements (e.g. features provided by the Adaptive Search module). Instead, the custom solution will need to be kept up-to-date with SAP (Hybris) Commerce during platform upgrades to keep the currently implemented functionality working.

The third-party solution for search might have more sophisticated functionality, but in this specific project, using default SAP (Hybris) Commerce search and related tools would have been good enough to fulfill the requirements.

This example illustrates that it is important to carefully analyze all options before making technology choices, and align them with business requirements (current and potential future ones).

 

Project infrastructure issues

In many audits, we find that the infrastructure setup for the project is using an outdated setup, including the technology stack and related processes. One extreme case is using Subversion for source version control in 2019! However, more common are the following examples:

• Manual or only partially automated build & deployment processes. One-click deployment can be achieved nowadays without much effort.
• Manual or only partially automated configuration management both for the software and the servers. Much less error-prone and fully automated approaches are available.
• Running tests and code quality checks only on the “main” branch. Modern “pipelines” approach allows continuous build & test cycles of all code changes, including feature & bugfix branches.
• Underutilized resources. In some projects the size of individual servers in terms of CPU/RAM resources is too large — the real-world non-functional requirements (response time, peak load, etc.) often do not justify the choices made during infrastructure sizing. In the end, the servers are underutilized. Combined with the lack of ability for dynamic scaling (e.g. containerization, Kubernetes), it means a waste of resources (money).

 

The code audit should be considered whenever you are planning to implement a major upgrade of your SAP (Hybris) Commerce platform, or roll out new significant functionalities, or just want to investigate why your platform performance is declining and security breaches are becoming more common. If your internal team failed to identify issues or you need an unbiased outsider to have a look at your code with fresh eyes, the best option is bringing in a third-party expert to perform an in-depth code audit. Often, this is the only way to get an independent and objective assessment of your code and catch all vulnerabilities that haven’t been noticed by your employees despite the fact that the issues were right in front of their noses.